Spark向Cassandra写入数据时节点无响应、连接被拒问题排查咨询

• Native Transport线程池耗尽：Cassandra的9042端口（CQL服务端口）依赖独立的Native Transport线程池处理请求，而节点状态同步走7000端口的Gossip协议，两者互相独立。当写入请求量超过线程池处理上限时，9042端口会拒绝新连接，但Gossip服务正常运行，所以会出现nodetool status显示UP但cqlsh连接被拒的现象。
• 同机资源争抢：128GB物理机给Cassandra和Spark Worker各分配64GB内存，没有预留操作系统内核、Page Cache所需的内存空间，内存不足时CQL服务会被优先阻塞，但优先级更高的Gossip服务仍可正常运行。
• 写入配置不合理导致过载：Spark侧配置了output.batch.size.rows=1（每行发起一次请求）、output.concurrent.writes=100，再加上多Executor并发，会在短时间内向Cassandra发起大量小请求，直接打满9042端口的连接/线程上限。
• TCP连接耗尽：大量短连接导致TIME_WAIT状态的连接占满端口资源，无法新建9042端口的连接，但Gossip使用长连接不受影响。

• 首先验证9042端口状态：异常节点执行ss -lntp | grep 9042确认端口是否还在监听，执行ss -antp | grep 9042 | wc -l统计当前连接数，和Cassandra配置的native_transport_max_threads、native_transport_max_connections参数对比，确认是否已达上限。
• 排查系统资源与内核日志：执行free -h确认内存使用情况，执行dmesg -T检查是否有OOM Killer的相关日志，执行iostat、top确认CPU、IO是否存在过载。
• 抓取JVM栈信息：异常时执行jstack <Cassandra进程ID> > jstack.log，检查Native Transport线程是否全部处于阻塞状态，是否存在大量锁等待或IO等待。
• 核对Cassandra网络配置：检查cassandra.yaml中的rpc_address是否绑定了对外可访问的IP，是否开启了SSL等额外配置导致端口访问异常。

• 调整节点资源分配：128GB物理机建议给Cassandra分配32GB堆内内存+预留32GB Page Cache（共占用64GB），剩余64GB分配给Spark Worker和操作系统，避免内存争抢影响CQL服务。
• 优化Spark写入配置：将spark.cassandra.output.batch.size.rows调整为100~1000，减少请求数量；将spark.cassandra.output.concurrent.writes调整为每个Executor 8~16，总并发数不超过Cassandra集群Native Transport总线程数的70%；必要时可降低throughputMBPerSec参数值进行限流。
• 优化Cassandra与内核参数：根据业务规模适当调大native_transport_max_threads（建议不超过4096）、native_transport_max_connections参数；调整TCP内核参数tcp_tw_reuse=1、tcp_fin_timeout=30，减少TIME_WAIT连接占用端口资源。
• 补充监控能力：新增9042端口存活监控、Native Transport线程数/连接数监控，异常时提前告警，避免影响业务。

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