redis集羣方案比較
1.哨兵模式架構
哨兵監控集羣服務的各節點的健康狀態，master解決寫服務，down之後選舉salve爲主節點
問題：單臺redis支持5w左右的併發，無法滿足大併發的業務需求
master掛掉之後，在選舉的過程中，不能響應寫服務
節點內存有限，即內存瓶頸
2.高可用模式架構（redis3.0之後官方架構）
redis集羣是一個由多個主從節點組成的分佈式服務集羣，它具有複製，高可用和分片的特性，Redis不需要sentinel哨兵也能完成節點移除和故障轉移的功能，需要將每個節點部署爲集羣模式，這種集羣模式沒有中心節點，可以水平擴展，官方可線性擴展到1000個節點，Redis集羣的性能和高可用性均優於之前版本的哨兵模式，且集羣配置非常簡單。
3.redis高可用搭建與使用
集羣搭建：
自己測試搭建3個小集羣，每個小集羣都是一主兩從架構
./redis-trib.rb create --replicas 2 192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 192.168.1.104:8001 192.168.1.104:8002 192.168.1.105:8001 192.168.1.105:8002 192.168.1.106:8001 192.168.1.106:8002
默認前面爲主節點（16384個槽總共，不管有多少個master）
配置文件的主要修改：
a.daemonize yes 後臺啓動
b.port 6379 （若在僞集羣下，需要修改這個端口號)
c. dir /home/redis-cluster/ (指定數據存放位置，僞集羣下必須設置爲不同 的地址， 不然會丟失數據)
d.cluster-enabled yes (啓動集羣模式)
e.cluster-config-file nodes-6379.conf(集羣節點信息文件，最好和port對應上)
f.cluster-node-timeout 5000(監測集羣節點不可用的時間)
g.appendonly yes (寫日誌文件)
具體的安裝路徑參考：https://www.cnblogs.com/xuliangxing/p/7146868.html
創建集羣遇到的坑：
Sorry, can't connect to node 192.168.1.101:6379
修改redis.conf文件，將bind 127.0.0.1註釋 protected-mode 模式設置爲no
redis集羣分片原理分析
redis cluster 採用虛擬槽分區，所有的鍵根據哈希函數映射到0~16383整數槽內，計算公式爲:solt=CRC16(key)%16383，每一個節點負責維護一部分槽以及槽所映射的鍵值數據，每個集羣之間是有心跳的，彼此之前知道所對應的分片槽
redis集羣Master選舉原理分析
當salve發現自己的master變爲FAIL狀態時，便嘗試進行FailOver,以期望成爲新的master。由於掛掉的master可能有多個salve，從而存在多個salve競爭爲master節點的過程，其過程如下：
- salve發現自己的master變爲FAIL
- 將自己記錄的集羣的currentEpoch加1，並廣播FAILOVER_AUTH_REQUEST信息
- 其他節點收到該信息，只有master響應，判斷請求者的合法性，併發送FAILOVER_AUTH_ACK，對每個epoch只發送一次ack
- 嘗試failover的salve收集FAIL_OVER_ACK,超過半數則成爲master
- 廣播Pong通知其他集羣節點