バックプレッシャーとフロー制御（リアクティブストリーム）

速度差が引き起こす「圧倒」問題

非同期パイプラインでは、データを生み出す側（生産者・producer）と処理する側（消費者・consumer）の速度が一致しません。秒間10万件を吐くセンサーに対し、DBへ書く消費者は秒間1万件しかさばけない、といった状況は普通に起きます。このとき差分の9万件はどこへ行くのか。素朴な非同期実装では、両者の間にあるキューやバッファへ溜まり続けます。

問題は、この中間バッファが無限に膨らむことです。生産者が止まらない限りキューは単調増加し、やがてメモリを食い尽くしてOutOfMemoryでプロセスが落ちます。GCを採用する処理系では、その手前で巨大なヒープを掃くためにGCが頻発し、レイテンシが崩壊します。つまり「速い生産者が遅い消費者を圧倒する（overwhelm）」状態を、システムは静かなメモリ膨張という形で被るわけです。

バックプレッシャー＝逆向きの制御シグナル

バックプレッシャー（backpressure）とは、消費者が「自分はいま、あとどれだけ受け取れるか」を生産者へ逆方向に伝え返す仕組みです。データは生産者→消費者へ流れますが、制御信号は消費者→生産者へ逆流します。これにより生産者は、消費者の処理能力を超えた送出を自ら控えられます。

押し方には2つの型があります。push型は生産者が都合よく送りつける方式で、消費者の事情を無視するためバッファ溢れに弱い。pull型は消費者が要求した分だけ生産者が送る方式で、流量の上限が消費者側に握られるため本質的に溢れません。バックプレッシャーの実装とは、push的なデータフローへpull的な制御を後付けし、実効的にpull型へ変換することだと言えます。

Reactive Streamsのdemandシグナル

この変換を標準化したのがReactive Streams仕様です。Publisher（生産者）、Subscriber（消費者）、両者を仲介するSubscriptionの3者で構成され、フロー制御の核はSubscriptionが持つrequest(n)というメソッドです。

Publisher  --- subscribe(Subscriber) --->
Subscriber <-- onSubscribe(Subscription) --
Subscriber --- subscription.request(n) --->   // demand を発行（逆向き）
Publisher  --- onNext(item) × 最大 n 回 --->   // 要求された分だけ送る
Publisher  --- onComplete() / onError(e) --->  // 終端シグナル

肝はrequest(n)です。購読が確立すると、SubscriberはonSubscribeで受け取ったSubscriptionに対し「いまn件まで受け取れる」とdemand（需要）を発行します。Publisherはこの累積demandを超えてonNextを呼んではならない、と仕様が義務付けています。Subscriberは1件処理し終えるごとにrequest(1)を足す、あるいはまとめてrequest(64)し残りが少なくなったら補充する、といった形で自分のペースで蛇口を開け閉めします。

// 消費者が「処理が終わったら次を要求する」pull ループ
onSubscribe(s):  this.sub = s;  s.request(BATCH)   // 初期 demand
onNext(item):    process(item)                     // ここがボトルネック
                 if (--remaining == 0)
                   remaining = BATCH; sub.request(BATCH)  // 補充

この仕組みにより、Publisherが秒間10万件を生成できても、Subscriberがrequestした総数を超える分は生産者側で待たされる。中間に溜まる未処理アイテムの上限は「未消化のdemand」に等しく、消費者が決めた有限値に固定されます。速度差はキューの膨張ではなく、生産者の送出抑制として吸収されるわけです。これはイベントループ上で多数のストリームを同時にさばく際、各ストリームのメモリ使用量を予測可能に保つうえで決定的に効きます。

demandで止められない発生源への戦略

request(n)が機能するのは、生産者が送出を遅延できる場合だけです。ファイル読み込みやDBカーソルのように「読む速度を自分で決められる」源（cold source）なら、demandに合わせて読み出しを止めれば済みます。

困るのは、マウス移動・センサー・外部からのプッシュ通知のように**こちらの都合で止められない発生源（hot source）**です。イベントは現実世界の都合で発生し、requestしていなくても到着します。ここでは「溢れた分をどうするか」を設計者が明示的に選ぶ必要があり、有限のバウンドキューと組み合わせた緩衝戦略を取ります。

これらはいずれも有限のキャパシティを前提に「何を犠牲にするか」を選ぶ点が共通します。latestはUIの座標更新のように「最後の値だけ正しければよい」場合に最適で、dropは逆に「最初に来たものを優先」したいログ収集に向きます。重要なのは、どの戦略も無限バッファという幻想を捨て、有界性（boundedness）を回復するためにあるということです。戦略を選ばないこと自体が、暗黙に「無限バッファ＝いつか必ず溢れる」を選んでいることになります。

demand伝播のコストと連鎖

request(n)は演算子チェーンを上流へ1段ずつ伝わります。mapやfilterはdemandをそのまま透過しますが、buffer(k)のような集約演算子は「下流のdemand 1に対し上流へk件request」のようにdemandを変換します。長いチェーンではrequest呼び出し自体が同期オーバーヘッドになるため、実装は1件ごとではなくバッチでrequestを補充し、残りが閾値（例：バッチの1/4）を切ったら次のバッチを先行要求する、という最適化を行います。これはスレッドプールのタスク粒度調整と同じく、「制御の細かさ」と「制御自体のコスト」のトレードオフです。

まとめ

バックプレッシャーは、(1)消費者の受容能力を生産者へ逆向きに伝える制御で、無限バッファ膨張によるOOMを根本から防ぐ。(2)Reactive Streamsはこれをrequest(n)というdemandシグナルで標準化し、pushなデータフローを実効的にpull型へ変換する。未処理アイテムの上限は消費者が決めた有限値に固定される。(3)止められないhot sourceには、バウンドキューとdrop/latest/bufferなどの有限緩衝戦略を明示的に選び、有界性を回復する。「キューを大きくする」のではなく「生産レートを消費能力へ合わせる」——この向きの逆転こそが、高並行ストリーム処理を予測可能に保つ要点です。