メッセージキュー：KafkaとRabbitMQ

メッセージキュー： Kafka、 RabbitMQ

（セクション： 技術とインフラ）

概要

メッセージキューは、iGamingのイベント指向アーキテクチャ（EDA）の基礎です。これらは、レート、支払い、不正防止、CRM、通知、分析のマイクロサービスをリンクします。実際には、2つのクラスのソリューションが最も一般的です：

Apache Kafkaは、パーティーを通じたストリーミング、レプリケーション、水平スケーリングに焦点を当てた分散イベントログ（ログ）です。
RabbitMQは、柔軟なルーティング（取引所/バインディング）、優先順位、TTL、確認、古典的なキュー・タスクを備えたAMQPキュー・ブローカーです。

両方のツールは成熟していますが、さまざまな問題を解決します。Kafka-スケーラブルなストリームと分析、RabbitMQ-運用タスクのオーケストレーション、RPC、多様なルーティング。

iGamingで適切な場所

カフカ-選択するとき：

当事者を通して高いTPSイベント（ベット、ゲームイベント、テレメトリー）と水平スケールが必要です。
コールド/ホット再消費（テープデータの再読み込み）、集計（バランス、プレーヤーの状態）の保持と圧縮が重要です。
リアルタイム集計のためのストリームプロセス（Kafka Streams/ksqlDB/Flink）が必要です。

RabbitMQ-次の場合を選択します：

古典的なタスクキューが必要です：KYCチェック、延期/繰り返し支払い、電子メール/SMS/プッシュ、 WebhookをPSPに送信します。
柔軟なルーティング（トピック/直接/ファンアウト）、優先順位、TTL、遅延、デッドレターおよびRPCパターン。
消費者ごとの厳格な制限（プリフェッチ/QoS）、シンプルな負荷管理、高速リトレイが必要です。

頻繁な成果：イベントと分析のためのKafka+オーケストレーションと統合のためのRabbitMQ。

データモデルとルーティング

カフカ

トピックは→パーティーに分かれており、それぞれが注文されたログです。
メッセージキーは、キー内のバッチ→順序を定義します。
消費者はオフセットを読み取り、消費者のグループは処理を拡大します。
時間/量による保持；log compactionはキーの最新バージョンを格納します。

RabbitMQ

取引所（direct/fanout/topic/headers）+bindings→メッセージはキューに入ります。
確認（ack/nack/request）、パブリッシャー確認、優先順位、TTL、デッドレター（DLX/DLQ）。
高可用性のためのクォーラムキュー（いかだ）；RAMを保存するための遅延キュー。

配達保証およびidempotency

At-once：リトレイなし；損失の危険、最低の遅れ。
最低1回：デフォルトの標準→重複→idempotentハンドラ（リクエスト/トランザクションキー、upsert、 dedupテーブル、outbox）が可能です。
正確に一度：カフカでは、特権的なプロデューサー+トランザクショントピック+合意された消費は連動して達成されますが、より多くの場合、それはより高価でより困難です。RabbitMQ-限られた骨で。実際の支払い/ベットフローでは、最低1回+厳格なidempotenceが適用されます。

Idempotencyの練習：

イベント/コマンドごとに一意のidempotency-keys （UUID/ULID）
+Change Data Capture （Debezium）サービスデータベースのOutboxパターン→二重書き込み防止。
TTLとは別の行に（key、 created_at）でデダップします。

注文/メッセージ注文

カフカはパーティー内の注文を保証します。キーを選択すると、エンティティの「life」全体（たとえば、balanceの'player_id'）が1つのキーになるようになります。
RabbitMQ注文は、繰り返し配信/複数の消費者で厳密に保証されていません。注文に重要なパイプライン-Kafkaまたはシングルアクティブなコンシューマーとストリームのシリアライズを通じてより良い。

トピカルとキューのデザイン

カフカ：

粒度：'ドメイン。event'（例えば、'payment。沈殿物。'）を作成しました。
キー：'player_id'、 'account_id'、 'bet_id'
バッチ=ターゲットTPSによるN（ルール：1バッチ≈ Xメッセージ/秒/消費者）；成長のための在庫を置きなさい。
保持：イベント-時間/日；compaction-「states」。

RabbitMQ：

ドメイン別の交換：'支払い。直接'、'リスク。トピック'。
消費者のためのキュー：'kyc。チェッカーだよ。q'、'psp。webhooks。再試行してください。Q'。
バックオフのワークキュー遅延あたりのDLQ。
PrefetchはHAの並行性、クォーラムキューを指定します。

エラー、リトレイ、DLQ

エラーの分類：一時的な（ネットワーク/PSP 5xx）→リトレイ；致命的（検証、スキーム）→直ちにDLQ。
指数関数バックオフ+ジッタ、リトレイ限界、毒薬検出。
ステップ（5s、 1m、 5m、 1h）で再試行キューを分離します。
DLQハンドラ：アラート、トレース、手動解析、パッチによる再注入。

データ契約と回路図

Avro/Protobuf+スキーマレジストリ（Kafka-de facto standard）を使用します。
バージョン管理：下位互換性のある変更（オプションフィールドの追加）、マイグレーションの破損の禁止。
PIIフィールド-暗号化/トークン化；GDPRおよびローカル規則に従って下さい。

モニタリング、観測、SLO

生産者/消費者の指標：遅延、スループット、エラー、レトライ、処理時間。

ログ+トレース（相関ID： 'trace_id'、 'message_id'）

SLO： p99-latency of publication/delivery、許容される消費者の遅延、ファイル後の回復時間。
DLQの成長、ラグ超過、パーティー/クォーラムの低下に対するアラート。

安全性とコンプライアンス

トランジット中のTLS、秘密暗号化（SOPS/Vault）、限られたACL/RBAC。
機密ドメイン（決済、KYC）のトピック/キューを分けます。
パブリケーション/サブスクリプションの監査ログ、コード外のキーの保存。
地域要件（EU/トルコ/LatAm）：保持、ストレージのローカライズ、マスキング。

高可用性、フォールトトレランス、DR

カフカ：

少なくとも3-5ブローカーのクラスター；複製します。因子≥ 3。
ミン。insync。replicasおよびacks=耐久の記録のためのすべて。
DRRのクロスリージョナルレプリケーション（MirrorMaker-2）

RabbitMQ：

HAのクォーラムキュー、クォーラムを持つノードの偶数/奇数数。
データセンター間レプリケーション用のフェデレーション/シャベル、DRスクリプト。
冷たい/暖かい立場、転換テスト。

パフォーマンスとチューニング

カフカ（プロデューサー）：

「残りました」MSのバッチ。サイズ'butching；'圧縮します。タイプ'（lz4/zstd）
'acks=all'ですが、待ち時間を監視します。チューンマックスだ。中に入っています。フライトだ。ご要望をお待ちしております。per。 connection'とidempotency。

カフカ（ブローカー/トピック）：

十分なパーティー；NVMeはグリッド10/25Gドライブします。JVM GCの設定。

カフカ（消費者）：

正しいグループ管理、'最高。投票。インターバル。ミスパーティーを休止させて。

RabbitMQ（プロデューサー）：

出版社はバッチで確認します。チャネルの再使用。

RabbitMQ（キュー/消費者）：

'prefetch'（例：処置の時間によって50-300）；大きなバックログのための遅延キュー。
ホットキューをノードに投稿する。TCPチューニング/ファイル記述子。

iGamingの典型的なパターン

ドメインイベントの信頼性の高い出版のためのOutbox+Kafka（賭け、入金）。
統合への同期要求（KYCドキュメントチェック、リベート計算）のためのRabbitMQ RPC。
佐賀パターン：イベント（Kafka）とチーム（RabbitMQ）によるオーケストレーション。
ファンアウト通知：1つのイベント→CRM、不正防止、分析から。
プログレッシブディレイとDLQを備えたスマートなPSP Webhook。

移行とハイブリッドアーキテクチャ

「オペレーティングシステム」のためのRabbitMQから始めて、イベントと分析用のKafkaを追加します。
重複した出版物：サービス→アウトボックス→コネクタ（Kafka+RabbitMQ）が完全に安定化するまで両方向に。
Kafka Streams/ksqlDBにアナリティクス/ストリーム集約加入者を徐々に移行します。

ミニセレクションチェックリスト

1.ロード/TPS>数万/秒？→Kafka。
2.雑誌のように保存と再読み込みが必要ですか？→Kafka。
3.柔軟なルーティング、優先順位、遅延配信、RPC？→RabbitMQ。
4.厳密なキー順序および横のスケール→Kafka（キー/党）。
5.並行管理→RabbitMQを使用したシンプルなタスク/ワークキュー。
6.Kafka（イベント）+RabbitMQ（オーケストレーション）の組み合わせが理想的です。

最小構成の例

例： RabbitMQの遅延レトライとDLQ（ポリシー経由）

ワークキュー： 'psp。webhooks。Q'

レトラスキュー： 'psp。webhooks。再試行してください。1m。q '（TTL=60、 DLXは運用に戻る）

DLQ： 'psp。webhooks。dlq'

ポリシー（概念的に）：

'psp。webhooks。q'→'x-dead-letter-exchange=psp。再試行してください。「交換」
'psp。webhooks。再試行してください。1m。q'→'x-message-ttl=60000'、'x-dead-letter-exchange=psp。仕事だよ。「交換」
'psp。webhooks。dlq'→モニタリングと手動デバッグ。

例：カフカの賭けトピック

トピック：'賭け。配置されました。v1'、パーティー：24、 RF=3、保持7日。
メッセージキーは'player_id'または'bet_id'です（注文に重要なものを選択してください）。
Схема： Protobuf/Avro-'bet_id'、 'player_id'、 'stake'、 'odds'、 'ts'、 'idempotency_key'。

テストと品質

契約テストプロデューサー/消費者+スキーマレジストリ。
カオステスト：ノードドロップ、ネットワーク遅延、スプリットブレイン。
負荷は、ターゲットTPS、 p99チェック、ラグの増加と回復で実行されます。

概要

Kafka-イベントハイウェイとストリーミング：キーの順序、保持/圧縮、高いTPS、リアルタイム分析。
RabbitMQ-運用タスクキュー：柔軟なルーティング、確認、優先順位、再試行/DLQ、 RPC。
iGamingでは、ベストプラクティスは補完的な使用です：Kafkaのイベントと分析、RabbitMQの統合/オーケストレーションタスク、均一なスキーマ標準、idempotency、監視、厳密なSLO。