Cassandra多应用并发场景下如何正确实现全局back-pressure

以下是几种可落地的解决方案：

• 集群侧内置限流兜底：Cassandra 4.0及以上版本原生支持服务端全局流量管控，开启后可直接配置集群级别的每秒写入吞吐量上限、单次请求大小阈值，超出限制的请求会被节点自动返回OVERLOADED错误，配合客户端默认的重试策略即可避免过载，无需修改上层任何应用配置，是成本最低的兜底方案。
  核心配置参考：

  native_transport_rate_limiting_enabled: true
  native_transport_max_bytes_per_second: 104857600 # 示例值，按集群实际上限设为100MB/s
  

• 统一接入网关层管控：在所有应用和Cassandra集群之间部署一层接入代理，由网关层统一计算全局写入流量总和，超出集群吞吐量上限的请求会先进入排队队列，还可按业务优先级分配流量配额，优先保证核心生产负载的写入请求不被拦截，非核心批量任务的请求滞后处理。
• 调度层全局资源配额限制：如果所有Spark批量写入任务都跑在YARN、K8s等统一资源调度平台上，可单独为Cassandra写入类任务划分独立资源池，预先设置资源池的总Executor核数上限，同时强制所有该资源池内的作业默认继承统一的spark.cassandra.output.throughputMBPerSec配置，禁止用户私自调大。按你之前的参数示例，假设单核心吞吐量限制为2MB/s，集群总写入上限为100MB/s，只需将资源池总核数上限设为48，就算所有应用满负载并发也不会超过集群吞吐量上限。
• 统一客户端配置+流量审计：将所有对接Cassandra的客户端（Spark Datastax驱动、业务服务驱动、cqlsh等）的背压配置托管到统一配置中心，可动态调整所有客户端的单节点/单核心吞吐量上限，同时部署全链路流量监控，实时统计全局写入吞吐量，发现流量接近阈值时自动调低非核心应用的吞吐量配额，必要时可暂停低优先级批量任务。

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