Redis高可用性：主從、哨兵和集羣

1、主從模式：master-slave

1. 引入背景：單實例Redis因爲數據量大性能會下降

2. master保證客戶端的讀寫，slave保證與master的數據同步和客戶端的讀取，從而實現備份和讀寫分離

3. 只需手動要修改slave機器的配置文件便可；若是master掛了，能夠升級slave爲master，便可讀寫

僅須要在slave node上修改配置：

找到slaveof這行，參考下面的修改（填上master node的Ip和端口就完事了）

slaveof 10.6.144.155 7030

另外注意下 slave-read-only yes 這行，這表示slave只讀不寫，也是推薦設置

4. 原理：主節點作一次bgsave

 

2、高可用性方案：Sentinel機制（哨兵機制）

1. 引入背景：在主從模式下，須要手動切換主備，會形成服務一段時間不可用

2. 哨兵是一個獨立的進程，經過發送命令，監控多個Redis實例(包括主Redis和從Redis)的運行狀態

3. 一個哨兵可能出現問題，因此使用多個哨兵進行監控Redis，而且哨兵之間會相互監控

4. 故障切換(failover)：主觀下線(一個哨兵監測到master故障)和客觀下線(經過發佈訂閱模式切換主從)

5. 以上過程對客戶端透明

 

3、redis集羣：Redis3.0版本推出了集羣(Cluster)功能，進行負載均衡，提升擴展性

1. redis集羣並不能保證數據的強一致性，可能會丟失寫操做

2. 哈希槽：redis集羣沒有使用一致性hash，而是使用哈希槽，一共有16384個哈希槽，每一個節點負責一部分哈希槽

3. 開源集羣方案：codis

 

 

 

 

 

 

 

參考：

https://www.jianshu.com/p/06ab9daf921d

http://www.javashuo.com/article/p-gfjgewpn-gp.html

http://www.javashuo.com/article/p-vguqgocn-gw.html

http://www.javashuo.com/article/p-gshfkfow-dq.html

http://www.javashuo.com/article/p-apvyfhec-gx.html