我所经历的一次Dubbo服务雪崩，这是一个漫长的故事

在一个处理用户点击广告的高并发服务上找到了问题。看到服务打印的日记后我完全蒙了，全是jedis读超时，Read time out！一直用的是亚马逊的Redis服务，很难想象Jedis会读超时。

看了服务的负载均衡统计，发现并发增长了一倍，从每分钟3到4万的请求数，增长到8.6万，很显然，是并发翻倍导致的服务雪崩。

服务的部署：

处理广告点击的服务：2台2核8g的实例，每台部署一个节点(服务)。下文统称服务A

规则匹配服务(Rpc远程调用服务提供者)：2个节点，2台2核4g实例。下文统称服务B

还有其它的服务提供者，但不是影响本次服务雪崩的凶手，这里就不列举了。

从日记可以看出的问题：

一是远程rpc调用大量超时，我配置的dubbo参数是，每个接口的超时时间都是3秒。服务提供者接口的实现都是缓存级别的操作，3秒的超时理论上除了网络问题，调用不应该会超过这个值。在服务消费端，我配置每个接口与服务端保持10个长连接，避免共享一个长连接导致应用层数据包排队发送和处理接收。

二是刚说的Jedis读操作超时，Jedis我配置每个服务节点200个最小连接数的连接池，这是根据netty工作线程数配置的，即读写操作就算200个线程并发执行，也能为每个线程分配一个连接。这是我设置Jedis连接池连接数的依据。

三是文件句柄数达到上线。SocketChannel套接字会占用一个文件句柄，有多少个客户端连接就占用多少个文件句柄。我在服务的启动脚本上为每个进程配置102400的最大文件打开数，理论上目前不会达到这个值。服务A底层用的是基于Netty实现的http服务引擎，没有限制最大连接数。

所以，解决服务雪崩问题就是要围绕这三个问题出发。

第一次是怀疑redis服务扛不住这么大的并发请求。估算广告的一次点击需要执行20次get操作从redis获取数据，那么每分钟8w并发，就需要执行160w次get请求，而redis除了本文提到的服务A和服务B用到外，还有其它两个并发量高的服务在用，保守估计，redis每分钟需要承受300w的读写请求。转为每秒就是5w的请求，与理论值redis每秒可以处理超过 10万次读写操作已经过半。

由于历史原因，redis使用的还是2.x版本的，用的一主一从，jedis配置连接池是读写分离的连接池，也就是写请求打到主节点，读请求打到从节点，每秒接近5w读