干货 | QMQ在携程的落地实践

原创 Magiccao 携程技术

作者简介

Magiccao，携程软件开发工程师，热衷网络、操作系统相关技术。

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

比较自然的解决方案有两个：1）分库分表；2）换存储。与业界众多出名的消息队列（Kafka、RocketMQ、Pulsar等）一样，QMQ也走上了基于文件存储的分布式消息系统自研之路（详细设计请关注QMQ开源：https://github.com/qunarcorp/qmq）。后文的介绍， 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消息同步完成。