时延敏感业务低概率超时问题分析

前言

作为阿里云底层提供的基础设施，内部的物理网络和许多网络产品在数据平面给客户的可操作性并不高，从一定程度上来说是个黑盒。当然，在传统的IDC环境，业务和物理网络之间也存在同样的隔阂。所以在遇到业务卡顿、延迟、不通等问题的时候，很容易怀疑到网络。因此如何抽丝拨茧，找到正确的方向对症下药才能够真正的解决问题。毕竟“真相只有一个”。

在进行问题排查和处理的时候，难度最高的场景就是极度偶发，复现频率极低的问题。尤其在网络排查的领域，通常为了性能和控制资源消耗，不会将每一个数据包的情况都一一记录下来，对于一次偶发的应用层记录的超时，网络层通常没有明确的对应此次应用层调用的包交互记录，因此排查起来非常困难。

在这次的案例中，我们通过一个客户端查询redis集群偶发超时的小案例，来说明一些诊断思路、排查手段，进而引出一些在网络方面提高业务稳定性的最佳实践。

问题环境

这次的问题是一个交互性web应用中的一个子模块，主要进行redis查询，可以简单将其理解为视频弹幕网站中“查询弹幕”的小模块。这个模块的拓扑非常简单：

在上面的拓扑中，客户使用ECS构建了一个Redis集群，前面用Codis实现了一层Redis Proxy （为了通用性，后面均用Redis proxy来描述），并将这组Redis proxy挂载在一个SLB后，通过SLB的单一入口提供服务。

问题现象

客户的主要问题是访问其自建Redis系统的客户端会不定期出现超时报错，尽管总体概率不高，但是报错概率高于其业务运行在原有机房的水平。超时报错主要有两种情况：

1. 一般情况下超时数量与业务量呈正相关，非业务高峰期但是SLB、ECS的资源使用率均较低。
2. 会存在突发性的大量超时。

诊断思路

作为问题排查的第一步，首先要了解到问题本身所处的上下文和环境。在平时诊断问题收集信息的时候，为了有条理的、全面的收集信息，笔者将需要收集的信息分为两种类型：资源因素和环境因素。

• 资源因素：即发生问题的系统的拓扑。比如涉及的各种应用程序、主机、转发设备、链路资源等，并且要充分理解这些资源组建在拓扑中起到的作用。
• 环境因素：即描述这个问题所需要的信息，比如