閱讀132 返回首頁    go 阿裏雲 go 技術社區[雲棲]


Redis開發運維實踐高可用和集群簡述

10.1 概念

在本文檔中,高可用主要指的是解決盡可能在不丟失數據的前提下不間斷服務問題,由於redis是異步複製,因此不保證數據完全不丟失,在這個場景下並不實現動態橫向擴容,隻能進行縱向擴容,你隻要加內存,啟動redis,設置maxmemory即可。而分片(Sharding)主要指的是解決在線動態橫向擴容縮容問題,當然為了穩定也進行高可用部署配置,即包含成對的主從關係。


10.2 高可用主要場景和對應思路

適用於redis非重度用戶,內存占用不大,總體內存大小的增長趨勢可預估,有一定停機時間的係統——縱向擴容即可滿足,可以對全庫進行主從複製即滿足需求而不需要做分片,一般針對單個小型項目的cache 等場景。一般采用一主多從的sentinel方案進行部署。


10.3 分片主要場景和對應思路

分片是為了應對業務增長帶來的數據增長,需要對動態橫向擴容有一定要求時采用。對於一般的分片采用一致性哈希,它極大的優化機器增刪時帶來的哈希目標漂移問題。同時對於Hash目標漂移時產生的嚴重的數據傾斜,可以利用虛擬節點來優化。基本上,物理節點有了一定規模後,隻要不是同時掛多個節點,或者同時擴容多個節點,數據分片不會有太大的擾動。穿透過Cache的請求後端存儲可以抗住即可。

稍微複雜的方案是可以使用“預分片(Pre-Sharding)”的方案,也稱為按“桶”進行數據劃分,即分配一個相當大的集合,對Key哈希的結果落在這個集合中,集合的每個元素又與具體的物理節點存在多對一的路由映射關係,這張路由表由一個配置中心進行維護。其實,一致性哈希中的虛擬節點,實際上也可以歸類到Pre-Sharding方案中。換句話說,隻要是key經過兩次哈希,第一次Hash到虛擬節點,第二次Hash到物理節點,都可以算作Pre-Sharding。隻不過區別在於,一致性哈希的第二次Hash其路由表是按照算法固定的,而分桶的第二次Hash其路由表是第三方可配的。


10.4 適用場景對比列表

--- 動態擴容能力 係統複雜度 開發複雜度 運維複雜度
主從複製+Sentinel No 簡單 簡單 簡單
Twemproxy No 簡單 簡單 稍微複雜
3.0 Cluster Yes 簡單 簡單 複雜
Codis Yes 複雜 簡單 複雜
應用層麵presharding Yes 複雜 複雜 視開發的水平而定


最後更新:2017-05-08 11:31:08

  上一篇:go Redis開發運維實踐高可用和集群架構與實踐(一)
  下一篇:go Redis開發運維實踐Shell提權問題