Cassandra中REQUEST_RESPONSE消息丢失问题求原因分析与排查思路

我之前维护Cassandra集群时确实碰到过一模一样的REQUEST_RESPONSE消息丢失问题，结合踩过的坑和官方文档总结，这类问题的常见原因主要有以下几类：

首先先贴出你提供的日志供参考：

DEBUG [SharedPool-Worker-2] 2018-XX-XX 13:55:30,596 MessageDeliveryTask.java:52 - Message dropped; constructionTime: 1521726918889, isCrossNodeTimestamp: false, timeout: 10000, message: FROM:/XX.XX.XXX.XXX TYPE:REQUEST_RESPONSE VERB:REQUEST_RESPONSE SIZE:146018

常见引发原因 #

• 消息超时触发丢弃：日志里明确标注了timeout:10000，这和Cassandra默认的rpc_timeout_in_ms（10秒）一致。当请求的响应消息在构造完成后，传输到接收端的时间超过了这个超时阈值，MessageDeliveryTask就会直接丢弃这条消息。常见场景包括：跨节点网络延迟过高、目标节点处理请求耗时过长（比如磁盘IO繁忙导致读取数据慢），导致响应生成后已经超时。
• 网络层传输异常：日志里的消息大小是SIZE:146018，这个尺寸接近网络MTU的分片上限，很可能在传输过程中出现分片丢失；另外集群节点间的网络波动、防火墙/路由设备拦截大报文、跨数据中心链路不稳定等，都会导致响应消息在传输途中丢失。
• 目标节点资源瓶颈：如果目标节点的CPU、内存使用率长期居高不下，或者磁盘IO负载过高，会导致请求响应无法及时生成和发送；另外Cassandra的核心线程池（比如ReadStage、SharedPool）被占满时，请求处理会被阻塞，响应延迟超过超时时间后，就会被发送端判定为超时丢弃。
• 版本特定Bug：部分旧版本的Cassandra存在消息处理逻辑的Bug，比如在大尺寸请求并发场景下，会错误地丢弃响应消息。比如3.11.x系列的部分早期版本就有过这类问题，后续补丁版本已经修复。

排查建议 #

• 先确认集群的rpc_timeout_in_ms配置，如果业务场景允许，可以适当调大这个值，但要注意避免因超时过长导致请求堆积。
• 用ping、traceroute等工具检查节点间的网络延迟和丢包率，同时排查网络设备是否有报文拦截规则。
• 用nodetool tpstats查看Cassandra线程池的堆积情况，结合节点的CPU、内存、磁盘IO监控数据，定位是否存在资源瓶颈。
• 核对当前Cassandra版本，查看官方JIRA是否有相关已知Bug，必要时升级到稳定的补丁版本。

内容的提问来源于stack exchange，提问作者sandeep