QMQ在携程的落地实践

2020-07-13 00:00:00 客户端 文件 消息 队列 超时

QMQ(Qunar Message Queue)诞生于去哪儿网,初版基于MySQL存储。随着集团业务系统越发倚重消息解耦上下游,业务量的上涨随之带来消息量的增长,MySQL作为存储的瓶颈也越发明显。

比较自然的解决方案有两个:1)分库分表;2)换存储。与业界众多出名的消息队列(Kafka、RocketMQ、Pulsar等)一样,QMQ也走上了基于文件存储的分布式消息系统自研之路(详细设计请关注QMQ开源:github.com/qunarcorp/qm)。后文的介绍, QMQ均指基于文件存储的版本。

在携程落地的过程中,我们主要和两类问题打交道:网络和磁盘IO。

一、网络

网络问题多种多样,因而也诱发了一系列问题,和大家分享5种比较典型的场景。

1.1 OOM

场景来自某台Broker slave机器OOM告警,问题出在堆外内存分配上,图1是堆外内存泄露现场。QMQ网络通信基于netty开发,接收消息时使用堆外内存;拉取消息时,使用FileRegion和少量堆内内存;slave从master同步消息文件,使用FileRegion。FileRegion直接将消息文件写入到发送缓冲区,不会分配堆外内存,排除。接收消息放入Receiver队列,如果消息落磁盘操作阻塞,消息积压在队列(没有回压机制,而channel是auto read的,只要有消息进来,就会不停的放入队列),势必引发堆外内存上涨,但只有master提供消息服务,排除。

图1 OOM时堆外内存泄露现场

引起关注的是稳定的增长速率:300MB/分钟,即50MB/10秒。50MB是个特殊的数字,我们有一个消息索引备份服务,会实时从slave上拉取消息索引,我们设置了每次拉取的上限。10秒则是索引备份服务请求的超时时间。如果,备份服务的请求抵达slave,slave实时计算了索引、分配了内存,但数据未被备份服务接收,10秒后超时,重试。似乎一切都能解释了,查看了当时的备份服务的日志(图2所示),吻合。

图2 备份异常日志

备份服务和slave是tcp单连接通信,备份服务和slave是一对一关系,当slave上tcp连接的发送缓冲区满了后,索引数据的网络写入会感知到失败,我们的服务应该是能感知到才对。原来,FileRegion的操作,不会影响netty的水位线,因而代码中没有做channel.isWritable的判断就直接channel.writeAndFlush了。后面因为需求,增加了slave实时计算索引的功能,复用了以前的代码,导致数据积压在netty的OutboundBuffer中,从而引发了堆外内存泄露。至于备份请求能到slave,响应未能从slave送出去,是网络故障导致。

结论:netty write操作前,须判断isWritable。

1.2 文件句柄耗尽

场景来自客户端与MetaServer 新建tcp连接失败的告警。图3是某一台MetaServer的网络连接现场。tcp连接是需要分配文件句柄的,机器上设置的大可用文件句柄为65536,显然tcp建连失败,是因为此机器上的文件句柄耗尽导致。

图3 某台MetaServer的tcp连接数

QMQ一个客户端实例(进程)只会与MetaServer创建一个tcp连接,正常情况下不可能出现文件句柄耗尽。为了排查泄露的连接,分别在某台客户端机器和MetaServer机器上执行ss。

图4 客户端ss输出
图5 MetaServer ss输出

显然,的确发生了泄露。客户端因为某些原因关闭了54026(譬如,机器掉电或者局部网络隔离触发了tcpkeepalive机制等),如果服务端未能感知到客户端54026的关闭,54026就泄露了。客户端与MetaServer通信基于netty,反查代码,MetaServer未设置IdleStateHandler以及ChannelOption.SO_KEEPALIVE,意味着54026非正常关闭后,MetaServer失去了感知手段,泄露成为必然。

结论:客户端和服务端双向idle检测很有必要。

1.3 Broker未被摘除

Broker粘滞在某台MetaServer上定时心跳,当心跳间隔超时后,只能由被粘滞的MetaServer将其状态置为不可读写(NRW),从生产者、消费者路由列表中摘除,如图6所示。

这种去中心化的心跳保活机制有个缺陷:当Broker与被粘滞的MetaServer同时故障或被粘滞的MetaServer与DB局部网络隔离后,Broker不会被摘除,生产者和消费者将引发生产、消费异常,只能依赖客户端熔断机制弥补。在有一次QMQ单边机房演练中(关闭单边机房的QMQ服务)就触发了上述场景。

图6 broker保活机制

我们重新设计了保活机制,所有MetaServer都定时扫描DB中Broker状态表,一旦发现broker失联,就尝试将其置为NRW。

结论:分布式需要多考虑些网络隔离。

1.4 java.net.SocketTimeoutException: Read timed out

生产者、消费者应用启动时,通过与MetaServer心跳获取路由信息,MetaServer将客户端元数据存储于MySQL。在一次机房断网演练恢复后,仍出现大量线程被挂起情况,堆栈如下图,大约15分钟,抛出java.net.SocketTimeoutException: Read timed out。

图7 操作db阻塞线程堆栈

堆栈显示,当前线程阻塞在等待MySQL响应读取上,比较容易联想到是机房断网演练导致,且可能超时设置不合理导致。实际上,我们使用的DataSource并未设置SO_TIMEOUT,意味着无超时时间。可实际现象为何是15分钟,应用层感知到socket timeout?

其实,这是linux tcp中比较常见的一类问题。对于一个ESTABLISHED的tcp连接,发送端将应用层数据写入发送缓冲区,内核tcp协议栈负责保证数据可靠传递到接收端。为了保证可靠,tcp采用超时重传机制,重试间隔根据退避算法计算得出,相关代码位于net/ipv4/tcp_timer.c#tcp_retransmit_timer,截取部分如图8所示。

图8 rto退避算法

简言之,tcp重传定时器定时时间是上次rto的两倍,大不超过TCP_RTO_MAX(120S),小不能小于TCP_RTO_MIN(200ms),而终判定是否超时,则与内核参数net.ipv4.tcp_retries2有关,相关代码位于在net/ipv4/tcp_timer.c#retransmits_timed_out,截取部分如图9所示。

图9 重传超时判定算法

默认net.ipv4.tcp_retries2取值15,即代码截图中的boundary,rto_base对于ESTABLISHED状态的连接取值TCP_RTO_MIN(200ms)。当应用层未设置SO_TIMEOUT,即timeout == 0,整个重传耗时大于(((2 << 9) - 1) * 0.2 + (15 -9) * 120)后,约15分钟,将被认定为超时,关闭连接,socketRead0将抛SocketTimeoutException: readtimed out。

结论:DataSource须设置SO_TIMEOUT。

1.5 大流量

某个周六的中午,某台Broker的端到端延迟(从消息生产到被消费的时间差)突然告警,从平时的20ms蹿升到几十秒。将机器拉出解除故障后,着手排查,发现full gc了,图10所示。从日志分析引发fgc是因为堆外内存不足,主动触发了system.gc()。

图10 fgc
图11 oom日志

堆外内存耗尽,是由于一波突发生产消息流量导致,而根因是broker的消息接收模型导致。netty decode handler切割出消息(ByteBuf.slice())后,将消息放入一个无界的接收队列,netty的worker线程就返回了,然后由一个单线程的消息处理线程从接收队列中取出消息写入磁盘。终堆外内存归还到池子中,须待slave消息同步完成。

图12 消息接收流程

无界接收队列不应该承担全部的责任,其本质还是需要有套回压机制,譬如,当检测到接受队列大小超过阈值后,关闭channel的auto read机制。终我们从如下几个角度做了针对突发大流量的防御:

1)decode handler中,检测单包请求大小,对于超过阈值的,直接关闭连接。可以有效避免,非法客户端发送超大消息,导致netty分配超大内存;

2)生产、消费限速;

3)限制接收队列大小,限制消息在队列中停留的时间,超时后,直接丢弃,释放内存;

4)监控写io耗时,超过阈值后,暂停接收消息流量。

结论:系统须考虑回压机制。

二、磁盘IO

任何基于文件存储的系统,磁盘IO问题都是不得不考虑的问题。我们的机器未使用SSD,都是基于机械硬盘的存储上的优化,主要介绍两类场景。

2.1 堆积消息拉取

在介绍这个问题前,先介绍一下QMQ的存储模型,如图13所示。所有主题的消息都顺序写入一个文件,然后为每个消息主题构建索引文件,拉取消息的时候,根据消息主题索引文件从而读取到消息。但由于所有消息主题共用一个文件,极限情况,拉取10条消息,可能会读取10次消息文件。

图13 QMQ存储模型

由于linux的page cache机制,对于实时拉取而言,可能读取全部命中page cache,并不会产生读IO事件。但堆积长时间的消息,很大程度上其消息已经换出page cache,而离散的消息,将实实在在的产生多次读IO,影响系统的io util,终影响整个系统的生产、消费。

QMQ的作者刀刀给出了一种解决方案:如何用不到两千块大幅度提升QMQ性能,即尝试对消息文件进行排序,能缓解堆积消息拉取对系统带来的冲击。本文不做过多介绍,感兴趣的同学可以跳转至刀刀的文章阅读。

除了上述方案,我们还在物理隔离上做了一些尝试。概括来说就是将产生堆积的消费组(一般是大数据job类)从实时集群剥离出来,我们将消息镜像到hbase,消费者通过hbase消费。

结论:冷热分离可以尝试

2.2 大消息

在消息治理的过程中,我们发现有一定比例主题的消息体有超过100KB。如果能减少消息体大小,对系统的IO显然能起到减负效果。于是,我们推出了生产者消息压缩。压缩效率5到8倍,如图14展示了某个主题消息压缩前后的监控数据。

图14 某个主题的压缩效果

结论:控制写入磁盘量来缓解IO。文件编码优化也不失为一种选择。

三、后

在实践中会比本文遇到的case更多、更复杂:客户端容器与宿主出现丢包、中间网络设备出现包错乱、客户端堆内存居高不下、服务端TCP重传机制“失效”、服务端IO持续偏高、RAID卡电池异常、RAID卡固件版本过低等,本文旨在抛砖引玉。

后续,我们的工作将从下面几个方面入手:文件编码优化(譬如varint替代定长、timestamp压缩)、page cache使用优化(快手kafka解决方案)、消费者拉取重定向(冷热消息分离,rocketmq重定向到slave,可以考虑HDFS等)、内核升级(引入bcc)排查长尾问题。

【作者简介】Magiccao,携程软件开发工程师,热衷网络、操作系统相关技术。

更多携程技术人一手干货文章,请关注“携程技术”微信公众号。

相关文章