イベントストア

その EventStore interfaceはsocketio4jの分散イベント同期レイヤーを定義します。 これは、1つ以上のサーバーインスタンスにまたがるルームの参加・退出、確認応答、セッション変更、ノード間同期などの内部イベントを公開および購読するための統一された抽象を提供します。

主な特徴

• 統一されたイベントAPI — すべてのバックエンドで同じ公開/購読モデル

• 型付きディスパッチ — リスナーは強い型の EventMessage オブジェクトを受け取る

• ノード認識フィルタリング — 実装は通常、経由で自己発生イベントを無視します nodeId

• プラグ可能なトランスポート — Kafka、Redis Streams、Hazelcast、NATS、インメモリフォールバック等

• ライフサイクル制御 — 標準化された publish, subscribe, unsubscribe, shutdown

仕組み

• publish → 経由でのバックエンド固有の送信 publish0

• subscribe → 経由でイベントリスナーを登録 subscribe0

• unsubscribe → 経由でリスナーを削除してクリーンアップ unsubscribe0

• shutdown → 経由でバックエンドリソースを解放 shutdown0

• 実装は経由のメソッドを通じてトランスポートの振る舞いを提供します *0 メソッド；インターフェースはフローとエラー処理を標準化します

イベントルーティングのプロパティ

プロパティ	意味
EventStoreMode	MULTI_CHANNEL （イベントごとのストリーム/トピック）または SINGLE_CHANNEL （統一チャネル）
EventStoreType	トランスポートのファミリを宣言します： STREAM, PUBSUB, LOCALなど
PublishMode	期待される信頼性を示します： RELIABLE または UNRELIABLE
nodeId	ノードを識別します；ローカルイベントの再処理を避けるために使用されます

注： getNodeId() はデフォルトでランダムなIDを提供します。 分散デプロイでは、を構成して、 安定したノードID 経由で StoreFactory.

利点

👍 コード変更なしで分散トランスポートを切り替え可能 👍 中央集約されたエラーロギングとフローセマンティクス 👍 カスタムバックエンドのための明確な拡張フック 👍 トランスポートの違いを抽象化

制限事項

ℹ️ 配信保証は実装に依存します—インターフェースによって強制されません ℹ️ 永続性、順序、重複排除はバックエンドの責任です ℹ️ nodeIdベースのローカルフィルタリングは重複を避けるために尊重される必要があります

---

配信保証

その EventStoreインターフェースは配信保証を定義しません. 信頼性、リプレイ、および順序は選択したバックエンドに完全に依存します（例：Redis Streams = 少なくとも一度；Redis Pub/Sub = ベストエフォート；Kafka = 少なくとも一度；Memory = ローカルのみ）。