上節回顧

上一節我們講了AKF拆分原則，講了Redis主從復制的方式，是X軸方向的拓展，實現了HA，但是沒有解決單節點數據的容量有限問題。

如何解決單節點數據容量的問題

如果數據可以分類，交集不多，可以考慮按業務拆分

如果數據沒有辦法劃分拆解：

采用sharding分片
下面這三種方案都發生在客戶端

1、Hash+取模（幾乎沒人用）

2、使用random隨機分配節點，適合做消息隊列

3、使用kmeta一致性哈希，規劃一個環形哈希環
一致性哈希：https://www.jianshu.com/p/735a3d4789fc

物理節點：本來有兩個redis的物理節點。
虛擬節點：可以讓一個物理設備出現在好幾個節點上。環上就有20個物理點。這樣解決了數據傾斜的問題。
這種方案更傾向于作為緩存，而不是數據庫用。
（拓撲關系圖）

redis連接對server端的成本很高，是對server端造成的

解決方式：
類似于nginx反向代理，增加一個接入層
我們增加一個代理層，我們只需要關注代理層性能就可以了。
代理層里面有了邏輯實現，例如modula，random，kemata，這叫無狀態的。這樣減輕了客戶端的代碼。
如果請求壓力太大，代理層hold不住怎么辦？我們看圖的下半部分這個模型。
在代理層前面加一個LVS，LVS做一個主備，主備之間通過keepalived，除了監控兩個LVS的健康狀態之外，也監控proxy的健康狀態。

這些內容來自于哪兒？https://github.com/twitter/twemproxy

無論你企業后面技術多么復雜，對于客戶端，都是透明的。你要考慮客戶端代碼邏輯的復雜度成本，

不要因為技術而技術。redis連多線程都沒有使用，它并不希望redis被引入那么多的功能。

以上三種模式的弊端是不能做分布式數據庫用。一致性哈希增刪節點的時候會讓一部分數據時間窗不可用。

新增節點會對算法帶來挑戰，比如rehash等，怎么解決這個問題？
我們引入預分區的概念

預分區

以前我們模3，如果現在我們模10，中間再加一層mapping

新增節點，遷移數據的時候，把槽位中部分數據拿出來，放進新的節點即可

redis cluster模式：無主模型
http://redis.cn/topics/partitioning.html
客戶端可以去任意一個redis節點取數據，每一個redis都有所有key的映射關系算法，知道別人持有哪些分片，會給客戶端返回應該重定向到的redis，由客戶端自己去正確的redis上取。
例如，客戶端去redis3上找k1，redis2說，你應該去redis3找。于是客戶端就去redis3上取k1

數據分治會帶來一個問題：聚合操作很難實現。
事務很難實現
兩個set取交集，可以實現但是redis并沒有去實現，因為其中有一個數據移動的過程->redis的作者想要計算向數據移動，而不是去移動數據。redis的作者做了取舍，將影響性能的功能都取消掉了。
redis代理關閉了一些操作：

可以由人去實現：hash tag
例如我們將帶有相同前綴的key放在一個節點上（我手動把它放到一起去，就能實現事務了）

Predixy

github上有完整的中文安裝步驟

總結

以上是生活随笔為你收集整理的Redis实战（七）：redis的集群：主从复制、CAP、PAXOS、cluster分片集群 2的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。