注文パイプライン
注文は請求、配送、分析へと流れ、それぞれが同じストリームを自分のペースで読み取ります。
コアデータバックグラウンド処理
イベントストリーミング
コンシューマーグループ、確認応答、クラッシュしたコンシューマーが残したメッセージの自動回復に対応した、追記専用のイベントストリーム。
- 追記専用ログ
- 永続
- ストリームあたりのコンシューマーグループ
- N
- クラッシュで失うメッセージ
- 0
ステップ 1 / 5
イベントを発行
注文サービスがイベントを追記し、そのIDを受け取ります。
サンプルセッションplaying
# イベントを発行
hotkv> XADD orders * type created order 1182 total 49.00
"1790985600123-0"
実際のHotKVコマンドと応答例を使ったアニメーションのウォークスルーです。任意のステップをクリックすると、そこに移動します。 コマンドと応答は、HotKVで実際に入力し表示されるとおり英語のままです。
課題
イベントに反応するサービスには、キュー以上のものが必要です。複数の独立したコンシューマーが同じイベントを必要とし、各コンシューマーグループはインスタンス間で作業を分担しなければなりません。そしてインスタンスがメッセージを抱えたまま停止したら、誰かがそれに気づいて引き継ぐ必要があります。
HotKVでの解決方法
ストリームは追記専用のログです。各コンシューマーグループはそれを独立して読み取り、各メッセージをグループの1つのメンバーに配信し、そのメンバーが確認応答するまで保留にしておきます。XAUTOCLAIMは、保留が長すぎるメッセージを正常なコンシューマーに渡します。
ステップごとに
コマンドごとに何が起きるか
- 01
イベントを発行
注文サービスがイベントを追記し、そのIDを受け取ります。
XADD orders * type created order 1182 total 49.00 - 02
2つのグループ、1つのストリーム
請求と配送はそれぞれ独自のグループを持ち、どちらもイベントを受け取ります。
XGROUP CREATE orders billing 0 MKSTREAM - 03
消費
請求のインスタンスが、何か届くまでブロックしながら、自分のグループの新しいメッセージを読み取ります。
XREADGROUP GROUP billing billing-1 COUNT 10 BLOCK 5000 STREAMS orders > - 04
確認応答
請求書が作成されると、請求側が確認応答し、メッセージは保留リストから外れます。
XACK orders billing 1790985600123-0 - 05
クラッシュから回復
配送のインスタンスがメッセージを抱えたまま停止しました。60秒間アイドルが続くと、正常なインスタンスがそれらを引き取ります。
XAUTOCLAIM orders shipping shipping-2 60000 0-0 COUNT 25
活用シーン
実際のシナリオ
監査とアクティビティフィード
ユーザーの操作はストリームに追記され、履歴を必要とするどのサービスでもリプレイできます。
IoTの取り込み
デバイスのメッセージはストリームにバッファされ、負荷に応じてスケールするワーカーのグループが処理します。
標準搭載
得られるもの
追記専用ログ
エントリーには時系列順のIDが付き、長さや経過時間でトリミングできます。
XADDXTRIMコンシューマーグループ
各グループがすべてのメッセージを受け取り、メンバー間で作業を分担します。
XGROUPXREADGROUP確認応答
メッセージは確認応答されるまで保留のまま残ります。
XACKXPENDING自動回復
アイドルが長すぎるメッセージは、別のコンシューマーが引き取ります。
XAUTOCLAIMXCLAIMよくある質問
古いイベントをリプレイできますか？
はい。XRANGEはIDでストリームの任意の部分を読み取れ、新しいコンシューマーグループは先頭から開始できます。
ストリームが際限なく大きくなるのを防ぐには？
XTRIM、またはXADDのMAXLENやMINIDオプションでトリミングします。
XADDで重複イベントを防げますか？
XADDは冪等なプロデューサーID（IDMP）に対応しているため、再試行した発行で2つ目のエントリーは作られません。XADDのリファレンスをご覧ください。
関連するユースケース
ご自身のワークロードで試してみましょう
HotKVはRedisプロトコルに対応しているため、既存のクライアントを向けるだけで、これらと同じコマンドを実行できます。