Redis複制與可擴充叢集搭建

Redis的複制功能是完全建立在之前我們讨論過的基于記憶體快照的持久化政策基礎上的，也就是說無論你的持久化政策選擇的是什麼，隻要用到了Redis的複制功能，就一定會有記憶體快照發生，那麼首先要注意你的系統記憶體容量規劃，原因可以參考我上一篇文章中提到的Redis磁盤IO問題。

Redis複制流程在Slave和Master端各自是一套狀态機流轉，涉及的狀态資訊是：

Slave 端：

Master端：

整個狀态機流程過程如下：

Slave端在配置檔案中添加了slave of指令，于是Slave啟動時讀取配置檔案，初始狀态為REDIS_REPL_CONNECT。

Slave端在定時任務serverCron(Redis内部的定時器觸發事件)中連接配接Master，發送sync指令，然後阻塞等待master發送回其記憶體快照檔案(最新版的Redis已經不需要讓Slave阻塞)。

Master端收到sync指令簡單判斷是否有正在進行的記憶體快照子程序，沒有則立即開始記憶體快照，有則等待其結束，當快照完成後會将該檔案發送給Slave端。

Slave端接收Master發來的記憶體快照檔案，儲存到本地，待接收完成後，清空記憶體表，重新讀取Master發來的記憶體快照檔案，重建整個記憶體表資料結構，并最終狀态置位為 REDIS_REPL_CONNECTED狀态，Slave狀态機流轉完成。

Master端在發送快照檔案過程中，接收的任何會改變資料集的指令都會暫時先儲存在Slave網絡連接配接的發送緩存隊列裡（list資料結構），待快照完成後，依次發給Slave,之後收到的指令相同處理，并将狀态置位為 REDIS_REPL_ONLINE。

整個複制過程完成，流程如下圖所示：

從上面的流程可以看出，Slave從庫在連接配接Master主庫時，Master會進行記憶體快照，然後把整個快照檔案發給Slave，也就是沒有象MySQL那樣有複制位置的概念，即無增量複制，這會給整個叢集搭建帶來非常多的問題。

比如一台線上正在運作的Master主庫配置了一台從庫進行簡單讀寫分離，這時Slave由于網絡或者其它原因與Master斷開了連接配接，那麼當Slave進行重新連接配接時，需要重新擷取整個Master的記憶體快照，Slave所有資料跟着全部清除，然後重建立立整個記憶體表，一方面Slave恢複的時間會非常慢，另一方面也會給主庫帶來壓力。

是以基于上述原因，如果你的Redis叢集需要主從複制，那麼最好事先配置好所有的從庫，避免中途再去增加從庫。

在我們分析過了Redis的複制與持久化功能後，我們不難得出一個結論，實際上Redis目前釋出的版本還都是一個單機版的思路，主要的問題集中在，持久化方式不夠成熟，複制機制存在比較大的缺陷，這時我們又開始重新思考Redis的定位：Cache還是Storage？

如果作為Cache的話，似乎除了有些非常特殊的業務場景，必須要使用Redis的某種資料結構之外，我們使用Memcached可能更合适，畢竟Memcached無論用戶端包和伺服器本身更久經考驗。

如果是作為存儲Storage的話，我們面臨的最大的問題是無論是持久化還是複制都沒有辦法解決Redis單點問題，即一台Redis挂掉了，沒有太好的辦法能夠快速的恢複，通常幾十G的持久化資料，Redis重新開機加載需要幾個小時的時間，而複制又有缺陷，如何解決呢？

既然Redis的複制功能有缺陷，那麼我們不妨放棄Redis本身提供的複制功能，我們可以采用主動複制的方式來搭建我們的叢集環境。

主動複制雖然解決了被動複制的延遲問題，但也帶來了新的問題，就是資料的一緻性問題，資料寫2次或多次，如何保證多份資料的一緻性呢？如果你的應用對資料一緻性要求不高，允許最終一緻性的話，那麼通常簡單的解決方案是可以通過時間戳或者vector clock等方式，讓用戶端同時取到多份資料并進行校驗，如果你的應用對資料一緻性要求非常高，那麼就需要引入一些複雜的一緻性算法比如Paxos來保證資料的一緻性，但是寫入性能也會相應下降很多。

通過主動複制，資料多份存儲我們也就不再擔心Redis單點故障的問題了，如果一組Redis叢集挂掉，我們可以讓業務快速切換到另一組Redis上，降低業務風險。

通過主動複制我們解決了Redis單點故障問題，那麼還有一個重要的問題需要解決：容量規劃與線上擴容問題。

我們前面分析過Redis的适用場景是全部資料存儲在記憶體中，而記憶體容量有限，那麼首先需要根據業務資料量進行初步的容量規劃，比如你的業務資料需要100G存儲空間，假設伺服器記憶體是48G，那麼根據上一篇我們讨論的Redis磁盤IO的問題，我們大約需要3~4台伺服器來存儲。這個實際是對現有業務情況所做的一個容量規劃，假如業務增長很快，很快就會發現目前的容量已經不夠了，Redis裡面存儲的資料很快就會超過實體記憶體大小，那麼如何進行Redis的線上擴容呢？

Redis的作者提出了一種叫做presharding的方案來解決動态擴容和資料分區的問題，實際就是在同一台機器上部署多個Redis執行個體的方式，當容量不夠時将多個執行個體拆分到不同的機器上，這樣實際就達到了擴容的效果。

拆分過程如下：

在新機器上啟動好對應端口的Redis執行個體。

配置新端口為待遷移端口的從庫。

待複制完成，與主庫完成同步後，切換所有用戶端配置到新的從庫的端口。

配置從庫為新的主庫。

移除老的端口執行個體。

重複上述過程遷移好所有的端口到指定伺服器上。

以上拆分流程是Redis作者提出的一個平滑遷移的過程，不過該拆分方法還是很依賴Redis本身的複制功能的，如果主庫快照資料檔案過大，這個複制的過程也會很久，同時會給主庫帶來壓力。是以做這個拆分的過程最好選擇為業務通路低峰時段進行。

我們線上的系統使用了我們自己改進版的Redis,主要解決了Redis沒有增量複制的缺陷，能夠完成類似Mysql Binlog那樣可以通過從庫請求日志位置進行增量複制。

我們的持久化方案是首先寫Redis的AOF檔案，并對這個AOF檔案按檔案大小進行自動分割滾動，同時關閉Redis的Rewrite指令，然後會在業務低峰時間進行記憶體快照存儲，并把目前的AOF檔案位置一起寫入到快照檔案中，這樣我們可以使快照檔案與AOF檔案的位置保持一緻性，這樣我們得到了系統某一時刻的記憶體快照，并且同時也能知道這一時刻對應的AOF檔案的位置，那麼當從庫發送同步指令時，我們首先會把快照檔案發送給從庫，然後從庫會取出該快照檔案中存儲的AOF檔案位置，并将該位置發給主庫，主庫會随後發送該位置之後的所有指令，以後的複制就都是這個位置之後的增量資訊了。

目前大部分網際網路公司使用MySQL作為資料的主要持久化存儲，那麼如何讓Redis與MySQL很好的結合在一起呢？我們主要使用了一種基于MySQL作為主庫，Redis作為高速資料查詢從庫的異構讀寫分離的方案。

為此我們專門開發了自己的MySQL複制工具，可以友善的實時同步MySQL中的資料到Redis上。

（MySQL-Redis 異構讀寫分離）

總結：

Redis的複制功能沒有增量複制，每次重連都會把主庫整個記憶體快照發給從庫，是以需要避免向線上服務的壓力較大的主庫上增加從庫。

Redis的複制由于會使用快照持久化方式，是以如果你的Redis持久化方式選擇的是日志追加方式(aof),那麼系統有可能在同一時刻既做aof日志檔案的同步刷寫磁盤，又做快照寫磁盤操作，這個時候Redis的響應能力會受到影響。是以如果選用aof持久化，則加從庫需要更加謹慎。

可以使用主動複制和presharding方法進行Redis叢集搭建與線上擴容。