redis 主從同步&哨兵模式&codis
主從同步
1、CPA原理
1. CPA原理是分散式儲存理論的基石： C(一致性)； A(可用性)； P(分割槽容忍性);
2. 當主從網路無法連通時，修改操作無法同步到節點，所以“一致性”無法滿足
3. 除非我們犧牲“可用性”，也就是暫停分散式節點服務，不再提供修改資料功能，知道網路恢復
一句話概括CAP: 當網路分割槽發生時，一致性 和 可用性 兩難全
2、redis主從同步介紹
1. 和MySQL主從複製的原因一樣，Redis雖然讀取寫入的速度都特別快，但是也會產生讀壓力特別大的情況。
2. 為了分擔讀壓力，Redis支援主從複製，Redis的主從結構可以採用一主多從或者級聯結構。
3. Redis主從複製可以根據是否是全量分為全量同步和增量同步。
注：redis主節點Master掛掉時，運維讓從節點Slave接管（redis主從預設無法自動切換，需要運維手動切換）
3、全量同步（快照同步）
注：Redis全量複製一般發生在Slave初始化階段，這時Slave需要將Master上的所有資料都複製一份。具體步驟如下：
1）從伺服器連線主伺服器，傳送SYNC命令；
2）主伺服器接收到SYNC命名後，開始執行BGSAVE命令生成RDB檔案並使用緩衝區記錄此後執行的所有寫命令；
3）主伺服器BGSAVE執行完後，向所有從伺服器傳送快照檔案，並在傳送期間繼續記錄被執行的寫命令；
4）從伺服器收到快照檔案後丟棄所有舊資料，載入收到的快照；
5）主伺服器快照發送完畢後開始向從伺服器傳送緩衝區中的寫命令；
6）從伺服器完成對快照的載入，開始接收命令請求，並執行來自主伺服器緩衝區的寫命令；
7）完成上面幾個步驟後就完成了從伺服器資料初始化的所有操作，從伺服器此時可以接收來自使用者的讀請求。
4、增量同步
1. 主節點會將那些對自己狀態產生修改性影響的指令記錄在本地記憶體buffer中，然後非同步將buffer中指令同步到從節點
2. 從節點一邊執行同步指令達到主節點狀態，一邊向主節點反饋自己同步到哪裡（偏移量）
3. 當網路狀態不好時，從節點無法和主節點進行同步，當網路恢復時需要進行快照同步
5、Redis主從同步策略
1. 主從剛剛連線的時候，進行全量同步；全同步結束後，進行增量同步。
2. 當然，如果有需要，slave 在任何時候都可以發起全量同步。
3. redis 策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。
6、注意點
1. 如果多個Slave斷線了，需要重啟的時候，因為只要Slave啟動，就會發送sync請求和主機全量同步，當多個同時出現的時候，可能會導致Master IO劇增宕機。
哨兵模式--sentinel
1、sentinel作用
1. 當用Redis做主從方案時，假如master宕機，Redis本身無法自動進行主備切換
2. 而Redis-sentinel本身也是一個獨立執行的程序，它能監控多個master-slave叢集，發現master宕機後能進行自動切換。
2、sentinel原理
1. sentinel負責持續監控主節點的健康，當主節掛掉時，自動選擇一個最優的從節點切換成主節點
2. 從節點來連線叢集時會首先連線sentinel，通過sentinel來查詢主節點的地址
3. 當主節點發生故障時，sentinel會將最新的主節點地址告訴客戶端，可以實現無需重啟自動切換redis
3、Sentinel支援叢集
1. 只使用單個sentinel程序來監控redis叢集是不可靠的，當sentinel程序宕掉後sentinel本身也有單點問題
2. 如果有多個sentinel，redis的客戶端可以隨意地連線任意一個sentinel來獲得關於redis叢集中的資訊。
4、Sentinel版本
1. Sentinel當前穩定版本稱為Sentinel 2，Redis2.8和Redis3.0附帶穩定的哨兵版本
2. 安裝完redis-3.2.8後，redis-3.2.8/src/redis-sentinel啟動程式 redis-3.2.8/sentinel.conf是配置檔案。
5、執行sentinel兩種方式（效果相同）
法1：redis-sentinel /path/to/sentinel.conf
法2：redis-server /path/to/sentinel.conf --sentinel
1. 以上兩種方式，都必須指定一個sentinel的配置檔案sentinel.conf，如果不指定，將無法啟動sentinel。
2. sentinel預設監聽26379埠，所以執行前必須確定該埠沒有被別的程序佔用。
6、sentinel.conf配置檔案說明
1. 配置檔案只需要配置master的資訊就好啦，不用配置slave的資訊，因為slave能夠被自動檢測到
2. 需要注意的是，配置檔案在sentinel執行期間是會被動態修改的，例如當發生主備切換時候，配置檔案中的master會被修改為另外一個slave。
3. 這樣，之後sentinel如果重啟時，就可以根據這個配置來恢復其之前所監控的redis叢集的狀態。
# sentinel.conf 配置說明 sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1
'''1、sentinel monitor mymaster 127.0.0.1 6379 2''' #1）sentinel監控的master的名字叫做mymaster,地址為127.0.0.1:6379 #2）當叢集中有2個sentinel認為master死了時，才能真正認為該master已經不可用了 '''2、sentinel down-after-milliseconds mymaster 60000''' #1）sentinel會向master傳送心跳PING來確認master是否存活，如果master在60000毫秒內不迴應PONG #2）那麼這個sentinel會單方面地認為這個master已經不可用了 '''3、sentinel failover-timeout mymaster 180000''' #1）如果sentinel A推薦sentinel B去執行failover，B會等待一段時間後，自行再次去對同一個master執行failover， #2）這個等待的時間是通過failover-timeout配置項去配置的。 #3）從這個規則可以看出，sentinel叢集中的sentinel不會再同一時刻併發去failover同一個master， #4）第一個進行failover的sentinel如果失敗了，另外一個將會在一定時間內進行重新進行failover，以此類推。 '''4、sentinel parallel-syncs mymaster 1''' #1）在發生failover主備切換時，這個選項指定了最多可以有多少個slave同時對新的master進行同步 #2）如果這個數字越大，就意味著越多的slave因為replication而不可用，這個數字越小，完成failover所需的時間就越長。 #3）可以通過將這個值設為 1 來保證每次只有一個slave處於不能處理命令請求的狀態。
7、配置傳播
1. 一旦一個sentinel成功地對一個master進行了failover，它將會把關於master的最新配置通過廣播形式通知其它sentinel，其它的sentinel則更新對應master的配置。
2. 一個faiover要想被成功實行，sentinel必須能夠向選為master的slave傳送SLAVE OF NO ONE命令，然後能夠通過INFO命令看到新master的配置資訊。
3. 當將一個slave選舉為master併發送SLAVE OF NO ONE`後，即使其它的slave還沒針對新master重新配置自己，failover也被認為是成功了的。
因為每一個配置都有一個版本號，所以以版本號最大的那個為標準：
1）假設有一個名為mymaster的地址為192.168.1.50:6379。
2）一開始，叢集中所有的sentinel都知道這個地址，於是為mymaster的配置打上版本號1。
3）一段時候後mymaster死了，有一個sentinel被授權用版本號2對其進行failover。
4）如果failover成功了，假設地址改為了192.168.1.50:9000，此時配置的版本號為2
5）進行failover的sentinel會將新配置廣播給其他的sentinel，發現新配置的版本號為2時，版本號變大了，
說明配置更新了，於是就會採用最新的版本號為2的配置。
codis
1、為什麼會出現codis
1. 在大資料高併發場景下，單個redis例項往往會無法應對
2. 首先redis記憶體不易過大，記憶體太大會導致rdb檔案過大，導致主從同步時間過長
3. 其次在CPU利用率中上，單個redis例項只能利用單核，資料量太大，壓力就會特別大
2、什麼是codis
1. codis是redis叢集解決方案之一，codis是GO語言開發的代理中介軟體
2. 當客戶端向codis傳送指令時，codis負責將指令轉發給後面的redis例項來執行，並將返回結果轉發給客戶端
3、codis部署方案
1. 單個codis代理支撐的QPS比較有限，通過啟動多個codis代理可以顯著增加整體QPS
2. 多codis還能起到容災功能，掛掉一個codis代理還有很多codis代理可以繼續服務
4、codis分片的原理
1. codis負責將特定key轉發到特定redis例項，codis預設將所有key劃分為1024個槽位
2. 首先會對客戶端傳來的key進行crc32計算hash值，然後將hash後的整數值對1024進行取模，這個餘數就是對應的key槽位
3. 每個槽位都會唯一對映到後面的多個redis例項之一，codis會在記憶體中維護槽位和redis例項的對映關係
4. 這樣有了上面key對應的槽位，那麼它應該轉發到那個redis例項就很明確了
5. 槽位數量預設是1024，如果叢集中節點較多，建議將這個數值大一些，比如2048,4096
5、不同codis槽位如何同步
1. 如果codis槽位值存在記憶體中，那麼不同的codis例項間的槽位關係得不到同步
2. 所以codis還需要一個分散式配置儲存的資料庫專門來持久化槽位關係
3. codis將槽位關係儲存在zookeeper中，並且提供一個dashboard可以來觀察和修改槽位關係
6、codis優缺點
優點
- 對客戶端透明,與codis互動方式和redis本身互動一樣
- 支援線上資料遷移,遷移過程對客戶端透明有簡單的管理和監控介面
- 支援高可用,無論是redis資料儲存還是代理節點
- 自動進行資料的均衡分配
- 最大支援1024個redis例項,儲存容量海量
- 高效能
缺點
- 採用自有的redis分支,不能與原版的redis保持同步
- 如果codis的proxy只有一個的情況下, redis的效能會下降20%左右
- 某些命令不支援,比如事務命令muti
- 國內開源產品,活躍度相對弱一些