高可用Redis(八)：Redis主從複製
1.Redis複製的原理和優化
1.1 Redis單機的問題
1.1.1 機器故障
在一臺伺服器上部署一個Redis節點，如果機器發生主機板損壞，硬碟損壞等問題，不能在短時間修復完成，就不能處理Redis操作了，這就是單機可能存在的問題
同樣的，伺服器正常執行，但是Redis主程序發生宕機事件，此時只需要重啟Redis就可以了。如果不考慮在Redis重啟期間的效能損失，可以考慮Redis的單機部署
Redis單機部署出現故障時，把Redis遷移到另一臺伺服器上，此時需要把發生故障的Redis中的資料同步到新部署的Redis節點，這也需要很高的成本
1.1.2 容量瓶頸
一臺伺服器有16G記憶體，此時分配12G記憶體執行Redis
如果有新需求：Redis需要佔用32G或者64G等更多的記憶體，此時這臺伺服器就不能滿足需求了,此時可以考慮更換一臺更大記憶體的伺服器，也可以用多臺伺服器組成一個Redis叢集來滿足這個需求
1.1.3 QPS瓶頸
根據Redis官方的說法，單臺Redis可以支援10萬的QPS，如果現在的業務需要100萬的QPS，此時可以考慮使用Redis分散式
2.什麼是主從複製
2.1 一主一從模型
一個Redis節點為master節點(主節點)，負責對外提供服務。
另一個節點為slave節點(從節點)，負責同步主節點的資料，以達到備份的效果。當主節點發生宕機等故障時，從節點也可以對外提供服務
如下圖所示
2.2 一主多從模型
一個Redis節點為master節點(主節點)，負責對外提供服務。
多個節點為slave節點(從節點)。每個slave都會對主節點中的資料進行備份，以達到更加高可用的效果。這種情況下就算master和一個slave同時發生宕機故障，其餘的slave仍然可以對外讀提供服務，並保證資料不會丟失
當master有很多讀寫，達到Redis的極限閥值，可以使用多個slave節點對Redis的讀操作進行分流，有效實現流量的分流和負載均衡，所以一主多從也可以做讀寫分離
2.3 讀寫分離模型
master節點負責寫資料，同時客戶端可以從slave節點讀取資料
3.主從複製作用
對資料提供了多個備份，這些備份資料可以大大提高Redis的讀效能，是Redis高可用或者分散式的基礎
4.主從複製的配置
4.1 slaveof命令
取消複製
4.2 配置檔案配置
修改Redis配置檔案/etc/redis.conf
slaveof <masterip> <masterport> # masterip為主節點IP地址，masterport為主節點埠
slave-read-only yes # 從節點只做讀操作，不做寫操作，保證主從裝置資料相同4.3 兩種主從配置方式比較
使用命令列配置無需重啟Redis，可以實現統一配置
使用配置檔案方式配置不變於管理，而且需要重啟Redis4.4 例子
有兩臺虛擬機器，作業系統都是CentOS 7.5
一臺虛擬機器的IP地址為192.168.81.100,做master
一臺虛擬機器的IP地址為192.168.81.101,做slave第一步：在192.168.81.101虛擬機器操作
[[email protected] ~]# vi /etc/redis.conf # 修改Redis配置檔案
bind 0.0.0.0 # 可以從外部連線Redis服務端
slaveof 192.168.81.100 6379 # 設定master的IP地址和埠然後儲存修改，啟動Redis
[[email protected] ~]# systemctl stop firewalld # 關閉firewalld防火牆
[[email protected] ~]# systemctl start redis # 啟動slave上的Redis服務端
[[email protected] ~]# ps aux | grep redis-server # 檢視redis-server的程序
redis 2319 0.3 0.8 155204 18104 ? Ssl 09:55 0:00 /usr/bin/redis-server 0.0.0.0:6379
root 2335 0.0 0.0 112664 968 pts/2 R+ 09:56 0:00 grep --color=auto redis
[[email protected] ~]# redis-cli # 啟動Redis客戶端
127.0.0.1:6379> info replication # 檢視Redis的複製資訊 檢視192.168.81.101機器上的Redis的info
# Replication
role:slave # 角色為slave
master_host:192.168.81.100 # 主節點IP為192.168.81.100
master_port:6379 # 主節點埠為6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:155
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0第二步：在192.168.81.100虛擬機器上操作
[[email protected] ~]# systemctl stop firewalld # 關閉firewalld防火牆
[[email protected] ~]# vi /etc/redis.conf # 修改Redis配置檔案
bind 0.0.0.0
然後儲存修改，啟動Redis
[[email protected] ~]# systemctl start redis # 啟動master上的Redis
[[email protected] ~]# ps aux | grep redis-server # 檢視redis-server程序
redis 2529 0.2 1.8 155192 18192 ? Ssl 17:55 0:00 /usr/bin/redis-server 0.0.0.0:6379
root 2536 0.0 0.0 112648 960 pts/2 R+ 17:56 0:00 grep --color=auto redis
[[email protected] ~]# redis-cli # 啟動master上的redis-cli客戶端
127.0.0.1:6379> info replication # 檢視192.168.81.100機器上Redis的資訊
# Replication
role:master # 角色為主節點
connected_slaves:1 # 連線一個從節點
slave0:ip=192.168.81.101,port=6379,state=online,offset=141,lag=2 # 從節點的資訊
master_repl_offset:141
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:140
127.0.0.1:6379> set hello world # 向主節點寫入資料
OK
127.0.0.1:6379> info server
# Server
redis_version:3.2.10
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:c8b45a0ec7dc67c6
redis_mode:standalone
os:Linux 3.10.0-514.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.8.5
process_id:2529
run_id:7091f874c7c3eeadae873d3e6704e67637d8772b # 注意這個run_id
tcp_port:6379
uptime_in_seconds:488
uptime_in_days:0
hz:10
lru_clock:12784741
executable:/usr/bin/redis-server
config_file:/etc/redis.conf第三步：回到192.168.81.101這臺從節點上操作
127.0.0.1:6379> get hello # 獲取'hello'的值，可以獲取到
"world"
127.0.0.1:6379> set a b # 向192.168.81.101從節點寫入資料，失敗
(error) READONLY You can't write against a read only slave.
127.0.0.1:6379> slaveof no one # 取消從節點設定
OK
127.0.0.1:6379> info replication # 檢視192.168.81.101機器，已經不再是從節點，而變成主節點了
# Replication
role:master # 變成主節點了
connected_slaves:0
master_repl_offset:787
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379> dbsize # 檢視192.168.81.101上Redis所有資料大小
(integer) 2第四步：回到192.168.81.100虛擬機器
127.0.0.1:6379> mset a b c d e f # 向192.168.81.100上的Redis集合中寫入資料
OK
127.0.0.1:6379> dbsize # Redis中資料大小為5
(integer) 5第五步：檢視192.168.81.100虛擬機器上Redis的日誌
[[email protected] ~]# tail /var/log/redis/redis.log # 檢視Redis最後10行日誌
2529:M 14 Oct 17:55:09.448 * DB loaded from disk: 0.026 seconds
2529:M 14 Oct 17:55:09.448 * The server is now ready to accept connections on port 6379
2529:M 14 Oct 17:55:10.118 * Slave 192.168.81.101:6379 asks for synchronization
2529:M 14 Oct 17:55:10.118 * Partial resynchronization not accepted: Runid mismatch (Client asked for runid '9f93f85bce758b9c48e72d96a182a2966940cf52', my runid is '7091f874c7c3eeadae873d3e6704e67637d8772b') # 與192.168.81.100裝置上通過info命令檢視到的run_id相同
2529:M 14 Oct 17:55:10.118 * Starting BGSAVE for SYNC with target: disk # 執行BGSAVE命令成功
2529:M 14 Oct 17:55:10.119 * Background saving started by pid 2532
2532:C 14 Oct 17:55:10.158 * DB saved on disk
2532:C 14 Oct 17:55:10.159 * RDB: 12 MB of memory used by copy-on-write
2529:M 14 Oct 17:55:10.254 * Background saving terminated with success
2529:M 14 Oct 17:55:10.256 * Synchronization with slave 192.168.81.101:6379 succeeded # 向192.168.81.101同步資料成功第六步：回到192.168.81.101虛擬機器
127.0.0.1:6379> slaveof 192.168.81.100 6379 # 把192.168.81.101重新設定為192.168.81.100的從節點
OK
127.0.0.1:6379> dbsize
(integer) 5
127.0.0.1:6379> mget a
1) "b"第七步：檢視192.168.81.101虛擬機器上Redis的日誌
[[email protected] ~]# tail /var/log/redis/redis.log # 檢視Redis最後10行日誌
2319:S 14 Oct 09:55:17.625 * MASTER <-> SLAVE sync started
2319:S 14 Oct 09:55:17.625 * Non blocking connect for SYNC fired the event.
2319:S 14 Oct 09:55:17.626 * Master replied to PING, replication can continue...
2319:S 14 Oct 09:55:17.626 * Trying a partial resynchronization (request 9f93f85bce758b9c48e72d96a182a2966940cf52:16).
2319:S 14 Oct 09:55:17.628 * Full resync from master: 7091f874c7c3eeadae873d3e6704e67637d8772b:1 # 從master節點全量複製資料
2319:S 14 Oct 09:55:17.629 * Discarding previously cached master state.
2319:S 14 Oct 09:55:17.763 * MASTER <-> SLAVE sync: receiving 366035 bytes from master # 顯示從master同步的資料大小
2319:S 14 Oct 09:55:17.765 * MASTER <-> SLAVE sync: Flushing old data # slave清空原來的資料
2319:S 14 Oct 09:55:17.779 * MASTER <-> SLAVE sync: Loading DB in memory # 載入同步過來的RDB檔案
2319:S 14 Oct 09:55:17.804 * MASTER <-> SLAVE sync: Finished with success5.全量複製和部分複製
5.1 全量複製
5.1.1 run_id的概念
Redis每次啟動時，都有一個隨機ID來標識Redis,這個隨機ID就是上面通過info命令檢視得到的run_id
檢視192.168.81.101虛擬機器上的run_id和偏移量
[[email protected] ~]# redis-cli info server |grep run_id
run_id:7e366f6029d3525177392e98604ceb5195980518
[[email protected] ~]# redis-cli info |grep master_repl_offset
master_repl_offset:0檢視192.168.91.100虛擬機器上的run_id和偏移量
[[email protected] ~]# redis-cli info server | grep run_id
run_id:7091f874c7c3eeadae873d3e6704e67637d8772b
[[email protected] ~]# redis-cli info | grep master_repl_offset
master_repl_offset:4483run_id是一個非常重要的標識。
在上面的例子裡，192.168.81.101做為slave去複製192.168.81.100這個master上的資料，會獲取192.168.81.100機器上對應的run_id在192.168.81.101上做一個標識
當192.168.81.100機器上的Redis的run_id發生改變，意味著192.168.81.100機器上的Redis發生重啟操作或者別的重大變化，192.168.81.101就會把192.168.81.100上的資料全部同步到192.168.81.101上，這就是全量複製的概念
5.1.2 offset的概念
偏移量(offset)就是資料寫入量的位元組數。
在192.168.81.100的Redis上寫入資料時，master就會記錄寫了多少資料，並記錄在偏移量中。
在192.168.81.100上的操作，會同步到192.168.81.101機器上，192.168.81.101上的Redis也會記錄偏移量。
當兩臺機器上的偏移量相同時，代表資料同步完成
偏移量是部分複製很重要的依據
檢視192.168.81.100機器上Redis的偏移量
127.0.0.1:6379> info replication # 檢視複製資訊
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.81.101,port=6379,state=online,offset=8602,lag=0
master_repl_offset:8602 # 此時192.168.81.100上的偏移量是8602
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:8601
127.0.0.1:6379> set k1 v1 # 向192.168.81.100寫入資料
OK
127.0.0.1:6379> set k2 v2 # 向192.168.81.100寫入資料
OK
127.0.0.1:6379> set k3 v3 # 向192.168.81.100寫入資料
OK
127.0.0.1:6379> info replication # 檢視複製資訊
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.81.101,port=6379,state=online,offset=8759,lag=1
master_repl_offset:8759 # 寫入資料後192.168.81.100上的偏移量是8759
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:8758檢視192.168.81.101機器上Redis的偏移量
127.0.0.1:6379> info replication # 檢視複製資訊
# Replication
role:slave
master_host:192.168.81.100
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:8602
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0 # 此時192.168.81.101上的偏移量是8602
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> get k3
"v3"
127.0.0.1:6379> info replication # 檢視複製資訊
# Replication
role:slave
master_host:192.168.81.100
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:8759 # 同步資料後192.168.81.101上的偏移量是8759
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0如果主從節點上的offset差距太大，說明從節點沒有從主節點同步資料，主從節點之間的連接出現問題：比如網路，阻塞，緩衝區等
5.1.3 全量複製的概念
如果一個主節點上已經寫入很多資料，此時從節點不僅同步已經有的資料，同時同步slave在同步期間master上被寫入的資料(如果在同步期間master被寫入資料)，以達到資料完全同步的目的，這就是Redis的全量複製的功能
Redis的master會把當前的RDB檔案同步給slave,在此期間master中寫入的資料會被寫入複製緩衝區(repl_back_buffer)中，當RDB檔案同步到slave完成，master通過偏移量的對比，把複製緩衝區(repl_back_buffer)中的資料同步給slave
Redis使用psync命令進行資料全量複製和部分複製
psync命令有兩個引數：run_id和偏移量
psync命令的步驟：
1.在slave第一次向master同步資料時，不知道master的run_id和offset，使用`psync ? -1`命令向master發起同步請求
2.master接受請求後，知道slave是做全量複製，master就會把run_id和offset響應給slave
3.slave儲存master傳送過來的run_id和offset
4.master響應slave後，執行BGSAVE命令把當前所有資料生成RDB檔案，然後將RDB檔案同步給slave
5.Redis中的repl_back_buffer複製緩衝區可以記錄生成RDB檔案之後到同步完成這個時間段時寫入的資料，然後把這些資料也同步給slave
6.slave執行flushall命令清空slave中原有的資料，然後從RDB檔案讀取所有的資料，保證slave與master中資料的同步如下圖所示：
5.1.4 全量複製的開銷
- 全量複製的開銷非常大
- master執行BGSAVE命令會消耗一定時間
- BGSAVE命令會fork子程序，對CPU，記憶體和硬碟都有一個消耗
- master將RDB檔案傳輸給slave的時間,傳輸過程中也會佔用一定的網路頻寬
- slave清除原有資料的時間,如果slave中原有資料比較多，清空原有資料也會消耗一定的時間
- slave載入RDB檔案會消耗一定時間
-
可能的AOF檔案重寫的時間：RDB檔案載入完成，如果slave節點的AOF功能開啟，則會執行AOF重寫操作，保證AOF檔案中儲存最新的資料
5.4 全量複製的問題
除了上面提到的開銷，如果master和slave之間的網路出現問題，則在一段時間內slave上同步的資料就會丟失
解決這個問題的最好辦法就是再做一次全量複製，同步master中所有資料
Redis 2.8版本中添加了部分複製的功能，如果發生master和slave之間的網路出現問題時，使用部分複製儘可能的減少丟失資料的可能，而不用全部複製
5.2 部分複製
當master與slave之間的連線斷開時，master在寫入資料同時也會把寫入的資料儲存到repl_back_buffer複製緩衝區中
當master與slave之間的網路連通後，slave會執行psync {offset} {run_id}命令,offset是slave節點上的偏移量
master接收到slave傳輸的偏移量，會與repl_back_buffer複製緩衝區中的offset做對比，
如果接收到的offset小於repl_back_buffer中記錄的偏移量，master就會把兩個偏移量之間的資料傳送給slave，slave同步完成，slave中的資料就與master中的資料一致
如下圖所示
6. 主從複製故障
6.1 slave宕機
這種架構讀寫分離情況下，宕機的slave無法從master中同步資料
6.2 master宕機
Redis的master就無法提供服務了，只有slave可以提供資料讀取服務
解決方法：把其中一個slave為成master,以提供寫入資料功能，另外一臺slave重新做為新的master的從節點，提供讀取資料功能，這種解決方法依然需要手動完成
主從模式沒有實現故障的自動轉移，這就是Redis的sentinel的作用了
7.開發運維常見的問題
7.1 讀寫分離
讀寫分離：master負責寫入資料，把讀取資料的流量分攤到slave節點
讀寫分離一方面可以減輕master的壓力，另一方面又擴充套件了讀取資料的能力
讀寫分離可以遇到的問題：
7.1.1 複製資料延遲
大多數情況下，master採用非同步方式將資料同步給slave，在這個過程中會有一個時間差
當slave遇到阻塞時，接收資料會有一定延遲，在這個時間段內從slave讀取資料可能會出現資料不一致的情況
可以對master和slave的offset值進行監控，當offset值相差過多時，可以把讀流量轉換到master上，但是這種方式有一定的成本
7.1.2 讀到過期資料
Redis刪除過期資料的方式
方式一：懶惰策略
當Redis操作這個資料時，才會去看這個資料是否過期，如果資料已經過期，會返回一個-2給客戶端，表示查詢的資料已經過期方式二：
每隔一個週期，Redis會採集一部分key,看這些key是否過期
如果過期key非常多或者取樣速度慢於key過期速度時，就會有很多過期key沒有被刪除
此時slave會同步包括過期key在內的master上的所有資料
由於slave沒有刪除資料的許可權，此時基於讀寫分離的模式，客戶端會從slave中讀取一些過期的資料，也即髒資料7.1.3 從節點故障
在圖9中，slave宕機，從slave節點遷移為master節點的成本很高
在考慮使用讀寫分離之前，首先要考慮優化master節點的問題
Redis的效能很高，可以滿足大部分場景，可以優化一些記憶體的配置引數或者AOF的策略，也可以考慮使用Redis分散式
7.2 主從配置不一致
第一種情況是：例如maxmemory不一致：丟失資料
如master節點分配的記憶體為4G，而slave節點分配的記憶體只有2G時，此時雖然可以進行正常的主從複製
但當slave從master同步的資料大於2G時，slave不會丟擲異常，但會觸發slave節點的maxmemory-policy策略，對同步的資料進行一部分的淘汰，此時slave中的資料已經不完整了，造成丟失資料的情況
另一種主從配置不一致的情況是：對master節點進行資料結構優化，但是沒有對slave做同樣的優化，會造成master和slave的記憶體不一致
7.3 規避全量複製
7.3.1 全量複製的開銷是非常大的
第一次為一個master配置一個slave時，slave中沒有任何資料，進行全量複製不可避免
解決方法：主從節點的maxmemory不要設定過大，則傳輸和載入RDB檔案的速度會很快，開銷相對會小一些，也可以在使用者訪問量比較低時進行全量複製
7.3.2 節點run_id不匹配
當master重啟時，master的run_id會發生變化。slave在同步資料時發現之前儲存的master的run_id與現在的run_id不匹配，會認為當前master不安全
解決方法：
做一次全量複製,當master發生故障時，slave轉換為master提供資料寫入，或者使用Redis哨兵和叢集Redis4.0版本中提供新的方法：當master的run_id發生改變時，做故障轉移可以避免做全量複製
7.3.3 複製緩衝區不足
複製緩衝區的作用是把新的命令寫入到緩衝區中
複製緩衝區實際是一個佇列，預設大小為1MB，即複製緩衝區只能儲存1MB大小的資料
如果slave與master的網路斷開，master就會把新寫入的資料儲存到複製緩衝區中
當寫入到複製緩衝區內的資料小於1MB時，就可以做部分複製，避免全量複製的問題
如果新寫入的資料大於1MB時，就只能做全量複製了在配置檔案中修改rel_backlog_size選項來加大複製緩衝區的大小，來減少全量複製的情況出現
7.4 規避複製風暴
主從架構中，master節點重啟時，則master的run_id會發生變化，所有的slave節點都會進行主從複製
master生成RDB檔案，然後所有slave節點都會同步RDB檔案，在這個過程中對master節點的CPU，記憶體，硬碟有很大的開銷，這就是複製風暴
單主節點複製風暴解決方法
更換複製拓樸
單機多部署複製風暴
一臺伺服器上的所有節點都是master，如果這臺伺服器系統發生重啟，則所有的slave節點都從這臺伺服器進行全量複製，會對伺服器造成很大的壓力
主節點分散多機器
將master分配到不同的伺服器上Redis的主從模式簡單總結
一個master可以有多個slave
一個slave還可以有slave
一個slave只能有一個master
資料流向是單向的，只能從master到slave