Redis學習日記(三):Redis 主從複製

九、Redis複製原理和優化

 

1、什麼是主從複製?

      a、redis單機存在的問題:

             redis單機部署非常不安全,具體可以表現爲:

             *      機器故障導致的 redis  服務停止,高可用問題,可以用 redis 的 主從複製來解決。     

             *      redis 服務意外停止導致的服務停止和數據丟失,高可用問題,主從複製可以解決。

             *      redis 容量瓶頸 , redis 的qps瓶頸(每秒查詢率),這些問題可以通過redis的分佈式解決。(在之後的文筆中介紹

      b、 主從複製

                       從字面上理解就是有主redis和從redis,主從可以是1對1, 也可以是1對多,主節點只能爲一個,從節點可以多個。

                      我們可以理解主從的關係爲從節點會複製主節點的數據達到他們兩者的數據一致性。

                      主從的數據流是單向的,只能從主(master)到從(slave)。

           主從複製還能通過讀寫分離來實現請求的分流達到負載均衡(寫數據到主節點,從從節點讀數據)

 

 

2、複製的配置

      a、命令方式

slaveof ip port :在連接到6379的客戶端發送瞭如slaveof 127.0.0.1 6380 這樣的命令,意思就是把當前節點6379當做從節點,6380當做主節點,在這個完成後6379就會進行對6380的同步數據操作。這個命令是異步的,在發出命令時就會返回結果,但實際執行結果可能並沒這麼快。

slaveof no one :解除當前客戶端和綁定主節點的關係,執行後當前客戶端就不再對之前主節點的複製。

命令方式不需要重啓,可以直接生效,但是不便於管理。

 

      b、配置文件方式

            配置文件中的配置項:

            slaveof ip port : 和命令一樣,在配置的時候就綁定主節點。

            slave-read-only yes :從節點只進行讀數據而不進行寫,這樣保證了主從節點數據的一致性。

              配置方式需要重啓才生效,便於統一管理。

 

3、全量複製和部分複製

a、run_id 和 偏移量

如這是主節點(6380) run_id 的信息,它唯一標識了一個redis的服務,用戶區分不同的redis

 

關於這個 run_id ,我們可以看下之前主從複製時從節點(6381)的日誌,我們可以看到從節點在複製主節點(6380)時就是用run_id來標識要複製的對象的。

 

偏移量的信息可以看下圖,這時主節點的偏移量信息,我們可以看到在主從同步是這個主從的偏移量是一致的,也就是說如果這個偏移量相差過大的話說明這個主從同步是存在問題的。

 

b、全量複製

 

①、從節點請求全量同步,但是從節點不知道主節點的 run_id 和 offset ,所以這時攜帶的參數是 ? 和 -1

②、主節點統一全量複製,這時把自己的 run_id 和 offset 攜帶給從節點

③、從節點先存儲主節點的信息

④、主節點開始bgsave , 保存RDB 文件, 準備給從節點同步

⑤、發送備份好的 RDB 文件給從節點

⑥、因爲在開始 bgsave 開始到備份結束這段時間主節點主進程還在接收命令,所以這時的命令存入 緩存區,在發送完 RDB 文件後在把這 buffer 發送到從節點

⑦,⑧、從節點清舊數據,然後重新加載主節點的數據。

 

c、部分複製

           

當master和slave斷開連接時,master會將期間所做的操作記錄到複製緩存區當中(可以看成是一個隊列,其大小默認1M)。待slave重連後,slave會向master發送psync命令並傳入offset和runId,這時候,如果master發現slave傳輸的偏移量的值,在緩存區隊列範圍中,就會將從offset開始到隊列結束的數據傳給slave,從而達到同步,降低了使用全量複製的開銷。

 

4、開發運維常見問題

a、讀寫分離

讀寫分離 : 將數據寫入主節點,從從節點讀數據,mysql中也常使用。

讀寫分離的問題

        複製數據存在延遲(從節點阻塞的時候會變明顯)。

        讀取到過期數據:主節點中保存的某個key過期了但是一直都沒被刪除,通過主從複製從節點就帶着了這個key,但是主從複製的時候又不允許對從節點寫,所以在讀取從節點的時候就可能會讀取到這個過期的key。這裏得知道 刪除過期數據的兩個策略:①、懶惰策略:只有在使用到這個key 的時候再去查看他的ttl,如果過期了則刪除並返回空;②、定時策略:定時從erpires字典中隨機抽樣一些key查看這個過期時間,如果這個key過期則刪除。具體的策略可以參考這個簡書上寫的。redis的過期時間和過期刪除機制

        從節點故障,將連接這個從節點的客戶端的遷移會比較困難。

 

b、主從配置不一致

1、主從節點 maxmemory 不一致 導致的數據丟失。

2、數據結構化參數 (例如hash-max-ziplist-entries)不同導致的 數據內存不一致問題。

 

c、規避全量複製

 

 

d、規避複製風暴

先了解下什麼是複製風暴: 複製風暴是指例如當一個主節點因爲某些原因而掛了然後重啓後,從節點都從這個主節點同時同步數據導致的cpu,內存,i/o 飆升的問題。

 

 

 

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章