线上服务依赖的tair服务随机性的短时大幅超时问题排查处理

1. 超时问题报警

2017年02月22日 监控服务突然出现P0级别报警，线上服务出现1018个超时，之前未出现过如此大数量的超时。

2. 问题初步确定

经过排查是由于tair超时导致的，详见下图，tair同学反映是tair请求达到服务上限，到此这个问题基本可以交差了，毕竟服务很快恢复正常。

3. 深入排查问题原因

有几个疑点难以解释

从tair超时开始，到tair超时结束一段时间，qps始终保持6k左右，而且后续还要高一些，如果是服务请求达到上限应该是服务一直维持超时状态，为什么服务很快又恢复了呢？
之前偶尔也出现过类似的tair请求超时，只是没有短时间连续出现，之前的qps比现在要低很多，为什么也会出现呢？

初步认为有可能是poi全量同步导致的瞬时压力导致tair短时间服务超时，但监控系统难以监控到qps短时间的变化。

经过调研确认，

lbs单机同步需要1.6-1.7s，同步数据量12W，此时的批量端口qps可以到达150；
在最差的情况40台服务器同时请求，批量端口qps可以达到6000,此情况下，瞬间会超过tair的1200（批量500条件下）服务上限。
超过8台机器在lbs短时间同步时，同时访问tair的概率很低，这也跟偶尔会出现tair超时的现象匹配。

4. 初步解决方案

控制lbs同步数据时的tair访问qps，初步将qps降低为5（最差情况批量qps为200，不会对tair服务造成太大影响），根据服务后续情况再调整相应数值。

5. 效果验证

在低流量（易验证小流量变化）以及相同业务请求量（排除业务请求干扰）的情况下，Tair的访问qps降低90，符合我们对流量的预期，证明解决方案已有效运行，后续再观察下服务运行效果。