居然是 你 偷走了那0.001的服务可用性

不久之前，部分同学提出对于我们某项活动的某项服务表现不稳定，偶尔低于0.999。虽然看起来3个9的可用性相当高，但是对于一个 10w+qps 的服务来讲，影响面就会被放大到不可接受的状态。

了解基本情况后，知道可用性降低是由于超时导致，非其他错误。进行简要分析，能够找出一些可能的原因，例如某些业务写法导致性能问题，异常流量，系统调用，网络问题，cpu throttle，中间件问题（如redis,mysql），go调度，gc问题等。至于是这8名嫌疑犯还是另有其人，需要结合实际现象进行排除与论证，所以需要针对性地收集一些线索。

其实cpu throttle并不高，也问过运维，没啥异常，不太像是导致超时的原因。中间有个小插曲：当时有同学从cpu throttle导致超时这个猜想出发，发现预约业务内存cache占用量比较大（占用大的话可能影响内存的分配与释放），尝试减少预约业务内存cache占用量。观察一段时间，cpu throttle稍微有点降低，但计算机的可用性不够的问题依然没有得到好转。

其他组件也同样看过，都没啥异常。那么问题来了，组件们都不背，那到底谁来背？那网络，系统调用，go调度与gc，你们自己看着办吧。

网络说你再仔细想想，不对啊，一个请求至少给了250ms的time_quota，你们最后只留给我和组件们那么点时间，redis 0.04ms，mysql 0.01ms。请问扣除这点时间，剩余是谁“消费”了，应该心知肚明了吧。说到这，go调度，系统调用与gc主动跳出来了。其实，这个问题很好解决，只要我们在go调度中设置一个默认参数，就可以避免这个问题了。

（编辑：银川站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!