【深刻學習Redis】主從複製（下）

 

（續上文）

---

 

6、應用中的問題

1. 讀寫分離及其中的問題

在主從複製基礎上實現的讀寫分離，能夠實現Redis的讀負載均衡：由主節點提供寫服務，由一個或多個從節點提供讀服務（多個從節點既能夠提升數據冗餘程度，也能夠最大化讀負載能力）；在讀負載較大的應用場景下，能夠大大提升Redis服務器的併發量。下面介紹在使用Redis讀寫分離時，須要注意的問題。

 

一、延遲與不一致問題

前面已經講到，因爲主從複製的命令傳播是異步的，延遲與數據的不一致不可避免。若是應用對數據不一致的接受程度程度較低，可能的優化措施包括：優化主從節點之間的網絡環境（如在同機房部署）；監控主從節點延遲（經過offset）判斷，若是從節點延遲過大，通知應用再也不經過該從節點讀取數據；使用集羣同時擴展寫負載和讀負載等。

 

在命令傳播階段之外的其餘狀況下，從節點的數據不一致可能更加嚴重，例如鏈接在數據同步階段，或從節點失去與主節點的鏈接時等。從節點的slave-serve-stale-data參數便與此有關：它控制這種狀況下從節點的表現；若是爲yes（默認值），則從節點仍可以響應客戶端的命令，若是爲no，則從節點只能響應info、slaveof等少數命令。該參數的設置與應用對數據一致性的要求有關；若是對數據一致性要求很高，則應設置爲no。

 

二、數據過時問題

在單機版Redis中，存在兩種刪除策略：

• 惰性刪除：服務器不會主動刪除數據，只有當客戶端查詢某個數據時，服務器判斷該數據是否過時，若是過時則刪除。

• 按期刪除：服務器執行定時任務刪除過時數據，可是考慮到內存和CPU的折中（刪除會釋放內存，可是頻繁的刪除操做對CPU不友好），該刪除的頻率和執行時間都受到了限制。

在主從複製場景下，爲了主從節點的數據一致性，從節點不會主動刪除數據，而是由主節點控制從節點中過時數據的刪除。因爲主節點的惰性刪除和按期刪除策略，都不能保證主節點及時對過時數據執行刪除操做，所以，當客戶端經過Redis從節點讀取數據時，很容易讀取到已通過期的數據。

 

Redis 3.2中，從節點在讀取數據時，增長了對數據是否過時的判斷：若是該數據已過時，則不返回給客戶端；將Redis升級到3.2能夠解決數據過時問題。

 

三、故障切換問題

在沒有使用哨兵的讀寫分離場景下，應用針對讀和寫分別鏈接不一樣的Redis節點；當主節點或從節點出現問題而發生更改時，須要及時修改應用程序讀寫Redis數據的鏈接；鏈接的切換能夠手動進行，或者本身寫監控程序進行切換，但前者響應慢、容易出錯，後者實現複雜，成本都不算低。

 

四、總結

在使用讀寫分離以前，能夠考慮其餘方法增長Redis的讀負載能力：如儘可能優化主節點（減小慢查詢、減小持久化等其餘狀況帶來的阻塞等）提升負載能力；使用Redis集羣同時提升讀負載能力和寫負載能力等。若是使用讀寫分離，可使用哨兵，使主從節點的故障切換儘量自動化，並減小對應用程序的侵入。

 

2. 複製超時問題

主從節點複製超時是致使複製中斷的最重要的緣由之一，本小節單獨說明超時問題，下一小節說明其餘會致使複製中斷的問題。

 

超時判斷意義

1. 在複製鏈接創建過程當中及以後，主從節點都有機制判斷鏈接是否超時，其意義在於：

2. 若是主節點判斷鏈接超時，其會釋放相應從節點的鏈接，從而釋放各類資源，不然無效的從節點仍會佔用主節點的各類資源（輸出緩衝區、帶寬、鏈接等）；此外鏈接超時的判斷可讓主節點更準確的知道當前有效從節點的個數，有助於保證數據安全（配合前面講到的min-slaves-to-write等參數）。

3. 若是從節點判斷鏈接超時，則能夠及時從新創建鏈接，避免與主節點數據長期的不一致。

 

判斷機制

主從複製超時判斷的核心，在於repl-timeout參數，該參數規定了超時時間的閾值（默認60s），對於主節點和從節點同時有效；主從節點觸發超時的條件分別以下：

主節點：每秒1次調用複製定時函數replicationCron()，在其中判斷當前時間距離上次收到各個從節點REPLCONF ACK的時間，是否超過了repl-timeout值，若是超過了則釋放相應從節點的鏈接。

從節點：從節點對超時的判斷一樣是在複製定時函數中判斷，基本邏輯是：

• 若是當前處於鏈接創建階段，且距離上次收到主節點的信息的時間已超過repl-timeout，則釋放與主節點的鏈接；

• 若是當前處於數據同步階段，且收到主節點的RDB文件的時間超時，則中止數據同步，釋放鏈接；

• 若是當前處於命令傳播階段，且距離上次收到主節點的PING命令或數據的時間已超過repl-timeout值，則釋放與主節點的鏈接。

 

主從節點判斷鏈接超時的相關源代碼以下：

/* Replication cron function, called 1 time per second. */
void replicationCron(void) {
   static long long replication_cron_loops = 0;

   /* Non blocking connection timeout? */
   if (server.masterhost &&
       (server.repl_state == REDIS_REPL_CONNECTING ||
        slaveIsInHandshakeState()) &&
        (time(NULL)-server.repl_transfer_lastio) > server.repl_timeout)
   {
       redisLog(REDIS_WARNING,"Timeout connecting to the MASTER...");
       undoConnectWithMaster();
   }

   /* Bulk transfer I/O timeout? */
   if (server.masterhost && server.repl_state == REDIS_REPL_TRANSFER &&
       (time(NULL)-server.repl_transfer_lastio) > server.repl_timeout)
   {
       redisLog(REDIS_WARNING,"Timeout receiving bulk data from MASTER... If the problem persists try to set the 'repl-timeout' parameter in redis.conf to a larger value.");
       replicationAbortSyncTransfer();
   }

   /* Timed out master when we are an already connected slave? */
   if (server.masterhost && server.repl_state == REDIS_REPL_CONNECTED &&
       (time(NULL)-server.master->lastinteraction) > server.repl_timeout)
   {
       redisLog(REDIS_WARNING,"MASTER timeout: no data nor PING received...");
       freeClient(server.master);
   }

   //此處省略無關代碼……

   /* Disconnect timedout slaves. */
   if (listLength(server.slaves)) {
       listIter li;
       listNode *ln;
       listRewind(server.slaves,&li);
       while((ln = listNext(&li))) {
           redisClient *slave = ln->value;
           if (slave->replstate != REDIS_REPL_ONLINE) continue;
           if (slave->flags & REDIS_PRE_PSYNC) continue;
           if ((server.unixtime - slave->repl_ack_time) > server.repl_timeout)
           {
               redisLog(REDIS_WARNING, "Disconnecting timedout slave: %s",
                   replicationGetSlaveName(slave));
               freeClient(slave);
           }
       }
   }

   //此處省略無關代碼……

}

 

須要注意的坑

下面介紹與複製階段鏈接超時有關的一些實際問題：

一、數據同步階段：在主從節點進行全量複製bgsave時，主節點須要首先fork子進程將當前數據保存到RDB文件中，而後再將RDB文件經過網絡傳輸到從節點。若是RDB文件過大，主節點在fork子進程+保存RDB文件時耗時過多，可能會致使從節點長時間收不到數據而觸發超時；此時從節點會重連主節點，而後再次全量複製，再次超時，再次重連……這是個悲傷的循環。爲了不這種狀況的發生，除了注意Redis單機數據量不要過大，另外一方面就是適當增大repl-timeout值，具體的大小能夠根據bgsave耗時來調整。

二、命令傳播階段：如前所述，在該階段主節點會向從節點發送PING命令，頻率由repl-ping-slave-period控制；該參數應明顯小於repl-timeout值(後者至少是前者的幾倍)。不然，若是兩個參數相等或接近，網絡抖動致使個別PING命令丟失，此時恰巧主節點也沒有向從節點發送數據，則從節點很容易判斷超時。

三、慢查詢致使的阻塞：若是主節點或從節點執行了一些慢查詢（如keys *或者對大數據的hgetall等），致使服務器阻塞；阻塞期間沒法響應複製鏈接中對方節點的請求，可能致使複製超時。

 

3. 複製中斷問題

主從節點超時是複製中斷的緣由之一，除此以外，還有其餘狀況可能致使複製中斷，其中最主要的是複製緩衝區溢出問題。

 

複製緩衝區溢出

前面曾提到過，在全量複製階段，主節點會將執行的寫命令放到複製緩衝區中，該緩衝區存放的數據包括瞭如下幾個時間段內主節點執行的寫命令：bgsave生成RDB文件、RDB文件由主節點發往從節點、從節點清空老數據並載入RDB文件中的數據。當主節點數據量較大，或者主從節點之間網絡延遲較大時，可能致使該緩衝區的大小超過了限制，此時主節點會斷開與從節點之間的鏈接；這種狀況可能引發全量複製->複製緩衝區溢出致使鏈接中斷->重連->全量複製->複製緩衝區溢出致使鏈接中斷……的循環。

 

複製緩衝區的大小由client-output-buffer-limit slave {hard limit} {soft limit} {soft seconds}配置，默認值爲client-output-buffer-limit slave 256MB 64MB 60，其含義是：若是buffer大於256MB，或者連續60s大於64MB，則主節點會斷開與該從節點的鏈接。該參數是能夠經過config set命令動態配置的（即不重啓Redis也能夠生效）。

 

當複製緩衝區溢出時，主節點打印日誌以下所示：

須要注意的是，複製緩衝區是客戶端輸出緩衝區的一種，主節點會爲每個從節點分別分配複製緩衝區；而複製積壓緩衝區則是一個主節點只有一個，不管它有多少個從節點。

 

4. 各場景下複製的選擇及優化技巧

在介紹了Redis複製的種種細節以後，如今咱們能夠來總結一下，在下面常見的場景中，什麼時候使用部分複製，以及須要注意哪些問題。

 

一、第一次創建複製

此時全量複製不可避免，但仍有幾點須要注意：若是主節點的數據量較大，應該儘可能避開流量的高峯期，避免形成阻塞；若是有多個從節點須要創建對主節點的複製，能夠考慮將幾個從節點錯開，避免主節點帶寬佔用過大。此外，若是從節點過多，也能夠調整主從複製的拓撲結構，由一主多從結構變爲樹狀結構（中間的節點既是其主節點的從節點，也是其從節點的主節點）；但使用樹狀結構應該謹慎：雖然主節點的直接從節點減小，下降了主節點的負擔，可是多層從節點的延遲增大，數據一致性變差；且結構複雜，維護至關困難。

 

二、主節點重啓

主節點重啓能夠分爲兩種狀況來討論，一種是故障致使宕機，另外一種則是有計劃的重啓。

 

主節點宕機

主節點宕機重啓後，runid會發生變化，所以不能進行部分複製，只能全量複製。

 

實際上在主節點宕機的狀況下，應進行故障轉移處理，將其中的一個從節點升級爲主節點，其餘從節點重新的主節點進行復制；且故障轉移應儘可能的自動化，後面文章將要介紹的哨兵即可以進行自動的故障轉移。

 

安全重啓：debug reload

在一些場景下，可能但願對主節點進行重啓，例如主節點內存碎片率太高，或者但願調整一些只能在啓動時調整的參數。若是使用普通的手段重啓主節點，會使得runid發生變化，可能致使沒必要要的全量複製。

 

爲了解決這個問題，Redis提供了debug reload的重啓方式：重啓後，主節點的runid和offset都不受影響，避免了全量複製。

 

以下圖所示，debug reload重啓後runid和offset都未受影響：

但debug reload是一柄雙刃劍：它會清空當前內存中的數據，從新從RDB文件中加載，這個過程會致使主節點的阻塞，所以也須要謹慎。

 

三、從節點重啓

從節點宕機重啓後，其保存的主節點的runid會丟失，所以即便再次執行slaveof，也沒法進行部分複製。

 

四、網絡中斷

若是主從節點之間出現網絡問題，形成短期內網絡中斷，能夠分爲多種狀況討論。

第一種狀況：網絡問題時間極爲短暫，只形成了短暫的丟包，主從節點都沒有斷定超時（未觸發repl-timeout）；此時只須要經過REPLCONF ACK來補充丟失的數據便可。

第二種狀況：網絡問題時間很長，主從節點判斷超時（觸發了repl-timeout），且丟失的數據過多，超過了複製積壓緩衝區所能存儲的範圍；此時主從節點沒法進行部分複製，只能進行全量複製。爲了儘量避免這種狀況的發生，應該根據實際狀況適當調整複製積壓緩衝區的大小；此外及時發現並修復網絡中斷，也能夠減小全量複製。

第三種狀況：介於前述兩種狀況之間，主從節點判斷超時，且丟失的數據仍然都在複製積壓緩衝區中；此時主從節點能夠進行部分複製。

 

5. 複製相關的配置

這一節總結一下與複製有關的配置，說明這些配置的做用、起做用的階段，以及配置方法等；經過了解這些配置，一方面加深對Redis複製的瞭解，另外一方面掌握這些配置的方法，能夠優化Redis的使用，少走坑。

 

配置大體能夠分爲主節點相關配置、從節點相關配置以及與主從節點都有關的配置，下面分別說明。

 

一、與主從節點都有關的配置

首先介紹最特殊的配置，它決定了該節點是主節點仍是從節點：

1. slaveof <masterip> <masterport>：Redis啓動時起做用；做用是創建複製關係，開啓了該配置的Redis服務器在啓動後成爲從節點。該註釋默認註釋掉，即Redis服務器默認都是主節點。

2. repl-timeout 60：與各個階段主從節點鏈接超時判斷有關，見前面的介紹。

 

二、主節點相關配置

1. repl-diskless-sync no：做用於全量複製階段，控制主節點是否使用diskless複製（無盤複製）。所謂diskless複製，是指在全量複製時，主節點再也不先把數據寫入RDB文件，而是直接寫入slave的socket中，整個過程當中不涉及硬盤；diskless複製在磁盤IO很慢而網速很快時更有優點。須要注意的是，截至Redis3.0，diskless複製處於實驗階段，默認是關閉的。

2. repl-diskless-sync-delay 5：該配置做用於全量複製階段，當主節點使用diskless複製時，該配置決定主節點向從節點發送以前停頓的時間，單位是秒；只有當diskless複製打開時有效，默認5s。之因此設置停頓時間，是基於如下兩個考慮：(1)向slave的socket的傳輸一旦開始，新鏈接的slave只能等待當前數據傳輸結束，才能開始新的數據傳輸 (2)多個從節點有較大的機率在短期內創建主從複製。

3. client-output-buffer-limit slave 256MB 64MB 60：與全量複製階段主節點的緩衝區大小有關，見前面的介紹。

4. repl-disable-tcp-nodelay no：與命令傳播階段的延遲有關，見前面的介紹。

5. masterauth <master-password>：與鏈接創建階段的身份驗證有關，見前面的介紹。

6. repl-ping-slave-period 10：與命令傳播階段主從節點的超時判斷有關，見前面的介紹。

7. repl-backlog-size 1mb：複製積壓緩衝區的大小，見前面的介紹。

8. repl-backlog-ttl 3600：當主節點沒有從節點時，複製積壓緩衝區保留的時間，這樣當斷開的從節點從新連進來時，能夠進行全量複製；默認3600s。若是設置爲0，則永遠不會釋放複製積壓緩衝區。

9. min-slaves-to-write 3與min-slaves-max-lag 10：規定了主節點的最小從節點數目，及對應的最大延遲，見前面的介紹。

 

三、從節點相關配置

1. slave-serve-stale-data yes：與從節點數據陳舊時是否響應客戶端命令有關，見前面的介紹。

2. slave-read-only yes：從節點是否只讀；默認是隻讀的。因爲從節點開啓寫操做容易致使主從節點的數據不一致，所以該配置儘可能不要修改。

 

6. 單機內存大小限制

在 深刻學習Redis（2）：持久化 一文中，講到了fork操做對Redis單機內存大小的限制。實際上在Redis的使用中，限制單機內存大小的因素很是之多，下面總結一下在主從複製中，單機內存過大可能形成的影響：

1. 切主：當主節點宕機時，一種常見的容災策略是將其中一個從節點提高爲主節點，並將其餘從節點掛載到新的主節點上，此時這些從節點只能進行全量複製；若是Redis單機內存達到10GB，一個從節點的同步時間在幾分鐘的級別；若是從節點較多，恢復的速度會更慢。若是系統的讀負載很高，而這段時間從節點沒法提供服務，會對系統形成很大的壓力。

2. 從庫擴容：若是訪問量忽然增大，此時但願增長從節點分擔讀負載，若是數據量過大，從節點同步太慢，難以及時應對訪問量的暴增。

3. 緩衝區溢出：（1）和（2）都是從節點能夠正常同步的情形（雖然慢），可是若是數據量過大，致使全量複製階段主節點的複製緩衝區溢出，從而致使複製中斷，則主從節點的數據同步會全量複製->複製緩衝區溢出致使複製中斷->重連->全量複製->複製緩衝區溢出致使複製中斷……的循環。

4. 超時：若是數據量過大，全量複製階段主節點fork+保存RDB文件耗時過大，從節點長時間接收不到數據觸發超時，主從節點的數據同步一樣可能陷入全量複製->超時致使複製中斷->重連->全量複製->超時致使複製中斷……的循環。

 

此外，主節點單機內存除了絕對量不能太大，其佔用主機內存的比例也不該過大：最好只使用50%-65%的內存，留下30%-45%的內存用於執行bgsave命令和建立複製緩衝區等。

 

7. info Replication

在Redis客戶端經過info Replication能夠查看與複製相關的狀態，對於瞭解主從節點的當前狀態，以及解決出現的問題都會有幫助。

 

主節點：

從節點：

對於從節點，上半部分展現的是其做爲從節點的狀態，從connectd_slaves開始，展現的是其做爲潛在的主節點的狀態。

 

info Replication中展現的大部份內容在文章中都已經講述，這裏再也不詳述。

 

7、總結

下面回顧一下本文的主要內容：

1. 主從複製的做用：宏觀的瞭解主從複製是爲了解決什麼樣的問題，即數據冗餘、故障恢復、讀負載均衡等。

2. 主從複製的操做：即slaveof命令。

3. 主從複製的原理：主從複製包括了鏈接創建階段、數據同步階段、命令傳播階段；其中數據同步階段，有全量複製和部分複製兩種數據同步方式；命令傳播階段，主從節點之間有PING和REPLCONF ACK命令互相進行心跳檢測。

4. 應用中的問題：包括讀寫分離的問題（數據不一致問題、數據過時問題、故障切換問題等）、複製超時問題、複製中斷問題等，而後總結了主從複製相關的配置，其中repl-timeout、client-output-buffer-limit slave等對解決Redis主從複製中出現的問題可能會有幫助。

 

主從複製雖然解決或緩解了數據冗餘、故障恢復、讀負載均衡等問題，但其缺陷仍很明顯：故障恢復沒法自動化；寫操做沒法負載均衡；存儲能力受到單機的限制；這些問題的解決，須要哨兵和集羣的幫助，我將在後面的文章中介紹，歡迎關注。

 

參考文獻

• 《Redis開發與運維》

• 《Redis設計與實現》

• 《Redis實戰》

• http://mdba.cn/2015/03/16/redis複製中斷問題-慢查詢/

• https://redislabs.com/blog/top-redis-headaches-for-devops-replication-buffer/

• http://mdba.cn/2015/03/17/redis主從複製（2）-replication-buffer與replication-backlog/

• https://github.com/antirez/redis/issues/918

• https://blog.csdn.net/qbw2010/article/details/50496982

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