处理 Observables 产生元素的速度比观察者消耗它们的速度快的策略
在 ReactiveX 中，不难陷入 Observable 发出元素的速度比操作符或观察者消耗它们的速度更快的情况。这就引发了如何处理日益积压的未消耗元素的问题。
例如，想象一下使用 Zip 运算符将两个无限 Observables 压缩在一起，其中一个发出元素的频率是另一个的两倍。操作符的简单实现必须维护一个不断扩大的缓冲区，其中包含由较快的 Observable 发出的元素，以最终与较慢的 Observable 发出的元素合并。这可能会导致 ReactiveX 占用大量系统资源。
注：zip 操作符是一种以锁步方式执行可观察序列的方法。
你可以使用多种策略在 ReactiveX 中执行流量控制和背压，以缓解快速生成的 Observable 遇到缓慢消耗的观察者时引起的问题，其中包括在一些 ReactiveX 实现中，响应式拉取背压和一些特定于背压的运算符。
一个 cold Observable 会发出特定的元素序列，但可以在观察者发现方便时开始发出该序列，并且可以以观察者希望的任何速率发出，而不会破坏序列的完整性。例如，如果将静态可迭代对象转换为可观察对象，则该可观察对象将发出相同的项目序列，无论稍后何时订阅或观察这些项目的频率如何。一个 cold Observable 发出的元素示例可能包括数据库查询、文件检索或 Web 请求的结果。
一个 hot Observable 在创建时开始生成要立即发出的元素。订阅者通常从序列中间的某个位置开始观察 hot Observable 发出的元素序列，从订阅建立后 Observable 发出的第一个元素开始。这样的 Observable 按照自己的节奏发出元素，并且由观察者来跟上。一个 hot Observable 发出的元素示例可能包括鼠标和键盘事件、系统事件或股票价格。
当一个 cold Observable 被多播时（当它被转换为可连接的 Observable 并调用其 Connect 方法时），它实际上从冷信号变成了热信号，并且出于背压和流量控制的目的，它应该被视为 hot Observable。
Cold Observables 非常适合由 ReactiveX 的某些实现实现的反向背压的反应式模型（reactive pull model of backpressure）（在其他地方进行了描述）。 Hot Observables 通常不能很好地应对反应式拉取模型，并且更适合其他流量控制策略，例如使用其他运算符，或 Buffer、Sample、Debounce 或 Window 等运算符。