我有多个应用程序写入 Cassandra。
每个单元应用程序都配置了反压机制，例如
throughputMBPerSec=10当多个应用程序同时运行时会出现问题，因为单独设置并成功测试的背压变得错误
在客户端背压场景中，如何实现一种机制，根据集群的整体压力状态选择一个好的背压值，并且不会损失太多性能？
这种问题在大公司是如何解决的？
大公司通常使用两种方法来减轻 Cassandra 的写背压。我建议应用程序团队同时使用这两种方法。我还会推荐第三种：
将每个写入作为其自己的线程发送，并具有“可监听的未来”。一旦启动了一定数量的任务（例如 50 个……这将根据应用程序而变化），请阻止以确保它们全部完成。完成后，启动另一批线程。这里主要的“可调整”是增加或减少活动线程数。
将每个写入作为消息发送到事件处理器/代理（例如 Apache Pulsar 或 Apache Kafka）。构建一个处理消息的消费者。这里主要的可调参数是调整消费者接收队列的大小。我认为 Pulsar 的默认值是 1000 条消息。
为每个应用程序构建一个 Cassandra 集群。不幸的是，Cassandra 在处理截然不同的访问模式方面做得并不好。在 Target，我们终于拥有了足够的具有大量写入流量的应用程序，为其他人造成了瓶颈，并为每个新应用程序构建了一个集群。
较小的应用程序只需要 3 到 6 个节点，而其他应用程序则需要 200 多个节点。当您考虑所需资源中的差异时，会发现将这些应用程序放在同一位置确实没有意义。如果您在云（公共或私有）中部署，这比在裸机上部署要容易得多。
编辑
当您处于特定的 ETL（jar/app）中时，这似乎很简单，因为您控制所有线程（并且可以阻止其中一些线程），同时全局阻止来自多个 ETL（jar/app）的线程似乎更困难时间，可以在不同的物理机上运行。
是的，这是假设线程控制发生在每个单独的 ETL 作业中。对于您的情况来说，这可能并不容易做到。
如何调整队列大小，对 Cassandra 端的背压有影响吗？
我对此不太确定，但我认为调整队列大小会限制消费者在任何给定时间可以从该主题中获取的消息数量。因此，如果该队列较小，它必须进行更多的代理行程，从而有效地减慢消息写入 Casasndra 的速度。
但是，在消费者方面，你仍然需要一些方法来避免给 Cassandra 带来太大的压力，所以在我看来，这个解决方案只是从背压的角度转移了问题
你在这一点上没有错。这肯定是一种权衡，但其想法是，一些问题可以通过消息代理有效地充当写入吞吐量的手刹来解决。当然，溢出是由消息传递服务器或消费者处理的。