REdis一致性方案探討

REdis功能強大眾所周知，能夠大幅簡化開發和提供大並發高性能，但截止到REdis-5.0.5仍然存在如下幾大問題：

1. 一致性問題

這是由於REdis的主從復制采用的是異步復制，異常時可能發生主節點的數據未能復制到從節點，導致從節點提升為主節點后缺失部分數據。雖然REdis提供WAIT命令來使得主節點將數據同步給了從節點，但當前此命令可用性低。

1. 分布式事務問題

當前REdis只支持單機事務，從官方的文檔來看，推薦使用“EVAL+lua”方式實現事務，而不是“MULTI+EXEC”方式。分布式事務對任何系統都是難點和挑戰，短期內無實現可能，但如果只實現低級別的隔離性滿足部分應用場景，則可大幅度降低實現的復雜性。

1. 從節點重啟全量復制

REdis雖然有部分復制能力，但針對的是網絡連接斷開后重連接。部分復制依賴“repl”信息，所以當前並不直接支持（可手工操作）。

本文專注探討一致性問題的解決。受Hadoop的NameNode
HA方案啟發，REdis也可采用相同的解決方案，此方案對REdis架構基本無影響，而且代碼改動量小。

基於同樣的思路，為REdis引入QJM：

REdis主節點接收和處理寫（Write）操作，然后同步到QJM，只QJM寫成功后才返回給Client。數據一旦寫入到QJM，由一致性協議（PaxOS或Raft等）可保證數據不會丟。

一般QJM的實現可基於一致性協議PaxOS或Raft，當前也有開源的PaxOS和Raft庫可直接使用，比如微信開源的PhxOS，而開源的Raft則更多，比如百度的braft等。

考慮到單個QJM集群性能有限，可以分組，比如一組REdis節點（一個主節點，加一到多個從節點組成）一組QJM集群。由於QJM只需多數寫成功，因此正常情況下，新增的性能開銷多數應用場景可接受。

基於此方案，不需改變REdis現有架構，並且只需要少量代碼修改，主要改動點在：

1. REdis主節點不再直接同步數據到從節點，部分復制功能也不需要了（直接基於QJM做部分復制，可隨意重啟節點）；

2. REdis主節點同步數據到QJM，並且只有同步QJM成功后才向Client返回成功（相當於WAIT命令應用在QJM寫）；

3. REdis從節點持續從QJM同步數據並回放；

4. REdis從節點獲得選舉后，並不立即進入可服務狀態，而是在提供服務之前先保證已取得了QJM上最新的數據，然后才進入可服務狀態。由於從節點在選舉之前持續同步QJM數據，因此在獲得選舉時一般已是或很快包含了最新數據。

如果是一個新的從節點加入，則可象Hadoop
NameNode一樣，從節點先從主節點下載image文件（或叫快照文件），然后再從QJM部分復制形成完整數據。