大公司通常使用两种方法来减轻Cassandra上的写背压。我建议应用程序团队使用这两种方法。我也会提出第三个建议：
1.将每个写操作作为自己的线程发送，并带有一个“可扩展的未来”。一旦启动了一定数量的写操作（比如50个......这将随着应用程序的变化而变化），就阻塞以确保它们都完成了。完成后，启动另一批线程。这里主要的“可调”是提高或降低活动线程数。
1.将每个写入作为消息发送到事件处理器/代理，如Apache Pulsar或Apache Kafka。构建一个处理消息的消费者。这里主要的可调性是调整消费者的接收器队列的大小。我认为Pulsar的默认值是1000条消息。
1.为每个应用程序构建一个Cassandra集群。不幸的是，Cassandra在处理截然不同的访问模式方面做得不好。在Target，我们终于有了足够的应用程序，这些应用程序具有沉重的写入流量，为其他所有人创造了瓶颈，并为每个新应用程序构建了一个集群。
较小的应用程序只需要3到6个节点，而其他应用程序则需要200多个节点。当您看到所需资源的差异时，将这些应用程序放在同一位置真的没有意义。如果你部署在云中（公共或私有），这要容易得多，而不是部署在裸机上。

编辑

当你在一个特定的ETL（jar/app）中时，这看起来很简单，因为你控制了所有的线程（并且可以阻止其中的一些），同时全局阻止来自多个ETL（jar/app）的线程似乎更困难，这些线程可以从不同的物理机器运行。
所以，是的，这是假设线程控制发生在每个单独的ETL作业中。在你的情况下，这可能不容易做到。
如何调整队列大小，对Cassandra端的背压有影响？
我不太确定这一点，但我认为调整队列大小限制了消费者在任何给定时间可以从主题中提取多少消息。因此，如果该队列较小，则它必须多次访问代理，从而有效地降低了将消息写入Casasndra的速度。
但是，在消费者方面，你需要一些方法来避免给Cassandra带来太多的压力，所以这个解决方案在我看来只是从背压的Angular 移动了问题
你说的没错。这当然是一种折衷，但其想法是，通过消息代理有效地充当写吞吐量的手制动器来解决一些问题。当然，溢出由消息传递服务器或使用者处理。