实例基础信息：

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造成的（请参考https://www.jianshu.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有可能会自动删除了）