Redis分布式方案的發(fā)展和演變

主從復制時代

跟Kafka、RocketMQ、MySQL、ZooKeeper一樣，Redis支持集群的架構，集群的節(jié)點有主節(jié)點和從節(jié)點之分。主節(jié)點叫master，從節(jié)點叫slave。slave會通過復制的技術，自動同步master的數(shù)據(jù)。

Redis主從復制解決了數(shù)據(jù)備份和一部分性能的問題。但是沒有解決高可用的問題，在一主一從或者一主多從的情況下，如果主服務器掛了，對外提供的服務就不可用了，需要手動把從服務器切換成主服務器，然后再把剩余節(jié)點設置為它的從節(jié)點，這個比較費時，還會造成一定時間的服務不可用。

Sentinel哨兵時代

從Redis2.8版本起，提供了一個穩(wěn)定版本的Sentinel哨兵來解決高可用的問題，它的思路是啟動奇數(shù)個Sentinel的服務來監(jiān)控Redis服務器來保證服務的可用性。

為了保證監(jiān)控服務器的可用性，我們會對Sentinel做集群部署，Sentinel既監(jiān)控所有的Redis服務，Sentinel之間也相互監(jiān)控。 Sentinel本身沒有主從之分，地位是平等的，只有Redis服務節(jié)點有主從之分。

Sentinel通過Raft共識算法，實現(xiàn)Sentinel選舉，選舉出一個leader，由leader完成故障轉移。
Raft共識算法在線演示：http://thesecretlivesofdata.com/raft（非常直觀，通俗易懂）
打不開時可參考國內這個：https://cloud.tencent.com/developer/article/2347149

• Raft算法的應用很廣泛，比如加密貨幣BTB，Spring Cloud注冊中心Consul也用到了Raft算法。
• Raft算法的核心思想是：先到先得，少數(shù)服從多數(shù)。Sentinel的Raft實現(xiàn)跟原生的算法是有所區(qū)別的，但是大體思想一致。

哨兵的不足：主從切換的過程中會丟失數(shù)據(jù)，因為只有一個master；只能單點寫，沒有解決水平擴容的問題。

Redis Cluster 時代

Redis Cluster是在Redis 3.0的版本正式推出的，用來解決分布式的需求，同時也可以實現(xiàn)高可用，它是去中心化的，客戶端可以連接到任意一個可用的節(jié)點。Redis Cluster可以看成是由多個Redis實例組成的數(shù)據(jù)集合?？蛻舳瞬恍枰P注數(shù)據(jù)的子集到底存儲在哪個節(jié)點，只需要關注這個集合整體。
Redis創(chuàng)建了16384個槽（slot），每個節(jié)點負責一定區(qū)間的slot。比如Node1負責0-5460，Node2負責5461-10922，Node3負責10923-16383。
對象分布到Redis節(jié)點的時候，首先是對Key用CRC16算法計算再%16384，得到一個slot的值，數(shù)據(jù)落到負責這個slot的Redis節(jié)點上。

key與slot的關系是永遠不會變的，會變的只有slot和Redis節(jié)點的關系。
如果想讓很多個key同時落在同一個節(jié)點怎么辦呢，只需要在key里面加入{hash tag}即可。
Redis在計算槽編號的時候只會獲取{}之間的字符串進行槽編號計算，如下所示：

user{666}base=...
user{666}fin=...

Redis-Cluster 特點

無中心結構。
數(shù)據(jù)按照slot存儲分布在多個節(jié)點，節(jié)點間數(shù)據(jù)共享，可動態(tài)調整數(shù)據(jù)分布。
可擴展性，可線性擴展到1000個節(jié)點（官網(wǎng)推薦不超過1000個），節(jié)點可動態(tài)添加或刪除。
高可用性，部分節(jié)點不可用時，集群仍可用。通過增加Slave做standby數(shù)據(jù)副本，能夠實現(xiàn)故障自動failover，節(jié)點之間通過gossip協(xié)議交換狀態(tài)信息，用投票機制完成Slave到Master的角色提升。
降低運維成本，提高系統(tǒng)的擴展性和可用性。

Redis Cluster既能實現(xiàn)主從的角色分配，又能夠實現(xiàn)主從切換，相當于集成了Replication和Sentinel的功能，目前來看屬于最優(yōu)解方案。