最近專案需要，所以研究了一下Redis主從的TCP連結是如何維持的，發現這一塊還沒有資料說明過，所以就把打算把這個東西記錄一下分享出來。

這個問題可以拆成以下幾個部分來說，包括：

• Redis如何建立主從關係
• Redis如何檢測斷鏈
• Redis如何重新建立主從關係

下面一一說明。

一、Redis如何建立主從關係

redis使用slaveof ip host指令來建立主從關係，主從關係的建立會引發持續的資料同步。值得一提的是，redis的設計認為這個關係的建立是持續性的，所以也設計了重連機制、對master的驗證機制、高效的資料重新同步的方法。下面具體描述這個過程及提到的幾個概念。

建立主從關係

前備條件：
例項A：127.0.0.1 6379
例項B：127.0.0.1 6380
我們希望例項A實時備份例項B，所以我們對例項A傳送指令slaveof 127.0.0.1 6380，這個邏輯如下圖所示。

*圖1 slaveofCommand指令傳送與執行過程

• redis-cli傳送指令slaveof 127.0.0.1 6379
• redis-server_6379接收slaveof 127.0.0.1 6379，執行slaveofCommand指令，將ip及port寫到server結構體裡，並修改狀態標誌位，同時回覆OK
• redis-server_6379執行周期函式serverCron
  ，其中會執行函式replicationCron，這裡會檢測狀態標誌位，並呼叫connectWithMaster，這個函式最後會呼叫非阻塞的connect，並且安裝事件處理函式syncWithMaster，當連線成功後，syncWithMaster被呼叫，啟動與Master的同步協議或者是連線失敗處理，如果是失敗，則後續會一直嘗試重連，所以我們會看到主從建立連線失敗的情況下syncWithMaster每秒都會被執行一次。

二、Redis如何檢測斷鏈

斷鏈這個問題比較複雜，需要考慮較多的情況，包括正常關閉、半開啟、異常關閉，底層的網路程式設計一般來說都跑不開這幾個話題，redis使用c語言作為開發語言，自己開發了一套IO複用機制，把這幾個問題處理得很好，這裡我不打算再敘述這幾個問題，下面直奔主題。

1、主監測從

主從關係建立後，redis從會以1秒為週期，向redis主傳送replconf ack offset指令，用以向master表達當前複製偏移量，並且讓master得以以此作為依據判斷redis從是否仍然存活，即心跳機制。

2、從監測主

主從關係建立後，redis主會以repl-ping-slave-period為週期，向redis從傳送PING指令。repl-ping-slave-period可以在配置檔案當中更改，不能小於1，因為replicationCron的週期是1，這是redis能處理的最小定時事件了（這是錯誤的，serverCron的週期才是redis能處理的最小定時事件）。
redis從以此為依據，建立心跳檢測機制。redis從每次收到ping指令，會更新server..master->lastinteraction時間，並且之後每次執行replicationCron都會檢測距離上次主從互動的時間是否超過了repl-timeout，這個也提供在配置檔案當中。如果時間超出了，則redis從認為redis主已經掛掉，則開始清理這個master。
所以我們可以得出結論，redis從基於repl-ping-slave-period及repl-timeout這兩個配置來建立對於master的檢測機制，前者最小不能小於replicationCron的週期，後者最小不能小於前者。

正常關閉

即Redis主主動發出Fin包，發起TCP關閉的流程。
redis從會為redis主建立客戶端，redis發出Fin包，向redis從傳送一個EOF。當redis從收到Fin包，產生可讀事件，readQureyFromClient被呼叫，最終呼叫read返回0，獲得EOF，感知到對端發起的關閉流程。

半開啟狀態

即對端已經無法通訊，但是本地無法感知到，除非主動發起通訊流程。
這種情況包括：

1、網路不通

2、主Redis程序崩潰或者主機down

3、主Redis主機網線被拿掉

4、中間網路裝置的網路被拿掉

這種情況Redis從需要依賴心跳機制來監測，並且主動發起TCP關閉流程，將[Redis從-->Redis主]方向的TCP連線關閉。
根據我們所描述的從監測主的原理，這個情況都可以被發現。

三、Redis如何重新建立主從關係

Redis從向Redis主重新發起連線

Server結構體定義了masterhost及masterport兩個域，用來儲存master的ip地址與埠。

`struct redisServer {`

    `...`

    `char* server.masterhost;`

    `int masterport;`

    `...`

`}`

當redis接受了slaveof ip port指令後，就將ip及port寫到以上兩個域當中。並且執行server.repl_state = REPL_STATE_CONNECT。
爾後在replicationCron函式當中根據根據以上操作，執行connect操作。具體如下：

`replicationCron()`

    `-->connectWithMaster()`

        `-->anetTcpNonBlockBestEffortBindConnect()`

        `-->aeCreateFileEvent()`

`replicationSendAck()`

replicationCron()是Redis惟一的定時事件的處理器，每秒被觸發一次。所以如果從與主斷掉了，從每秒會嘗試重新一次。

但是會嘗試多久，這個還需要再驗證。

每次執行時，會檢查是否需要連線master，如果需要就會呼叫connectWithMaster()。
connectWithMaster()使用非阻塞connect()去連線master，並且在connect()返回後馬上綁定了syncWithMaster()。
這個地方很精妙，也很體現Redis作者功力的地方。原本我以為syncWithMaster只有在連線成功後才會被繫結到描述符上，但事實並不是這樣。
connect()因為是非阻塞式的，所以我們沒有辦法立即得知是否連線成功了，但是當connect()的結果確定後，核心會反映到描述符上，如果成功則會產生可寫事件，如果失敗就會產生可讀、可寫事件。這個時候利用getsockopt()就可以判斷connect()是否成功了。
這個地方還有一個注意事項，非阻塞式connect()會立即返回－1，但是fd是由sock()建立的，所以這個時候並不是說fd可以用來與遠端伺服器通訊，但是我們的確可以用他來與核心通訊，但是這個fd並不會出現在/proc檔案系統裡。

aeCreateFileEvent()會將anetTcpNonBlockBestEffortBindConnect()產生的fd及可讀、可寫事件與syncWithMaster()繫結到一起，當fd產生可讀可寫事件時，syncWithMaster()執行，如果連線失敗，那麼這個情況就會在syncWithMaster()被處理掉。