记录一次生产事故

事故描述

新上线的功能（自选股小秘书、牛人智投和卖方金股）访问量过大，达到每分钟22w的并发量，导致大数据小秘书接口无法响应，也连带导致别的模块加载慢。

事故原因

1. APP端3秒轮询过于频繁，且Android在退到后台后，仍然在请求调用接口，并发量最大达到每分钟22w
2. 大数据端的自选股小秘书接口设计问题，采用遍历自选股的方式访问Redis，导致一次调用会产生大量的Redis访问请求，严重降低了接口性能；
3. 小秘书接口和牛人智投、卖方金股接口在一个服务里面，小秘书的巨大访问量压力，导致牛人智投、卖方金股的服务也无法正常响应；

解决措施

1. APP端修复了Android版本在后台持续请求的缺陷，并调慢了访问频率，由3s降低成1分钟，强制更新Android包，并发量降低到每分钟2000~3000并发；
2. 小秘书接口和别的模块做了服务分离，互不影响，优先保证牛人智投，卖方金股能够正常运行；
3. 针对小秘书逐条访问的方式做了优化，改成批量访问Redis，性能提高了40~300倍（根据并发量而不同），最终解决了小秘书性能慢的问题；
4. 针对该功能模块，统计实际的生产用户访问量，

知识点补充

1. Redis协议采取的是客户端-服务端方式，即在一次round trip中，客户端发送一条指令，服务端解析指令并执行，然后向客户端返回结果。这是一种典型的tcp交互方式。

• socket IO导致的上下文切换开销（严重读写系统开销）

  一次Redis请求在客户端和服务端分别至少会存在一次read（）和一次write（），作为系统调用。read/write的成本高于普通的函数调用，因此，在单个命令重复调用场景下，大量的read/write系统调用会产生明显的系统开销。

• （高并发下）资源竞争和系统调度开销（Redis竞争抖动）

客户端的影响非常明显。在高压力下，如果采用循环（loop）方式调用多次指令来完成某个服务请求，那么在高并发下，多个请求会在多个线程中同时竞争Redis链接资源多次，导致连接池压力增加，线程上下文切换更加频发，最终会导致请求RTT(round-trip time)急剧恶化。如果每个请求只抢占一次Redis链接并通过批量执行的方式一次处理多个请求，则单词请求的RTT会有显著提升。
在服务端，因为我们通常将Redis绑定到CPU（不管是通过物理机还是docker），因此一般而言不存在系统调度/资源竞争的开销。但是由于Redis对QPS敏感，如果因为客户端使用不合理而造成QPS放大效应，则Redis可能更早初级性能瓶颈而导致系统响应严重下降。

2. 批量命令(Redis对应的命令)

• mget(适用于string类型)
• mset(适用于string类型)
• hmget(适用于hash类型)
• hmset(适用于hash类型)

严格来说以上命令不属于批量操作，而是在一个指令中处理多个key。

• 优势：性能优异，因为是单条指令操作，因此性能略优于其它批量操作指令；
• 劣势：批量命令不保证原子性，存在部分成功部分失败的情况，需要应用程序解析返回的结果并做相应处理