我所经历的一次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读请求只有一个redis从节点处理,非常的吃力。所以我们将redis升级到4.x版本,并由主从集群改为分布式集群,两主无从。别问两主无从是怎么做到的,我也不懂,只有亚马逊清楚。
Redis升级后,理论上,两个主节点,分槽位后请求会平摊到两个节点上,性能会好很多。但好景不长,服务重新上线一个小时不到,并发又突增到了六七万每分钟,这次是大量的RPC远程调用超时,已经没有jedis的读超时Read time out了,相比之前好了点,至少不用再给Redis加节点。
这次的事故是并发量超过临界值,超过redis的实际最大qps(跟存储的数据结构和数量有关),虽然升级后没有Read time out! 但Jedis的Get读操作还是很耗时,这才是罪魁祸首。Redis的命令耗时与Jedis的读操作Read time out不同。
redis执行一条命令的过程是:
接收客户端请求
进入队列等待执行
执行命令
- 响应结果给客户端
由于redis执行命令是单线程的,所以命令到达服务端后不是立即执行,而是进入队列等待。redis慢查询日记记录slowlog get的是执行命令的耗时,对应步骤3,执行命令耗时是根据key去找到数据所在的内存地址这段时间的耗时,所以这对于key-value字符串类型的命令而言,并不会因为value的大小而导致命令耗时长。
为验证这个观点,我进行了简单的测试。
分别写入四个key,每个key对应的value长度都不等,一个比一个长。再来看下两组查询日记。先通过CONFIG SET slowlog-log-slower-than 0命令,让每条命令都记录耗时。
key_4的value长度比key_3的长两倍,但get耗时比key_3少,而key_1的value长度比key_2短,但耗时比key_2长。
第二组数据也是一样的,跟value的值大小无关。所以可以排除项目中因value长度过长导致的slowlog记录到慢查询问题。慢操作应该是set、hset、hmset、hget、hgetall等命令耗时比较长导致。
而Jedis的Read time out则是包括1、2、3、4步骤,从命令的发出到接收完成Redis服务端的响应结果,超时原因有两大原因:
redis的并发量增加,导致命令等待队列过长,等待时间长
- get请求读取的数据量大,数据传输时间长
所以将Redis从一主一从改为两主之后,导致Jedis的Read time out的原因一有所缓解,分摊了部分压力。但是原因2还是存在,耗时依然是问题。
Jedis的get耗时长导致服务B接口执行耗时超过设置的3s。由于dubbo消费端超时放弃请求,但是请求已经发出,就算消费端取消,提供者无法感知服务端超时放弃了,还是要执行完一次调用的业务逻辑,就像说出去的话收不回来一样。
由于dubbo有重试机制,默认会重试两次,所以并发8w对于服务b而言,就变成了并发24w。最后导致业务线程池一直被占用状态,RPC远程调用又多出了一个异常,就是远程服务线程池已满,直接响应失败。
问题最终还是要回到Redis上,就是key对应的value太大,传输耗时,最终业务代码拿到value后将value分割成数组,判断请求参数是否在数组中,非常耗时,就会导致服务B接口耗时超过3s,从而拖垮整个服务。
模拟服务B接口做的事情,业务代码(1)。
/**
* @author wujiuye
* @version 1.0 on 2019/10/20 {描述:}
*/
public class Match {
static class Task implements Runnable {
private String value;
public Task(String value) {
this.value = value;
}
@Override
public void run() {
for (; ; ) {
// 模拟jedis get耗时
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
// =====> 实际业务代码
long start = System.currentTimeMillis();
List ids = Arrays.stream(value.split(",")).collect(Collectors.toList());
boolean exist = ids.contains("4029000");
// ====> 输出结果,耗时171ms .
System.out.println("exist:" + exist + ",time:" + (System.currentTimeMillis() - start));
}
}
}
;
public static void main(String[] args) {
// ====> 模拟业务场景,从缓存中获取到的字符串
StringBuilder value = new StringBuilder();
for (int i = 4000000; i <= 4029000; i++) {
value.append(String.valueOf(i)).append(",");
}
String strValue = value.toString();
System.out.println(strValue.length());
for (int i = 0; i < 200; i++) {
new Thread(new Task(strValue)).start();
}
}
}
这段代码很简单,就是模拟高并发,把200个业务线程全部耗尽的场景下,一个简单的判断元素是否存在的业务逻辑执行需要多长时间。把这段代码跑一遍,你会发现很多执行耗时超过1500ms,再加上Jedis读取到数据的耗时,直接导致接口执行耗时超过3000ms。
这段代码不仅耗时,还很耗内存,没错,就是这个Bug了。改进就是将id拼接成字符串的存储方式改为hash存储,直接hget方式判断一个元素是否存在,不需要将这么大的数据读取到本地,即避免了网络传输消耗,也优化了接口的执行速度。
由于并发量的增长,导致redis读并发上升,Jedis的get耗时长,加上业务代码的缺陷,导致服务B接口耗时长,从而导致服务A远程RPC调用超时,导致dubbo超时重试,导致服务B并发乘3,再导致服务B业务线程池全是工作状态以及Redis并发又增加,导致服务A调用异常。正是这种连环效应导致服务雪崩。
最后优化分三步
一是优化数据的redis缓存的结构,刚也提到,由大量id拼接成字符串的key-value改成hash结构缓存,请求判断某个id是否在缓存中用hget,除了能降低redis的大value传输耗时,也能将判断一个元素是否存在的时间复杂度从O(n)变为O(1),接口耗时降低,消除RPC远程调用超时。
二是业务逻辑优化,降低Redis并发。将服务B由一个服务拆分成两个服务。这里就不多说了。
三是Dubbo调优,将Dubbo的重试次数改为0,失败直接放弃当前的广告点击请求。为避免突发性的并发量上升,导致服务雪崩,为服务提供者加入熔断器,估算服务所能承受的最大QPS,当服务达到临界值时,放弃处理远程RPC调用。
(我用的是Sentinel,官方文档传送门:
https://github.com/alibaba/Sentinel/wiki/%E6%8E%A7%E5%88%B6%E5%8F%B0)
所以,缓存并不是简单的Get,Set就行了,Redis提供这么多的数据结构的支持要用好,结合业务逻辑优化缓存结构。避免高并发接口读取的缓存value过长,导致数据传输耗时。同时,Redis的特性也要清楚,分布式集群相比单一主从集群的优点。反省img。
经过两次的项目重构,项目已经是分布式微服务架构,同时业务的合理划分让各个服务之间完美解耦,每个服务内部的实现合理利用设计模式,完成业务的高内聚低耦合,这是一次非常大的改进,但还是有还多历史遗留的问题不能很好的解决。同时,分布式也带来了很多问题,总之,有利必有弊。
有时候就需要这样,被项目推着往前走。在未发生该事故之前,我花一个月时间也没想出困扰我的两大难题,是这次的事故,让我从一个短暂的夜晚找出答案,一个通宵让我想通很多问题。
文章标题:我所经历的一次Dubbo服务雪崩,这是一个漫长的故事
文章分享:http://scyanting.com/article/ppceic.html