高頻度の状態更新を扱うとき、入力を一件も落とさないFIFOは安全な選択に見えます。ところが、消費側が欲しいのが履歴ではなく『いまの状態』なら、古い更新を丁寧に処理するほど最新値の到着が遅れることがあります。

2026年8月7日、ISO C++ BlogはAjay Pandey氏によるイベント合流キューの設計を紹介しました。論点は単なる高速化ではなく、同じキーへ短時間に届く更新のうち、何を残せば正しさを保てるかです。

FIFOを置き換えてよい条件は何でしょうか。イベントの意味からマージ規則を作り、C++の同期、順序、容量制限まで一つの契約として設計する道筋を追います。

同じキーの更新を残すとFIFOは「現在」を遅らせる

たとえば、同じ機器から200ミリ秒の間に 10、20、30 という状態値が届いたとします。FIFOは3件を順番に渡しますが、画面や監視コンポーネントが現在値だけを必要とするなら、途中の 10 と 20 は消費時点ですでに古い値です。

イベント合流キューは、短い有限のウィンドウ内で同じ論理キーの更新をまとめます。リンク先のACCU Overload掲載記事では、最新値を残す方式、終端状態を守る方式、数値を集計する方式が比較されています。

同じウィンドウへ届いた更新	最新値優先	区間集計
K:10 → K:20 → K:30	K:30	count=3, avg=20

ここで減らしているのは『不要と定義できた中間状態』です。監査ログや取引のように一つひとつの遷移が意味を持つなら、同じ見た目のデータでも合流してはいけません。

合流キューはキー・マージ規則・フラッシュ時刻で契約を作る

合流を正しくするには、少なくとも三つを明文化します。どのイベントを同一視するかというキー、古い値と新しい値をどう合わせるかというマージ規則、いつ下流へ渡すかというフラッシュ条件です。

マージ規則はデータ構造ではなく業務上の意味から決めます。最新値優先なら新しい更新が古い更新を置き換え、終端状態優先なら closed のような状態を後続の非終端更新から守り、集計なら件数・合計・最小値など必要な情報を一つへ畳みます。

順序も自動では決まりません。Diffusionのconflation資料が示すように、古い位置を新しい値で置き換える方式と、新しい値を末尾へ付け直す方式では、キーをまたいだ出力順が変わります。『キーの初出位置を保つ』『最新更新の位置へ移す』のどちらを保証するかまで公開契約に含めたいところです。

C++では複数producerと単一coalescerに責務を分ける

紹介された設計は、複数のproducerが短い enqueue 処理でイベントを投入し、単一のworkerが保留中の状態マップとマージ規則を所有する構成です。取り込み、合流、dispatchを分けることで、下流のシリアライズやI/Oをproducer側の待ち時間へ持ち込みにくくします。

保留領域は、到着順を持つ配列と、キーから配列位置を引く索引を組み合わせられます。初めて見るキーなら追加し、既存キーならその位置のイベントへマージ規則を適用するため、単一workerの中では所有関係を追いやすくなります。

待機には std::condition_variable と std::unique_lock を使えます。現行のC++ドラフトにあるcondition_variableの規定では、待機が通知なしに戻る可能性も含め、述語付き wait は条件を満たすまで再評価する形で定義されています。終了フラグや保留イベントの有無を述語に入れ、終了時には残りをdrainしてからworkerをjoinする設計が境界条件をはっきりさせます。

dispatchはmutexを解放してから実行します。ロック中に外部callbackやI/Oを呼ぶと、その遅さがproducerの enqueue に波及するためです。なお、掲載コードは設計を説明する概念スケッチであり、特定の負荷に対する性能保証ではありません。

合流ウィンドウを広げるほど削減率と遅延が引き換えになる

ウィンドウを短くすると待ち時間は抑えやすい一方、同じキーの更新が重なる機会は減ります。長くすると多くの更新を畳めますが、最新状態を下流へ伝えるまでの待ち時間が増えます。最適値は固定の定石ではなく、入力の揺らぎと下流が許容する鮮度から決めるパラメーターです。

運用では、受理数、出力数、置換数、合流を迂回した件数、flush頻度、batchサイズ、dispatch時間を分けて測ります。目安として 1 - 出力数 / 受理数 を追えば削減割合は見えますが、その値が高いだけでは成功とは言えません。キュー内待ち時間と下流で観測する状態の鮮度も並べて評価する必要があります。

さらに、終端状態や優先イベントをウィンドウ満了前にflushするなら、通常更新とは別の規則が増えます。削減率だけを上げる調整ではなく、どのイベントを何ミリ秒以内に届けるかというSLOへ落とし込むと判断しやすくなります。

イベント合流だけではバックプレッシャーと容量制限を代替できない

一つのキーにつき保留イベントを一件だけ持つ方式なら、メモリ量は総イベント数より『ウィンドウ内で活動中のキー数』に強く左右されます。ただし、毎回異なるキーが大量に来れば保留領域は増えるため、合流しただけで容量問題が消えるわけではありません。

バックプレッシャーは別の契約です。Reactive Streamsは、速い送信側が受信側へ任意量のbufferを押し付けないよう、非同期境界で需要を伝える仕組みとしてback pressureを位置付けています。合流は『何を残すか』を変え、バックプレッシャーは『どれだけ受けられるか』を制御するため、役割が異なります。

容量上限へ達したときは、送信側へ圧力を返す、損失を許せる更新だけを落とす、早めにflushする、重要イベントを永続領域へ逃がす、といった方針をイベント種別ごとに決めます。キーでpartitionする拡張もありますが、hot key、partitionをまたぐ順序、shutdown、観測性が複雑になるため、単一coalescerの競合を計測してから検討する順序が自然です。

監査・取引・コマンドは合流せず、意味のある履歴を守る

監査記録、会計取引、非冪等なコマンド、event sourcing、正確なreplayに使うイベントは、途中の一件にも意味があります。これらを『同じキーだから』という理由だけで上書きすると、性能ではなく正しさを失います。

同じパイプラインへ状態更新とコマンドが混在するなら、明示的なbypass経路を用意します。合流対象のテストでは、最新値、終端状態、集計結果を決定的な入力で確かめ、さらにウィンドウ満了、bypass、終了時drain、複数producer、ロック外dispatchという時間境界を分けて検証します。

テストの期待値は『全イベントがFIFO順に出ること』ではありません。文書化した合流契約どおりの状態が、定めた時間と順序で出ることです。ここを変えると、テストのものさしも変わると分かります。

FIFOを置き換える条件は「古い更新が不要」と説明できること

イベント合流キューが向くのは、消費側が完全な履歴ではなく現在状態や区間集計を必要とし、新しい更新が古い更新をどう代替するかを明示できる場面です。キー、マージ規則、順序、flush、bypassを契約にすれば、C++の実装はその意味を守るための同期機構として組み立てられます。

一方、合流はバックプレッシャーでも永続ログでもありません。容量上限と需要制御を別に設計し、履歴が必要なイベントはFIFOや耐久ストレージへ残す必要があります。

最初に問うべきなのは『何件減らせるか』ではなく、『どの情報を失っても正しいと言えるか』です。この問いに答えられるキューだけが、古い更新を抱えずに現在を届けられます。

出典

• Title: A Coalescing Event Queue for High-Frequency Systems -- Ajay Pandey
• URL: https://isocpp.org//blog/2026/08/a-coalescing-event-queue-for-high-frequency-systems-ajay-pandey