前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >由Redis的hGetAll函数所引发的一次服务宕机事件

由Redis的hGetAll函数所引发的一次服务宕机事件

作者头像
老_张
发布2019-12-02 19:08:42
1K0
发布2019-12-02 19:08:42
举报
文章被收录于专栏:老张的求知思考世界

昨晚通宵生产压测,终于算是将生产服务宕机的原因定位到了,心累。这篇文章,算作一个复盘和记录吧。。。先来看看Redis的缓存淘汰算法思维导图:

说明:当实际占用的内存超过Redis配置的maxmemory时,Redis就会根据用户选择淘汰策略清除被选中的key。

业务场景:用户通过微信入口来访问一个页面;

测试场景:通过多线程模拟定量的并发来访问页面服务;

涉及架构:springsession+Redis集群,容器部署;

问题描述:固定并发数压测10分钟,压测开始后半小时,Redis连接数激增,连接耗尽,服务重启;

处理逻辑:

①、用户通过入口页面访问服务时,springsession给每个用户创建一个session,将key存储在Redis中;

②、Redis默认配置每隔半小时,利用hGetAll函数遍历session-key所在的集合,将最近一分钟内要过期的key全部delete,释放内存;

宕机原因:

①、Redis是单线程处理,由于高并发压测,产生了百万级的key存储在set集合中,当hGetAll函数遍历集合删除过期session的key时,大量用户连接失效;

②、失效瞬间,Redis需要创建大量连接,如果TPS超过了设置的最大连接数,则Redis服务容器健康检查不通过;

③、通过选举,Redis集群主从切换时需要将master的数据复制到salve;

④、主从复制时,Redis定位区域buffer(软链接)超时,最终导致服务宕机重启。

优化方案:

①、选择Redis默认淘汰策略,每秒钟选择10次,每次不超过25个,即每秒钟淘汰≤250个key;

缺点:内存好用较高,需要通过横向扩展资源来应对该问题;

②、通过压测确定当前系统配置下的最大可处理阈值,通过网关限流、服务降级等措施来保障服务的稳定运行;

缺点:如果实际流量超过限流配置,则用户可能看到一些“友好界面”,用户体验不太好;

PS:在实际生产环境中,系统稳定性和可用性胜于一切!!!

以上就是此次问题复盘,虽然通宵带来的后遗症导致现在还有点迷糊,但从中学到了很多新的东西,值得思考与学习。。。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2018-12-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 老张的求知思考世界 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 Redis
腾讯云数据库 Redis(TencentDB for Redis)是腾讯云打造的兼容 Redis 协议的缓存和存储服务。丰富的数据结构能帮助您完成不同类型的业务场景开发。支持主从热备,提供自动容灾切换、数据备份、故障迁移、实例监控、在线扩容、数据回档等全套的数据库服务。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档