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，可以實現統一配置
使用配置文件方式配置不變於管理，而且需要重啟Redis
4.4 例子
有兩台虛擬機，操作系統都是CentOS 7.5
一台虛擬機的IP地址為192.168.81.100,做master
一台虛擬機的IP地址為192.168.81.101,做slave
第一步：在192.168.81.101虛擬機操作
[root@mysql ~]# vi /etc/redis.conf # 修改Redis配置文件
bind 0.0.0.0 # 可以從外部連接Redis服務端
slaveof 192.168.81.100 6379 # 設置master的IP地址和端口
然后保存修改，啟動Redis
[root@mysql ~]# systemctl stop firewalld # 關閉firewalld防火牆
[root@mysql ~]# systemctl start redis # 啟動slave上的Redis服務端
[root@mysql ~]# 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
[root@mysql ~]# 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虛擬機上操作
[root@localhost ~]# systemctl stop firewalld # 關閉firewalld防火牆
[root@localhost ~]# vi /etc/redis.conf # 修改Redis配置文件
bind 0.0.0.0
然后保存修改，啟動Redis
[root@localhost ~]# systemctl start redis # 啟動master上的Redis
[root@localhost ~]# 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
[root@localhost ~]# 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的日志
[root@localhost ~]# 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的日志
[root@mysql ~]# 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 success
5.全量復制和部分復制
5.1 全量復制
5.1.1 run_id的概念
Redis每次啟動時，都有一個隨機ID來標識Redis,這個隨機ID就是上面通過info命令查看得到的run_id
查看192.168.81.101虛擬機上的run_id和偏移量
[root@localhost ~]# redis-cli info server |grep run_id
run_id:7e366f6029d3525177392e98604ceb5195980518
[root@localhost ~]# redis-cli info |grep master_repl_offset
master_repl_offset:0
查看192.168.91.100虛擬機上的run_id和偏移量
[root@mysql ~]# redis-cli info server | grep run_id
run_id:7091f874c7c3eeadae873d3e6704e67637d8772b
[root@mysql ~]# redis-cli info | grep master_repl_offset
master_repl_offset:4483
run_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