Toggle navigation
面试宝典
架构师课程
开源
文章
博客
SpringCloud
CloudAlibaba
SpringBoot
Spring Boot1.X
Spring Boot2.X
关于
登录
|
注册
支付宝扫一扫帮助发展吧~
微信扫一扫帮助发展吧~
技术方案最佳实践
1.上线稳定性如何保...
2.稳定性保障,如何...
3.binlog真的是银...
4.缓存Bigkey坚决...
5.核心接口隔离,要...
6.每次上线都要加字...
7.ON UPDATE CU...
8.服务优雅下线,没...
9.Mybatis插件,...
10.在线进行分库分表...
11.深度分页,我都是这么玩的
缓存Bigkey坚决不要用,拆分是王道
尹吉欢
2021-12-25 14:05:59.0
0条评论
1078人阅读
版权声明:转载请先联系作者并标记出处。
实战经验
点击阅读全文
上一篇:binlog真的是银弹吗?有些时候也让人头疼
下一篇:核心接口隔离,要做哪些事情?
扫描下方二维码,加入Java方向技术交流讨论群。暗号:加群
去注册
去登录
登录后发表
去注册
去登录
登录后发表
大家好,我是架构摆渡人。这是实践经验系列的第四篇文章,这个系列会给大家分享很多在实际工作中有用的经验,如果有收获,还请分享给更多的朋友。 # 背景介绍 在高并发的业务场景中,缓存是必须要上的,用来扛高并发。在某个业务场景中,增加了对一个配置信息的缓存,最开始是直接读取DB的,为了性能考虑在前面加了一层缓存。 加完后很长一段时间也没问题,DB的压力也减小了很多。不幸的是在某天的一个时间点内,流量增加了好几倍,RT直线上升,接口各种超时,就这样,一个线上故障诞生了。 整个过程持续了1分钟左右,监控告警稍微有点延迟,刚看完监控告警,准备介入处理时流量已经跌下来了,接口也恢复了正常。 事后,通过监控发现接口超时的原因是因为底层Redis超时了,说到这可能大家都抱着怀疑的态度,Redis这么快也能超时?是的,你没看错,就是Redis超时了。 而Redis超时的原因并不是说Redis性能不行,而是在同一时刻有大量的请求访问了同一个Key,这个Key缓存的内容很大,导致一瞬间就把网络带宽给占用完了,后续请求都进不来。 # 解决方案 ## 扩容带宽 直接扩容是最简单有效的方式,如果有
首次访问,人机识别
扫描下方二维码回复
王老吉
获取解锁验证码
步骤:[ 打开微信 ]->[ 扫描上方二维码 ]->[ 关注
猿天地
的公众号] 输入
王老吉
获取验证码,即可永久解锁本站全部文章。
验证码:
(请输入)
提交