最好弃用redis命令key *
最近在伯乐上看到一篇文章,说的是redis命令keys *o*对项目造成的宕机:
背景:
整个过程如下:
- 监控报警，显示RDS的CPU使用率达到80%以上，DBA介入，准备KILL慢SQL
- 1分钟内，没有发现明显阻塞的SQL，CPU持续上升到99%
- 5分钟内，大量应用报警，并且拒绝服务，RDS的监控显示出现大量慢SQL，联系服务器数据库提供商进行协助
- 8分钟内，进行数据库主备切换（业务会受损，但是也没办法，没有定位到问题）
- 9分钟内，部分业务恢复，但是一些业务订单的回调消息堆积超过20w，备库的CPU使用率也持续上升
- 15分钟内，备库CPU使用率超过97%，业务再次中断，进行切回主库，并进行限流
- 20分钟内，关闭一些次要应用的流量入口
- 25分钟内，主库CPU使用率恢复正常
- 30分钟内，逐步开启关闭的限流应用
- 35分钟内，所有应用恢复正常
- 接下来就是与服务器数据库提供商成立应急小组紧急优化可能出现的慢SQL，虽然说可能解决了一些慢SQL，但此次并没有定位到具体的问题，也就为几天后再次发生宕机事件埋下了伏笔
后果
服务化项目不可用几十分钟,订单数减少几十万笔,直接损失金额上百万
原因分析处理:
针对每个应用单独建一个数据库账号,严格规范使用
缓存优化方案即使落地,慢sql问题优先处理(查询时间超过1S)
虽然进行优化,但是结果并不会有变化,主要症状并没有找到,谁也不会保证后面还会出现
最后原因就是由于 redis 的 keys *..*命令造成,内存飙升,
执行keys命令,redis会锁定,如果数据量稍微大点锁几秒,对于生产服务器也是灾难性的了
解决方案:
从redis的官方文档上看，2.8版本之后SCAN命令已经可用，允许使用游标从keyspace中检索键。对比KEYS命令，虽然SCAN无法一次性返回所有匹配结果，但是却规避了阻塞系统这个高风险，从而也让一些操作可以放在主节点上执行。
需要注意的是，SCAN 命令是一个基于游标的迭代器。SCAN 命令每次被调用之后， 都会向用户返回一个新的游标，用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数， 以此来延续之前的迭代过程。同时，使用SCAN，用户还可以使用keyname模式和count选项对命令进行调整。SCAN相关命令还包括SSCAN 命令、HSCAN 命令和 ZSCAN 命令，分别用于集合、哈希键及有续集等。
另一方面，使用redis的时候一定要注意控制key，对于key的命令要制定一个完善的方案，这样才能对redis里面的数据可控，避免出现没用数据长时间占据数据库这种情况，也可以避免上面说的这种查询键值的操作。
虽然只是一个小小的命令,但是作为一名开发者来说,这是必须要避免的,虽然只是一个小小的命令,但是造成的后果往往是巨大的.
告诫所有的开发者,官方文档还是要经常看看
- 版权申明：此文如未标注转载均为本站原创，自由转载请表明出处《龙行博客》。
- 本文网址：https://www.liaotaoo.cn/145.html
- 上篇文章：Linux 搜索文件和文件夹的 4 种常用简单方法
- 下篇文章：本站一年不到终上权2,立个杯
