线上系统报ERR Connection timed out异常解决过程

1 发现线上redis问题：ERR Connection timed out

近日，刚上线一个系统，上线第二天去ELK日志系统（公司的日志系统是对开源实时日志分析ELK平台进行了改造而来的）跟踪一下线上情况，一时发现抛出了很多redis异常：

再仔细一看：

发现连接redis有问题，于是立即联系运维，运维的回答是他们线上使用了twemproxy集群技术，redis服务并没有问题。于是我就方了，难道是程序使用redis不对。。。

2 定位问题

由于之前对twemproxy并不了解，于是了解了一下twemproxy实现集群的原理。其设计如下图，机制就是将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。

然后到github上查看了twemproxy相关的说明文档，希望能得到一些线索。从这个文档（https://github.com/twitter/twemproxy/blob/master/notes/recommendation.md）中可以看到关于timeout的说明：

Relying only on client-side timeouts has the adverse effect of the original request having timedout on the client to proxy connection, but still pending and outstanding on the proxy to server connection. This further gets exacerbated when client retries the original request.
By default, nutcracker waits indefinitely for any request sent to the server. However, when timeout: key is configured, a requests for which no response is received from the server in timeout: msec is timedout and an error response SERVER_ERROR Connection timed out\r\n (memcached) or -ERR Connection timed out\r\n (redis) is sent back to the client.

第两段的意思就是如果只是在客户端与代理服务器之间设置超时，而代理与redis服务器之间不设置超时，那么当代理请求redis服务器一直没有返回的时候，客户端会重新发起连接请求，这样就会导致客户端一直向代理发送请求的严重问题。所以客户端与代理之间、代理与redis服务器之间都应该配置超时。

我们可以看一下正常情况下，客户端一次查询请求的流程：

我们再看一下当返回Error Connection timed out错误的情况：

通过这样的分析，基本上可以确定客户端报timed out异常的情况是由代理与redis之间引起的。再加上刚上线并没有报这个异常，而且redis服务端是一个集群，所以我们大胆的猜测是线上redis集群中的某个实例挂掉了。于是又联系了运维，让运维的同事查看是否有实例挂掉。

不一会儿，运维的同事“报喜”了，说线上redis集群中有一个redis实例挂了。经过一番倒腾，总算是发现了问题的原因。

3 关于此问题的总结

在找到问题之后，我向运维问了一个问题，你们为什么不使用redis官方的集群解决方案呢，而是使用twemproxy。运维同事的回答是redis集群技术各有优点，redis官方的集群解决方案管理起来比较复杂，需要大量的配置。

站在我的角度看来twemproxy的高可用性不够，就像这次事故，在一个实例挂掉之后集群并没有容灾机制将挂掉的实例平滑的替代。

正如运维的同事所说redis集群技术各有优点，我们只能根据具体的项目择优选择合适的解决方案。下一篇文章将梳理几种redis集群解决方案。