在这里讲述一下最近发生在我公司的事故，以及如何避免，并且如何处理优化。 该宕机的直接原因是使用 Redis 的 keys * 命令引起的，php应用 使用hgetall函式一共造成了某个服务化专案的两次宕机。

间接原因还有很多，技术跟不上业务的发展，由每日百万量到千万级是一个大的跨进，公司对于系统优化的处理优先级不高，技术开发人手的短缺。

第一次宕机

2018年9月13日的某个点，公司某服务化专案的 RDS 例项连线飙升，CPU 升到 100%，拒绝了其他应用的所有请求服务。

整个过程如下：

监控报警，显示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，但此次并没有定位到具体的问题，也就为几天后再次发生宕机事件埋下了伏笔

事故影响

某服务化专案服务不可用几十分钟，造成订单数减少几十万笔，损失百万资金。

原因分析

当时是没有定位到具体的原因的，但是下面的原因也是一部分可能引起宕机的情况。

某服务化专案的业务增速非常快，在高峰期，数据库QPS突破35000，系统处于高负荷状态。

在高峰期如果同时执行几个全表扫描的SQL，会造成数据库压力急剧上升，应用超时增多，前端应用超时，使用者重试，流量飙升，形成了雪崩效应。

主要原因在与一些老专案的SQL查询效能较差，并且使用的主库，对数据库影响较大。数据库QPS太高，但是快取方案因为人手原因一直没有落地，慢SQL的问题处理优先级应该提升。

改进方案

针对每个应用建一个数据库账号，严格按照规范使用

快取优化方案即时落地，慢SQL问题优先处理，集中处理目前已经发现的慢SQL（查询时间超过1S）

升级数据库配置

迁移非核心业务到新的RDS例项中去

第二次宕机

由于上一次的宕机原因未找到，所以此次的宕机是可以预见的。

20180919，还是一样的”配方”，还是原来的”味道”。同一个RDS，CPU飙升至100%，接下来就是拒绝服务，宕机。当然，有了第一次的经验，直接主从切换，在几十秒左右就恢复了所有业务，但还是严重影响了公司的业务和形象

原因分析

恢复业务后，公司紧急召开了紧急事故研究会议，当然，我的级别是参与不了的。公司的高管，高层技术架构、DBA、各个专案的主负责人一起进行了会议。

在此次会议中，经过检视各个专案的日志，后台的监控资料，发现在那台RDS数据库CPU飙升时，有一台Redis数据库内存将近100%，然后急剧下降。联络第一次的宕机情况，也是类似的。

接下来就是联络服务器数据库提供商，将那台Redis最近一周的命令全部调用出来，最后发现，在那个时间点运行了一条keys *...*命令。公司的一个工程师执行keys模糊的匹配命令是为了清理没用的键，但是没有考虑到keys *进行模糊匹配引发Redis锁，造成Redis锁住，CPU飙升，引起了所有呼叫链路的超时并且卡住，等Redis锁的那几秒结束，所有的请求流量全部请求到RDS数据库中，使数据库产生了雪崩，使数据库宕机。

改进方案

所有线上操作，全部要经过运维通过后方可执行，运维部门逐步快速收回各项许可权

新增Redis例项，进行分离

如果有使用类似keys正则命令需求，使用scan命令代替

总结

该事件中出现的两次事故，完全是由于人为操作引起的，如果那位工程师，看过Redis的开发规范，会发现是建议禁用keys命令的。另外，有线上的命令操作，一定要经过运维评估后方可进行操作，估计那个工程师是老员工吧，有许可权，然后直接就进行操作了。

另外，公司的业务发展确实很快，技术跟不上，这是非常非常危险的，极大的增加了宕机的概率。

在业务量不大的情况下，那位工程师的操作是完全没什么问题的，毕竟并发也不大，但是现在，随着公司的发展，业务量的成倍成倍增加，技术的扩充套件却没有随着增长那么快。

公司的技术人手不足也是一方面，绝大多数人都是边维护老专案边做新功能，但是对于专案的重构优化，人手却少了很多，专案优化的优先级不高，这也是很大的一个原因，极有可能出现类似的情况，新服务化构建迫在眉睫。

最后的最后，线上操作的任何一条命令，再小心也不为过。

因为由于你的一个符号而引起的事故可能是你所承担不起的

Redis开发建议

最后附上Redis的一些开发规范和建议：

1.冷热资料分离，不要将所有资料全部都放到Redis中

虽然Redis支援持久化，但是Redis的资料储存全部都是在内存中的，成本昂贵。建议根据业务只将高频热资料储存到Redis中【QPS大于5000】，对于低频冷资料可以使用MySQL/ElasticSearch/MongoDB等基于磁盘的储存方式，不仅节省内存成本，而且资料量小在操作时速度更快、效率更高！

2.不同的业务资料要分开储存

不要将不相关的业务资料都放到一个Redis例项中，建议新业务申请新的单独例项。因为Redis为单执行绪处理，独立储存会减少不同业务相互操作的影响，提高请求响应速度；同时也避免单个例项内存资料量膨胀过大，在出现异常情况时可以更快恢复服务！ 在实际的使用过程中，redis最大的瓶颈一般是CPU，由于它是单执行绪作业所以很容易跑满一个逻辑CPU，可以使用redis代理或者是分散式方案来提升redis的CPU使用率。

3.储存的Key一定要设定超时时间

如果应用将Redis定位为快取Cache使用，对于存放的Key一定要设定超时时间！因为若不设定，这些Key会一直占用内存不释放，造成极大的浪费，而且随着时间的推移会导致内存占用越来越大，直到达到服务器内存上限！另外Key的超时长短要根据业务综合评估，而不是越长越好！

4.对于必须要储存的大文字资料一定要压缩后储存

对于大文字【+超过500字节】写入到Redis时，一定要压缩后储存！大文字资料存入Redis，除了带来极大的内存占用外，在访问量高时，很容易就会将网络卡流量占满，进而造成整个服务器上的所有服务不可用，并引发雪崩效应，造成各个系统瘫痪！

5.线上Redis禁止使用Keys正则匹配操作

Redis是单执行绪处理，在线上KEY数量较多时，操作效率极低【时间复杂度为O(N)】，该命令一旦执行会严重阻塞线上其它命令的正常请求，而且在高QPS情况下会直接造成Redis服务崩溃！如果有类似需求，请使用scan命令代替！

6.可靠的讯息伫列服务

Redis List经常被用于讯息伫列服务。假设消费者程式在从伫列中取出讯息后立刻崩溃，但由于该讯息已经被取出且没有被正常处理，那么可以认为该讯息已经丢失，由此可能会导致业务资料丢失，或业务状态不一致等现象发生。

为了避免这种情况，Redis提供了RPOPLPUSH命令，消费者程式会原子性的从主讯息伫列中取出讯息并将其插入到备份伫列中，直到消费者程式完成正常的处理逻辑后再将该讯息从备份伫列中删除。同时还可以提供一个守护程序，当发现备份伫列中的讯息过期时，可以重新将其再放回到主讯息伫列中，以便其它的消费者程式继续处理。

7.谨慎全量操作Hash、Set等集合结构

在使用HASH结构储存物件属性时，开始只有有限的十几个field，往往使用HGETALL获取所有成员，效率也很高，但是随着业务发展，会将field扩张到上百个甚至几百个，此时还使用HGETALL会出现效率急剧下降、网络卡频繁打满等问题【时间复杂度O(N)】,此时建议根据业务拆分为多个Hash结构；或者如果大部分都是获取所有属性的操作,可以将所有属性序列化为一个STRING型别储存！同样在使用SMEMBERS操作SET结构型别时也是相同的情况！

8.根据业务场景合理使用不同的资料结构型别

目前Redis支援的数据库结构型别较多：字串（String），杂凑（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog和地理空间索引（geospatial）等,需要根据业务场景选择合适的型别。

常见的如：String可以用作普通的K-V、计数类；Hash可以用作物件如商品、经纪人等，包含较多属性的资讯；List可以用作讯息伫列、粉丝/关注列表等；Set可以用于推荐；Sorted Set可以用于排行榜等！

9.命名规范

虽然说Redis支援多个数据库（预设32个，可以配置更多），但是除了预设的0号库以外，其它的都需要通过一个额外请求才能使用。所以用字首作为名称空间可能会更明智一点。

另外，在使用字首作为名称空间区隔不同key的时候，最好在程式中使用全域性配置来实现，直接在程式码里写字首的做法要严格避免，这样可维护性实在太差了。

如：系统名:业务名:业务资料:其他

但是注意，key的名称不要过长，尽量清晰明了，容易理解，需要自己衡量

10.线上禁止使用monitor命令

禁止生产环境使用monitor命令，monitor命令在高并发条件下，会存在内存暴增和影响Redis效能的隐患

11.禁止大string

核心丛集禁用1mb的string大key(虽然redis支援512MB大小的string)，如果1mb的key每秒重复写入10次，就会导致写入网络IO达10MB;

12.redis容量

单例项的内存大小不建议过大，建议在10~20GB以内。

redis例项包含的键个数建议控制在1kw内，单例项键个数过大，可能导致过期键的回收不及时。

13 可靠性

需要定时监控redis的健康情况：使用各种redis健康监控工具，实在不行可以定时返回redis 的 info资讯。

客户端连线尽量使用连线池（长连结和自动重连）