主從複製與sentinel

主從複製與sentinel

CAP原理

CAP原理是設計和部署分佈式應用時存在三個核心系統需求：consistent（一致性）、availability（可用性）、partition tolerance（分區容忍性）。一致性不知足就是多個分佈式節點的數據不一致，一個節點的修改操做沒法同步到另外一個節點。當網絡分區（網絡斷開，分佈式節點之間失去聯繫）發生時，一致性很難知足。除非犧牲可用性，就是暫停節點的服務，當網絡恢復時重啓。因此，網絡分區發生時（集羣中出現不能相互通訊的兩部分，即不知足分區容忍性），一致性和可用性難以同時知足。

大多數網站的架構都是AP，放棄對一致性的嚴格要求。

增量同步和快照同步

redis的主從數據是異步同步的，因此並不知足一致性的要求，在主從網絡斷開的條件下，主節點依然能夠正常對外提供修改服務，知足可用性。

主動同步（嚴格意義上講分爲主從同步和從從同步）主要分爲增量同步和快照同步兩種。

增量同步會將那些修改性指令存在本地的內存緩衝區中，而後異步的將其同步到從節點，從節點一邊執行同步指令一邊向主節點反饋偏移量。由於內存緩衝區是有限的，因此主庫不可能裝入太多指令，實際上這個緩衝區是一個環形數組，若是滿了就會覆蓋開始的內容。若是網絡長時間斷開就有可能緩衝區的指令被覆蓋掉，此時就須要使用快照同步。

快照同步將主庫中的內存數據所有裝入磁盤中，而後將其傳送到從節點，從節點拿到快照文件後清空內存而後執行全量加載。在執行快照同步時，主庫的修改指令還在不斷的裝入buffer中，若是buffer過小或者同步時間過長都會致使buffer的數據再次被覆蓋，因而又要進行快照同步，陷入死循環，因此要合理設置buffer的值以免。

當一個新節點加入集羣時先來一次快照同步，再進行增量同步。

redis2.8版本中快照同步改成了無盤複製，無需寫入磁盤，直接經過套接字將內容發給從節點，從節點取出寫入磁盤，而後一次性完成加載。

wait指令是強行手動同步，能夠設置從庫個數和最多等待時間，容許無限等待。

抵抗節點故障：sentinel

sentinel的做用：監控從節點的健康（判斷是否知足可用性）、進行主從切換、查詢主節點的地址。

它負責監控主從節點的健康，當主節點掛掉時，自動選擇一個最優的從節點切換爲主節點。

客戶端鏈接集羣時首先鏈接sentinel，而後由其來查詢主節點的地址，完成交互。客戶端鏈接時首先查主庫地址，若是發現主庫地址和內存中的不同就認爲主庫地址改變了，客戶端會斷開鏈接與主庫創建新的鏈接。

sentinel也能夠完成主動進行主從切換，主從切換後，主庫降級爲從庫，修改性指令在從庫執行會拋出異常，而後客戶端會切換鏈接。

在主從互換時，可能會由於網絡延遲致使同步消息丟失，sentinel能夠設置必須至少有x個節點正常複製，不然就失去可用性，還能夠設置正常複製的標準，就是每隔x秒收到從節點的反饋就表明合格。