背壓操作符

處理 Observable 生產項目速度快於其觀察者消耗速度的策略

在 ReactiveX 中，很容易遇到 Observable 發射項目的速度快於操作符或觀察者消耗它們的速度的情況。這就出現了一個問題，如何處理不斷增長、未消耗的項目積壓。

例如，想像使用 Zip 操作符來將兩個無限的 Observable 合併在一起，其中一個發射項目的頻率是另一個的兩倍。操作符的幼稚實現將不得不維護一個不斷擴展的緩衝區，來存放較快 Observable 發射的項目，以便最終與較慢的 Observable 發射的項目組合。這可能導致 ReactiveX 佔用大量的系統資源。

在 ReactiveX 中，有多種策略可以進行流量控制和背壓，以緩解快速生產的 Observable 遇到慢速消耗的觀察者時引起的問題，其中包括，在某些 ReactiveX 實現中，反應式拉取背壓和一些特定的背壓操作符。

冷的 Observable 發射特定的項目序列，但是當其觀察者認為方便時，可以開始發射此序列，並以觀察者期望的任何速率發射，而不會破壞序列的完整性。例如，如果將靜態的可迭代對象轉換為 Observable，則無論稍後何時訂閱或觀察這些項目的頻率如何，該 Observable 都會發射相同的項目序列。冷 Observable 發射的項目示例可能包括資料庫查詢、文件檢索或 Web 請求的結果。

熱的 Observable 在創建時立即開始生成要發射的項目。訂閱者通常從熱的 Observable 發射的項目序列的中間某處開始觀察，從建立訂閱後 Observable 發射的第一個項目開始。這樣的 Observable 以自己的速度發射項目，並且由其觀察者來跟上。熱的 Observable 發射的項目示例可能包括滑鼠和鍵盤事件、系統事件或股票價格。

當冷的 Observable 被多播時（當它被轉換為可連接的 Observable 並且它的 Connect 方法被調用時），它實際上變成了熱的，並且為了背壓和流量控制的目的，應該將其視為熱的 Observable。

冷的 Observable 非常適合某些 ReactiveX 實現所實現的反應式拉取背壓模型（在其他地方描述）。熱的 Observable 通常不適合反應式拉取模型，並且是其他流量控制策略的更好候選者，例如使用此頁面上描述的操作符，或者像 Buffer、Sample、Debounce 或 Window 的操作符。