1.现状描述

1.1.生产环境

生产环境配置6套 Redis 服务。

1、配置为3节点物理服务器的 Redis 缓存群集，通过控制应用的主、备处于不同的物理服务器实现 Redis 访问的高可用，按不同的应用访问配置对应的内存大小。

2、单台物理服务器的 Redis 服务，主要用于应急备用资源。

【资料图】

3、配置为3节点的虚拟服务器 Redis 集群，用于电商类应用。

4、单独配置的IOT、智能门店、会员应用的缓存资源，使用 6.0.5版本。

生产环境的物理服务器群集采用 SSD 盘配置，Redis 的版本为4.0.1，硬盘同步的模式采用 AOF 数据持久化配置；

虚拟群集的Redis 版本为 6.0.5，取消 AOF 持久化配置，启用新版本的多线程功能。

4、生产环境的 Redis 服务器集群配置开源性能监控软件cacheCloud，通过GUI图形方式呈现群集的慢查询情况。

1.2.测试环境

试环境配置3台 Redis 虚拟群集，在6月初配置升级为 6.0.5版本（由4.x 升级到 6.x）。版本升级完成后测试环境的应用数据访问无异常。

2.故障现象

Redis主从频繁切换导致业务访问异常，出现无法登录或页面无响应的情况

3.故障原因

1、群集启用持久化配置，磁盘写入频繁导致主从检查超时引起自动切换

2、业务程序代码缓冲池占用链接过多不释放

3、Redis资源应用不规范，将缓存服务器当数据库使用

4.问题分析

4.1.Redis AOF 存在IO瓶颈

集群采用 RDB 与 AOF 双持久化的机制。其中RDB平均约2分钟运行一次，持续时间为28秒，数据量为2700余万左右；而AOF实时记录写操作，对master资源占用更高。对Linux服务器进行监控，观察到15时左右写入操作峰值约100MB/s，存在瞬时数据写入压力

4.2.Redis 使用不规范

例如wmXXXX系列和openid系列大量使用根目录或者随机目录使用数据，未建立层级目录（如外卖系统做的就比较好，可以借鉴），导致无法通过工具查看redis中数据，首先不利于运维查看，其次也不利于监控维护。

超时时间设置为-1的（永不删除）的约占20%，超时时间大于1个小时的约占78%，两者相加共占98%。大量数据超时时间设置为-1，导致无法利用Redis自动回收数据机制，降低查询命中率，同时增加了数据的维护资源消耗。

4.3.Redis应用没有读写分离

网络资源消耗在主从切换时波动较大，切换时访问流量自动迁移至master节点，而slave节点几乎无访问。

除切换主从引发的流量异常增加外，选取7月10日1:00~11:00数据进行观察，观察到只有Master发生读写，Slave几乎无读写，只有数据同步引发的IO。

4.4.应用代码缓冲池应用不规范

代码缓冲池持续占用缓存服务器网络连接，影响缓存服务器整体网络性能

开发回收缓冲池后缓存群集稳定性提升（没有出现自动切换报警）。其中 192.168.0.203占用的连接数由1.36K降为30、192.168.0.218由372降为124。

4.5.电商应用

优化前（2020-7-28）

Sampled 202749 keys in the keyspace!Total key length in bytes is 8949425 (avg len 44.14)

Biggest string found "001:002:003:groupon:activity:indexlist:" has 949198 bytesBiggest list found "addoplog" has 6365167 itemsBiggest set found "001:002:003:store:groupstore:20" has 22013 membersBiggest hash found "alipay:mp:coupon_user_get_count" has 1291419 fieldsBiggest zset found "001:002:003:store:geo:channel:1" has 21310 members

135631 strings with 66782153 bytes (66.90% of keys, avg size 492.38)6449 lists with 6818691 items (03.18% of keys, avg size 1057.33)38894 sets with 2347603 members (19.18% of keys, avg size 60.36)21770 hashs with 1521001 fields (10.74% of keys, avg size 69.87)5 zsets with 76302 members (00.00% of keys, avg size 15260.40)

优化后

192.18.5.145:9020

Sampled 16701335 keys in the keyspace!

Total key length in bytes is 755221587 (avg len 45.22)

Biggest string found "portal.mp_coupon_allstorecodeV1" has 840115 bytesBiggest list found "groupon:activity_user_behavior_list" has 4047488 itemsBiggest set found "portal:mp:sendgiftbaguser:" has 4182827 membersBiggest hash found "alipay:mp:coupon_user_get_count" has 7822308 fieldsBiggest zset found "alipay:store:geo:temp" has 24579 members

14805770 strings with 1318411927 bytes (88.65% of keys, avg size 89.05)12479 lists with 4583765 items (00.07% of keys, avg size 367.32)3284 sets with 4499371 members (00.02% of keys, avg size 1370.09)1879799 hashs with 12640365 fields (11.26% of keys, avg size 6.72)3 zsets with 45714 members (00.00% of keys, avg size 15238.00)0 streams with 0 entries (00.00% of keys, avg size 0.00)

解决方案

1、调整缓存群集内存空间、调整系统硬盘配置参数等基于服务器硬件的调整

2、增加临时单主机独立的 Redis服务器配置，迁移部分业务，如电商应用部分功能

3、增加电商、会员、IOT、智能门店的独立Redis资源，独立缓存版本升级为 6.0.3，启用多线程支持。

4、增加服务器端口监控，调整业务程序代码；调整缓存持久化配置参数

5、迁移业务应用到独立缓存；会员、智能门店应用需要优化和调整代码。