我的情况如下：
我有一个生成随机数据的生成器。生成的数据应由多个订阅者接收。由于生成的数据是随机的，我不能使用冷发布者，因为在冷发布者的情况下，有几个订阅者会收到不同的数据。因此，我需要一个热发布者，但我不确定在热发布者的情况下如何从我的订阅者发出有界的请求。我的一个订阅者任务受 CPU 限制，而其他任务受 IO 限制，因此第二个任务很可能速度较慢。在以下情况下，热门发布者的行为方式有点令人困惑：
- CPU 绑定订阅者发出无限请求
- IO 绑定订阅者发出有界请求，例如一次 100 个项目
在冷发布者的情况下，很明显每个订阅者都可以独立于其他订阅者控制背压，所以请描述在热发布者和多个订阅者的情况下背压的工作原理，因为在我看来，CPU 绑定订阅者接收数据的速率将是 IO 绑定订阅者的速率，这似乎不是最佳的，因为一个订阅者依赖于另一个订阅者。
我会说这取决于热门出版商，但你可能期望它充其量会遵循(编辑：最低(需求。
编辑：这完全取决于热门出版商，没有一般规则。
但从概念上讲，它们在不同的订阅者之间"共享"他们的数据，因此为了不压倒其中一个订阅者，他们必须跟踪单个订阅者的请求并相应地排队无关的数据，或者对其源执行单个请求，以匹配其订阅者之间的最低请求。Flux#publish()(以及Flux#share()的程度(是后者。