记录一次生产事故

事故描述

新上线的功能(自选股小秘书、牛人智投和卖方金股)访问量过大,达到每分钟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可能更早初级性能瓶颈而导致系统响应严重下降。

  1. 批量命令(Redis对应的命令)
  • mget(适用于string类型)
  • mset(适用于string类型)
  • hmget(适用于hash类型)
  • hmset(适用于hash类型)

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

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

你可能感兴趣的:(记录一次生产事故)