實例基礎信息：
redis版本：redis-cli 3.2.5
架構：傳統主從架構
背景
好多天沒有登陸某套redis主從進行查看了，某天redis磁盤容量報警，上去排查磁盤容量報警問題時偶然發現一個大問題，redis主庫key數量與redis從庫key數量差別非常大(db0 差5685023個)，如圖：
WeChat_1522719374.jpeg
WeChat_1522719328.jpeg
問題定位
- 1）可能是過期key未及時刪除導致主從key數量不一致，之前遇到過redis主從key數量不一致，以為是過期key造成的（請參考http://www.lxweimin.com/writer#/notebooks/19390605/notes/20403782），于是對主庫、從庫分別進行了scan 0 count 1000000掃描清除過期但未被刪除的key，清除完畢后主從對比，與截圖相比差距基本類似，可以判斷這次主從key數量不一致不是由于過期key造成的。
- 2）可能是主從復制通道異常導致主從key數量不一致，info查看master、slave復制信息，發現復制通道是正常的，原因如下：
#主庫端
role:master
connected_slaves:1
slave0:ip=192.168.26.22,port=6379,state=online,offset=297300434582,lag=0
# 從庫端
role:slave
master_host:192.168.26.21
master_port:6379
master_link_status:up
- 3）可能是主從復制延遲導致主從key數量不一致，通過查看主從復制偏移量，發現復制偏移量基本正常，原因如下：
#主庫端
role:master
connected_slaves:1
slave0:ip=192.168.26.22,port=6379,state=online,offset=297614050284,lag=0
master_repl_offset:297614059914
repl_backlog_active:1
repl_backlog_size:104857600
repl_backlog_first_byte_offset:297509202315
repl_backlog_histlen:104857600
#偏移量計算（復制偏移量僅僅差9630 byte,而實際的key差距是50多萬，肯定不是這復制偏移量造成的）
MariaDB [(none)]> select 297614059914 -297614050284;
+----------------------------+
| 297614059914 -297614050284 |
+----------------------------+
| 9630 |
+----------------------------+
#從庫端
# Replication
role:slave
master_host:192.168.26.21
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:297610328994
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:104857600
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
- 4）這時沒有思路了，就仔細看看主從各自info信息，這時候發現一個大問題，主從內存占用差距太大，信息如下：
#主庫Memory
used_memory:7783990712
used_memory_human:7.25G
used_memory_rss:8958046208
used_memory_rss_human:8.34G
used_memory_peak:7855643336
used_memory_peak_human:7.32G
total_system_memory:16827678720
total_system_memory_human:15.67G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:10737418240
maxmemory_human:10.00G
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.15
mem_allocator:jemalloc-4.0.3
#從庫Memory
used_memory:1073784176
used_memory_human:1.00G
used_memory_rss:1381617664
used_memory_rss_human:1.29G
used_memory_peak:1090530808
used_memory_peak_human:1.02G
total_system_memory:16827678720
total_system_memory_human:15.67G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:1073741824
maxmemory_human:1.00G
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.29
mem_allocator:jemalloc-4.0.3
查看主從配置文件信息如下：
#主庫
maxmemory 10gb
maxclients 40000
maxmemory-policy noeviction
#從庫
maxmemory 1gb
maxclients 40000
maxmemory-policy noeviction
#主從內存不一樣原因：redis之前內存硬件升級，沒有更改從庫的配置文件，后期從庫重啟過
思考
通過排查定位到造成主從key數量不一致的原因就是從庫升級內存當時沒有更改配置文件，從庫數據超過了配置的內存，但是自己服務器配置的內存滿后的策略是noeviction，表示滿了以后不能繼續往里面寫入了，但是自己通過從庫info replication發現從庫的偏移量還是改變的，這說明從庫還是繼續寫入的，為了證明這個想法，手動在主庫設置了key，發現從庫竟然同步過來了，這說明從庫這時是能正常復制主庫的更新的。
redis maxmemory-policy策略介紹
A002817AC08654551D0CA4466C628B79.jpg
疑問
- 為什么從庫設置了maxmemory-policy noeviction參數后，從庫內存滿了仍能正常復制寫入數據，按照maxmemory-policy介紹，此時從庫的redis是不能寫入數據了啊（這塊自己還沒有想明白）
總結（maxmemory-policy noeviction策略下）
- redis 從庫內存滿了主從復制不會斷開
- redis 從庫內存滿了，數據會繼續同步，偏移量會繼續增長
- maxmemory-policy noeviction策略對于主庫生效，對于從庫即使數據大于配置的內存，復制也能正常進行，數據能夠正常同步（從庫的key會根據某種策略自動刪除）
- redis主從監控目前只能做到復制通道是否正常，但是不能監控主從數據是否一致，即使偏移量相同也不能證明主從數據一致（從庫的key有可能會自動刪除了）
