redis高可用方案

自帶 哨兵機制 Sentinel

開源方案 

Codis／Twemproxy

http://blog.720ui.com/2016/redis_action_04_cluster/

https://blog.csdn.net/shmiluwei/article/details/51958359

Sentinel的做用：

A、Master 狀態監測

B、若是Master 異常，則會進行Master-slave 轉換，將其中數據最新的一個Slave做爲Master，將以前的Master做爲Slave 

C、Master-Slave切換後，master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換 

 

Sentinel的工做方式:

1)：每一個Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其餘 Sentinel 實例發送一個 PING 命令 
2)：若是一個實例（instance）距離最後一次有效回覆 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel 標記爲主觀下線。 
3)：若是一個Master被標記爲主觀下線，則正在監視這個Master的全部 Sentinel 要以每秒一次的頻率確認Master的確進入了主觀下線狀態。 
4)：當有足夠數量的 Sentinel（大於等於配置文件指定的值）在指定的時間範圍內確認Master的確進入了主觀下線狀態， 則Master會被標記爲客觀下線 
5)：在通常狀況下， 每一個 Sentinel 會以每 10 秒一次的頻率向它已知的全部Master，Slave發送 INFO 命令 
6)：當Master被 Sentinel 標記爲客觀下線時，Sentinel 向下線的 Master 的全部 Slave 發送 INFO 命令的頻率會從 10 秒一次改成每秒一次 
7)：若沒有足夠數量的 Sentinel 贊成 Master 已經下線， Master 的客觀下線狀態就會被移除。 
若 Master 從新向 Sentinel 的 PING 命令返回有效回覆， Master 的主觀下線狀態就會被移除。

https://www.cnblogs.com/jaycekon/p/6237562.html

 

高可用方案 Sentinel 結點至少須要3臺集羣，由於Redis的設定是隻有當超過50%的Sentinel進程能夠連通並投票選取新的master時，纔會真正發生主從切換。

多個Sentinel能夠引入虛擬IP（Virtual IP，VIP）簡化客戶端訪問複雜度

https://mp.weixin.qq.com/s/76veueX7a2vfUjmZP5Pg5g

 

注意：redis單個結點最好內存不要設置過大，由於master掛掉以後，選舉出新的master後，其它slave結點須要掛靠在新的master結點上，此時slave的redis結點會清空內容，從master上覆制rdb文件來全量同步，這樣若是內存過大，同步時間太長。

https://mp.weixin.qq.com/s/fpupqLp-wjR8fQvYSQhVLg

 

阿里雲 Redis 容災體系介紹

https://www.jianshu.com/p/ac8718f5aecd?utm_campaign=hugo&utm_medium=reader_share&utm_content=note&utm_source=weixin-timeline&from=timeline&isappinstalled=0

 

 

redis sharding方案

  Redis Cluster 是Redis的集羣實現，內置數據自動分片機制，集羣內部將全部的key映射到16384=16*1024個Slot中，集羣中的每一個Redis Instance負責其中的一部分的Slot的讀寫。集羣客戶端鏈接集羣中任一Redis Instance便可發送命令，當Redis Instance收到本身不負責的Slot的請求時，會將負責請求Key所在Slot的Redis Instance地址返回給客戶端，客戶端收到後自動將原請求從新發往這個地址，對外部透明。一個Key到底屬於哪一個Slot由crc16(key) % 16384 決定。

  關於負載均衡，集羣的Redis Instance之間能夠遷移數據，以Slot爲單位，但不是自動的，須要外部命令觸發。

  關於集羣成員管理，集羣的節點(Redis Instance)和節點之間兩兩按期交換集羣內節點信息而且更新，從發送節點的角度看，這些信息包括：集羣內有哪些節點，IP和PORT是什麼，節點名字是什麼，節點的狀態(好比OK，PFAIL，FAIL，後面詳述)是什麼，包括節點角色(master 或者 slave)等。

  關於可用性，集羣由N組主從Redis Instance組成。主能夠沒有從，可是沒有從 意味着主宕機後主負責的Slot讀寫服務不可用。一個主能夠有多個從，主宕機時，某個從會被提高爲主，具體哪一個從被提高爲主，協議相似於Raft，參見這裏。如何檢測主宕機？Redis Cluster採用quorum+心跳的機制。從節點的角度看，節點會按期給其餘全部的節點發送Ping，cluster-node-timeout(可配置，秒級)時間內沒有收到對方的回覆，則單方面認爲對端節點宕機，將該節點標爲PFAIL狀態。經過節點之間交換信息收集到quorum個節點都認爲這個節點爲PFAIL，則將該節點標記爲FAIL，而且將其發送給其餘全部節點，其餘全部節點收到後當即認爲該節點宕機。從這裏能夠看出，主宕機後，至少cluster-node-timeout時間內該主所負責的Slot的讀寫服務不可用。

 

http://blog.csdn.net/shmnh/article/details/72868328