高并发服务遇 redis 瓶颈引发的事故

元旦期间 订单业务线 告知 推送系统 无法正常收发消息，作为推送系统维护者的我正外面潇洒，无法第一时间回去，直接让 ops 帮忙重启服务，一切好了起来，重启果然是个大杀器。由于推送系统本身是分布式部署，消息有做各种的可靠性策略，所以重启是不会丢失消息事件的。

???? 事后通过日志分析有大量的 redis 的报错，十分钟内有 16w 次的错误。日志的错误是 connect: cannot assign requested address 。该错误不是推送服务内部及 redis 库返回的 error，而是系统回馈的 errno 错误。

这个错误是由于无法申请可用地址引起的，也就是无法申请到可用的 socket。

话说，元旦当天在线数和订单量确实大了不少，往常推送系统的长连接客户端在 35w，这次峰值飙到 50w 左右, 集群共 6 个节点，其中有 4 个节点每个都扛了 9w+ 的长连接。另外，推送的消息量也随之翻倍。

分析

下面是 kibana 日志的统计，出错的时间区间里有近 16w 次的 redis 报错。

下面是出问题节点的 TCP 连接状况