背景

多个服务同时出现latency SEV2问题，这些服务都依赖远程缓存Redis存储的数据，而且Redis硬盘使用率也出现报警，经过排查发现Redis有4台host停止对外服务，另外其中一个node变成1主11从配置，而非默认的1主4从。

客户影响

1. 大概有0.1%的traffic在30min超过latency阈值，会导致上游服务部分请求超时。
2. 一个节点大部分数据丢失，会增加部分访问的latency。

分析&结论

1. 由于Redis的一台host出现问题，被健康检测系统用新的host（M5）替换，其连接到Master（M1）之后，触发M1的BGSAVE，但M5同步数据失败，不过由于配置原因(replica-serve-stale-data 为true)，其仍然可以对外提供服务，不过由于其没有完成数据同步，所以无有效数据可以读取，所以traffic会穿透到Sable，从而导致latency增加。
2. 同时这些traffic会触发大量写M1操作，引发大量AOF操作，导致内存使用增加，之后被OOM killer杀掉，多次反复此过程，从而导致内存波动，但由于硬盘数据未清理，故硬盘使用量持续增加，之后进行RDB操作，导致硬盘使用量快速增加，引发RDB进程反复重试报错，但这段时间由于没有AOF操作，所以内存并无变化，之后硬盘被服务器清理后，AOF开始工作，内存开始急剧降低，内存过低引发master连接超时。
3. 由于cluster-node-timeout配置为15000，故超时15s后，会触发Redis节点的选举操作，大概5s左右完成选举；由于在lettuce client中， DEFAULT_REFRESH_PERIOD被配置为60s，所以在60s内，lettuce client会感知到master的选举结果，换句话就是从Redis server超时，选举到client完成更新大概需要1min20s左右，在此过程中这个节点无法对外提供服务，故引发latency的peak。
4. 由于M5一直未成功从master同步数据，所以所有到M5的traffic都会访问sable，并会进行master 写操作，所以服务latency P99.9一直比较高，最终M5被选举为master，其他4台host被OOM  killer杀掉，不再对外提供服务。
5. 由于M5变成 orphaned  master, 其他slot会迁移slave到M5，确保M5的可用行，从而导致M5变为1主10从。

MemUsable/latency metric:

Cache miss traffic metric:

时间线

17:11 ~18:30 01/03 UTC (M1, M2, M3, M4, M5 按照顺序被选为master)

1. 17:11:55 a host with issue is replaced by M5.
2. 17:15:08 (M5) Connecting to MASTER (M1) and MASTER(M1) ↔ REPLICA(M5) sync started.
3. 17: 15 Redis cache miss/Client latency increased.
4. 17: 21:56 (M2) Failover election won: I'm the new master.
   1. (service) 17:21:35,717-17:22:43  ***RedisCommandTimeoutException: Command timed out after 50 millisecond(s)
5. 18:22:54 (M3) Failover election won: I'm the new master.
   1. (service) 18:22:35,922-18:23:43,136 ***RedisCommandTimeoutException: Command timed out after 50 millisecond(s)
6. 18:27:31 (M4) Failover election won: I'm the new master.
   1. (service) 18:27:08,999-18:27:43,317 ***RedisCommandTimeoutException: Command timed out after 50 millisecond(s)
7. 18:30:22 (M5) Failover election won: I'm the new master.
   1. (service) 18:29:57-18:31:40,727 ***RedisCommandTimeoutException: Command timed out after 50 millisecond(s)
8. 18:30:51 Every clusters migrates a host to orphaned master(M5), then M5 has 11 slaves.
9. 18:30: Redis cache miss/Client latency return back to normal.

问题

        为什么master生成前会有20s 左右的Command timed out exception?

在Redis配置文件中有一个参数cluster-node-timeout（15000ms），他表示节点不可访问的毫秒数。当master不可访问状态超过15000ms时，会开始选举，从上面的统计数据估计需要5s左右完成选举，并产生master。

        为什么master生成后会有不到1min左右的Command timed out exception?

        Service使用Lettuce作为客户端访问Redis数据，其通过ClusterTopologyRefreshOptions.DEFAULT_REFRESH_PERIOD设置周期拓扑刷新参数，并使用默认值60s，所有在服务端拓扑更新后，客户端未完成拓扑刷新前会报此异常。

        默认是1主4从配置，为什么会出现1主11从？

Redis有一个机制叫replicas migration，它会迁移replicas到orphaned master（无副本的master）, 从而确保cluster有更好的可用行。

        OOM killer杀掉OOM的进程后会马上影响MemUsable吗？

通过实际处理过程来看，OOM killer完成操作与进程停止工作之间的时间差可能在0-15min之间。

        新的Replicas完成添加后，什么时间开始处理实际流量？

Redis配置文件中的replica-serve-stale-data指令用于指定当主从复制失去连接，或者主从节点正在同步数据，是否从从节点响应客户端的读请求，默认是yes表示从库会继续响应客户端的读请求；如果设置的no，除去指定点命令之外的任何请求都会返回一个错误“sync with master in progress”。

参考link

1. RedisCluster集群模式下master宕机主从切换期间Lettuce连接Redis无法使用报错Redis command timed out的问题 | 码农家园
2. 【故障演练】 Redis Cluster集群，当master宕机，主从切换，客户端报错 timed out_redis集群master宕机_微观技术的博客-CSDN博客
3. https://blog.csdn.net/s_lisheng/article/details/82192613/

最后

以上就是听话跳跳糖为你收集整理的Redis OOM 问题排查背景客户影响分析&结论时间线问题参考link的全部内容，希望文章能够帮你解决Redis OOM 问题排查背景客户影响分析&结论时间线问题参考link所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。