让研发人员紧张的“故障神经线”
王新栋
讲述：丁婵大小：7.78M时长：05:40
在众多 HTTP Code 里，程序员可能都喜欢 200，但从不喜欢以 5xx 打头的 HTTP 返回码，比如 502。发生大量 502 报警，你会不会紧张？再比如，域名流量监控下，一旦洪峰流量过来，你会不会紧张？近日，程序员王新栋在公众号程序架道发文，以 502 现象剖析了让程序员紧张的故障线及其产生的问题。具体如下。
在同步应用下有一条“故障神经线”，一旦触发就会让你神经紧张。这条神经线是这么建立的：用户请求通过 Nginx 接入进来，首先抵达 A 系统，通过 RPC 的方式 A 系统去调用 B 系统。
造成 502 最为常见的原因是故障依赖传导，因为是同步调用，故障就会顺着一层层的依赖关系反映到表层，即从系统 B 传导到系统 A 再通过 VIP 传导到最终用户。
形成这种“故障神经线”的原因，大致如下：
B 系统变慢，可能是业务逻辑处理性能下降，也可能是 B 系统依赖的资源出现性能问题。
A 系统和 B 系统之间的网络出现问题，比如抖动、发生大量 TCP 重传。
因为上述两点原因，A 系统对 B 系统采取了容错处理，比如限流、禁用，来防止故障扩大化。最要命的一点是，被限制的请求发生重试，因为最外层的调用方一旦请求受限，它们可能会疯狂的重试，造成流量洪峰。
由于系统 A 做了容错保护，比如线程池固定在了 1000 大小，那么在这样洪峰的情况下，因为重试处理不过来的请求，直接通过 Nginx 以大量 502 的 HTTP 状态码反映到用户。
在此期间还有可能会造成一些其他问题，比如下面两种问题。
第一种问题，分布式限流遭受热点。
实现分布式限流一般是用 Redis 的方式解决。如果收到某个固定用户有很多台服务器的疯狂重试请求，因为单一的 key 的请求落到了一个 Redis 集群分片上，就会触发热点。一般 2C10G 大小内存的一个分片，80000 次 / 秒的请求，就会触发我们事先设置好的热点阈值了。
当上述这种分布式限流遇到瓶颈的时候，就需要考虑降级到单机服务器限流，程序代码从本机的缓存中读取限流的配置信息来进行限流的处理。
第二种问题，TCP 重传次数过高。
TCP 是一种可靠的传输通讯协议，正是为了保证这样的传输可靠性，有了重传这样的机制。它的原理是当发送一个报文后，会开启一个超时重传计时器。如果在这个计时范围内没有收到来自目的接收方的确认，发送端就会启动这样的重传机制。导致出现重传的原因大致有三种情况。
1、网络故障
如果两个通讯服务端点之间发生了丢包、频繁抖动等网络故障，而网络质量不能较好的保障，根据 TCP 重传机制的理解，出现 TCP 重传的概率就会比较高。
2、服务器端口 speed 设置不合理
两台服务器 A 和 B，服务器 B 为 TCP 传输的目标服务器，此时如果服务器 A 的端口速率 speed 是 1000Mb/S，服务器 B 的端口速率 speed 是 10Mb/S，那么因为目标服务器的速率太小，则会造成 TCP 重传。
3、请求速度远远大于响应速度
可能原因是接收请求处理的一方处理速度确实变慢，还有种可能是服务端处理的集群能力已经达到了极限。这两种原因都会导致请求发送的一方触发 TCP 重传。
除了以上这些服务器产生 502 现象的原因外，还有其他原因可以造成 502 现象，比如防火墙阻止请求、DNS 问题、路由问题以及 ISP 相关的问题等。
但当线上一旦发生大量 502 错误报警时，研发人员还是要首先排除服务系统的故障。502 产生的本质原因，对于用户来讲就是访问请求的响应超时造成的。
那么，异步能不能解决这种问题呢？
一般 RPC 异步模式都使用队列或 Map 来实现，然后用一个事件循环线程不停地轮询队列事件。这样的模式下可以接收很多请求并直接放入队列，当有事件发生的时候，通过触发回调函数来处理事件。由于使用的线程较少，切换开销也少，也就基本不会有多线程阻塞的问题。
采用异步调用可以大大减少调用方集群的服务器数量，它能够耗费很少量的资源去发起更多的请求，在大流量平稳调用下这是很好的处理方式，尤其是在网关应用中。但极端流量请求下，如遇到分布式限流这样的情况，它并不能很好的解决问题。不过，在合适的场景下，异步方案仍是一个趋势。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论