開源至上：mysql行鎖影響查詢嗎

Redis主從複制

概念

Redis的主從複制概念和MySQL的主從複制大概類似。一台

主機master

，一台

從機slaver

。master主機資料更新後根據配置和政策，自動同步到slaver從機，Master以

寫為主

，Slave以

讀為主

。

主要用途

• 讀寫分離

  ：适用于讀多寫少的應用，增加多個從機，提高讀的速度，提高程式并發

• 資料容災恢複

  ：從機複制主機的資料，相當于資料備份，如果主機資料丢失，那麼可以通過從機存儲的資料進行恢複。

• 高并發、高可用叢集實作的基礎

  ：在高并發的場景下，就算主機挂了，從機可以進行

  主從切換

  ，從機自動成為主機對外提供服務。

一主多從配置

環境準備

老哥太窮了，就用一台機器模拟三個機器。

• 第一步：

  将redis.conf複制3份，分别是redis6379.conf、redis6380.conf、redis6381.conf

• 第二步：

  修改三個redis.conf檔案裡的port端口、pid檔案名、日志檔案名、rdb檔案名

• 第三步：

  分别打開三個視窗模拟三台伺服器，并開啟redis服務。

檢視目前3台機器主從角色

先用指令

info replication

看看3台機器目前的

角色

是什麼。

# 三台機器都是這個狀态
127.0.0.1:6379> info replication
# 角色是master主機
role:master
# 從機個數為0
connected_slaves:0
           

設定主從關系

這裡注意，我們隻設定從機就可以了，不用設定主機。我們選擇

6380

和

6381

作為

從機

。

6379

作為

主機

。

# 6380 端口
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379

# 6381 端口
127.0.0.1:6381> SLAVEOF 127.0.0.1 6379

# 6381 端口
127.0.0.1:6381> SLAVEOF 127.0.0.1 6379
           

再次檢視3台機器目前角色

再次執行指令：

info replication

# 主機
127.0.0.1:6379> info replication
role:master # 角色：主機
connected_slaves:2 #連接配接的從機個數，以及從機IP和端口
slave0:ip=127.0.0.1,port=6380,state=online,offset=98,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=98,lag=1

# 從機1
127.0.0.1:6380> info replication
role:slave # 角色：從機
master_host:127.0.0.1 # 主機的IP和端口
master_port:6379

# 從機2
127.0.0.1:6381> info replication
role:slave # 角色：從機
master_host:127.0.0.1 # 主機的IP和端口
master_port:6379
           

搭建成功，試驗一把

• 全量複制：

  從機會把主機之前的資料全部都同步過來，大家可以在從機上get 某key試試。

• 增量複制：

  當主機新增資料時，從機會将該新增資料同步過來，大家可以在主機上執行指令set key value，然後在從機上get 該key，看是否能擷取到。

讀寫分離

Redis的從機

預設

不允許進行

寫操作

，大家可以在從機上執行指令

set key value

，會報錯。

# 6380從機
127.0.0.1:6380> set k3 v3
(error) READONLY You can't write against a read only slave.
           

「呼，好累」，主從複制寫的差不多了！！

主從複制原理

全量複制

**「①」**slave發送psync，由于是第一次複制，不知道master的runid，自然也不知道offset，是以發送psync ？ -1

**「②」**master收到請求，發送master的runid和offset給從節點。

**「③」**從節點slave儲存master的資訊

**「④」**主節點bgsave儲存rdb檔案

**「⑤」**主機點發送rdb檔案

并且在**「④」和「⑤」**的這個過程中産生的資料，會寫到複制緩沖區repl_back_buffer之中去。

**「⑥」**主節點發送上面兩個步驟産生的buffer到從節點slave

**「⑦」**從節點清空原來的資料，如果它之前有資料，那麼久會清空資料

**「⑧」**從節點slave把rdb檔案的資料裝載進自身。

全量複制的開銷

**「①」**bgsave時間

**「②」**rdb檔案網絡傳輸時間

**「③」**從節點清空資料的

**「④」**從節點加載rdb的時間

**「⑤」**可能的aof重寫時間，這是針對從節點，例如開啟了aof之後，從節點添加buffer資料時候，可能需要aof重寫

基于上面的原因，有的情況下不适合使用全量複制，例如網絡抖動之後，從節點隻需要傳送一部分資料，不需要傳送全部資料，

redis2.8

之後實作了部分複制功能

部分複制

**「①」**假設發送網絡抖動或者别的情況，暫時失去了連接配接

**「②」**這個時候，master還在繼續往buffer裡面寫資料

**「③」**slave重新連接配接上了master

**「④」**slave向master發送自己的offset和runid

**「⑤」**master判斷slave的offset是否在buffer的隊列裡面，如果是，那就傳回continue給slave，否則需要進行全量複制（因為這說明已經錯過了很多資料了）

**「⑥」**master發送從slave的offset開始到緩沖區隊列結尾的資料給slave

最後總結

搞定算法，面試位元組再不怕，有需要文章中分享的這些二叉樹、連結清單、字元串、棧和隊列等等各大面試高頻知識點及解析，以及算法刷題LeetCode中文版的小夥伴們可以點贊後點選這裡即可免費擷取！

最後再分享一份終極手撕架構的大禮包(學習筆記)：分布式+微服務+開源架構+性能優化

Code中文版的小夥伴們可以點贊後點選這裡即可免費擷取！**

最後再分享一份終極手撕架構的大禮包(學習筆記)：分布式+微服務+開源架構+性能優化

[外鍊圖檔轉存中…(img-U1Bt06Gx-1625066732000)]