消息隊列：Kafka和RabbitMQ

消息隊列： Kafka，RabbitMQ

（部分： 技術和基礎設施）

簡短摘要

• Apache Kafka是分布式事件日誌（日誌），專註於流式傳輸，復制和橫向分批滾動。
• RabbitMQ是AMQP隊列經紀人，具有靈活的路由（exchanges/bindings），優先級，TTL，確認和經典隊列任務。

兩種工具都是成熟的，但解決了不同的問題：用於可擴展流和分析的Kafka，用於在線任務編排RabbitMQ，RPC和多種路由。

在iGaming中合適的位置

• 需要高的TPS事件（投註，遊戲事件，遙測）和橫向滑道。
• 冷熱re-consum（重新讀取磁帶數據），重建和復合對於單元（平衡，玩家狀態）很重要。
• 我們需要流過程（Kafka Streams/ksqlDB/Flink）來進行實時聚合：錦標賽領導者，負責任的遊戲限制，反流信號。

• 需要經典的任務隊列：KYC檢查，延遲/重復付款，發送電子郵件/SMS/push，webhooks到PSP。
• 靈活的路由（topic/direct/fanout）、優先級、TTL、延遲、死信和RPC模式。
• 需要嚴格的消費者限制（prefetch/QoS）、簡單的負載管理和快速的回程。

常見結果：用於事件和分析的Kafka+用於編排和集成的RabbitMQ。

數據模型和路由

Kafka

拓撲→分成部分，每個都是有序的日誌。
消息密鑰定義密鑰內的批次→順序。
消費者讀取外部，消費者組縮放處理。
按時間/範圍重組；log compaction存儲密鑰的最新版本。

RabbitMQ

Exchanges （direct/fanout/topic/headers）+bindings →消息進入靜音。
確認（ack/nack/requeue），publisher confirms，priorities，TTL，dead-letter（DLX/DLQ）。
Quorum queues（Raft）高可用性；lazy queues節省RAM。

送貨保證和等效性

最多：沒有撤退；損失風險，最小延遲。
On-least-once：默認標準→可以重復→偶數手機（查詢/交易密鑰,upsert, dedup表,outbox）。
Exactly-once：在Kafka中，通過捆綁等效生產商+交易拓撲+協調消費來實現，但更常見的是更昂貴和更復雜；在RabbitMQ-有限和骨頭。在實際的支付/利率流中，適用嚴格的at-least-once+等效性。

• 每個事件/命令的唯一標識鍵（UUID/ULID）。
• 服務的DB+更改數據捕獲（Debezium）中的Outbox模式→防止「雙重記錄」。
• Dedup （key, created_at）在TTL的單獨棧中。

消息順序/順序

Kafka保證黨內的秩序。選擇鍵以使實體的所有「生命」都以相同的方式出現（例如，平衡的「player_id」）。
RabbitMQ的順序在重復交付/多次使用時未得到嚴格保證；在卡夫卡（Kafka）或通過單人主動消費者和線程序列化中，對管道順序至關重要。

設計拓撲和隊列

Kafka:

粒度： "域。事件「（例如，」payments。deposit.created`).

鍵：「player_id」、「account_id」、「bet_id」用於有序性。
對目標TPS的批次=N（規則：1批≈ X 消息/秒/consumer）；為增長奠定基礎。
重組：事件-小時/天；復合為「狀態」。

RabbitMQ:

按域排序： 'payments。direct`, `risk.topic`.

消費者隊列： 'kyc。checker.q`, `psp.webhooks.retry.q`.

每個工作隊列的DLQ；延遲到backoff。
Prefetch設置並發,quorum隊列設置為HA。

錯誤、轉發和DLQ

對錯誤進行分類：臨時（網絡/PSP 5xx） →中繼；致命（驗證，電路）→一次性DLQ。
Exponential backoff+jitter，後退限制，「poison-pill」檢測。
單獨的回程步驟（5s, 1m, 5m, 1h）。
DLQ處理程序：alert、trace、手動解析、帶補丁的re-inject。

數據和模式合同

使用Avro/Protobuf+Schema Registry（對於Kafka-事實上的標準）。
轉化：反向兼容更改（添加可選字段），禁止中斷遷移。
PII字段-加密/令牌化；遵守GDPR和當地規範。

監測、觀察和SLO

生產者/消費者的度量標準：lag, throughput,錯誤,retrai,處理時間。
Logi+Tracing（相關ID：'trace_id'，'message_id'）。
SLO： p99的發布/交付潛伏期,允許的消費者lag,從假恢復的時間。
Alerts對DLQ的增長、過高、政黨/法定人數的下降。

安全性和合規性

過境中的TLS，密碼加密（SOPS/Vault），受ACL/RBAC限制。
敏感域的單個拓撲/隊列（付款，KYC）。
對出版物/訂閱進行審核,將密鑰存儲在代碼之外。
區域要求（EU/Turkey/LatAm）：重建、存儲本地化、掩蓋。

高可用性、容錯和DR

Kafka:

最低3-5經紀人集群；replication.factor ≥ 3.

min.insync.replicas和acks=所有用於持久記錄。
DR的跨區域復制（MirrorMaker-2）。

RabbitMQ:

Quorum queues for HA,偶數/奇數零和法定數。
Federation/Shovel用於復制數據中心間,DR腳本。
冷暖看臺，開關測試。

性能和調音

• `linger.ms` и `batch.用於戰鬥的大小；「compression」。type` (lz4/zstd).
• 'acks=all'，但要註意潛伏期；tun'max。in.flight.requests.per.具有等效性的連接。

• 有足夠的政黨；NVMe驅動器；10/25G網格；JVM的GC設置。

• 正確的組管理，'max。poll.interval.ms'，在後座議員下暫停派對。

• 戰鬥中的出版商認罪；頻道重新使用。

• 處理時間為「prefetch」（例如50-300）；lazy queues for great backlog。
• 在nodas上排起熱隊；TSR/文件描述符。

iGaming的典型模式

Outbox+Kafka可可靠地發布域事件（投註,存款）。
RabbitMQ RPC用於同步集成查詢（檢查KYC文檔，計算獎金）。
傳奇模式：通過事件（Kafka）和命令（RabbitMQ）進行編排，並采取補償步驟。
Fan-out通知：從一個事件→ CRM, antifrod, analytics。
具有漸進延遲和DLQ的智能復制PSP webhook。

遷移和混合體系結構

從RabbitMQ開始「運營」，添加Kafka用於事件和分析。
配音出版物：outbox服務 雙向連接器（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.retry.1m.q'（TTL=60 s，DLX指向正在運行）

DLQ: `psp.webhooks.dlq`

• `psp.webhooks.q` → `x-dead-letter-exchange=psp.retry.exchange`
• `psp.webhooks.retry.1m.q` → `x-message-ttl=60000`, `x-dead-letter-exchange=psp.work.exchange`
• `psp.webhooks.dlq' →監控和手動解析。

示例： 用於投註的Kafka topic

Topik： 'bets。placed.v1'，分期付款：24，RF=3，續約7天。
消息密鑰是「player_id」或「bet_id」（選擇對順序更重要的內容）。

Схема: Protobuf/Avro с `bet_id`, `player_id`, `stake`, `odds`, `ts`, `idempotency_key`.

測試和質量

合同測試Prodewser/Consewmer+電路驗證（Schema Registry）。
混沌測試：鼻子掉落，網絡延遲，裂紋。
目標TPS的負載運行，p99驗證，lag增長和恢復。

結果

Kafka是事件的主幹和流媒體：按鍵排序，重組/復合，高TPS，實時分析。
RabbitMQ-任務操作隊列：靈活的路由、確認、優先級、轉發/DLQ、RPC。
在iGaming中，最佳做法是互補使用：Kafka中的事件和分析、RabbitMQ中的集成/編排任務，以及統一的電路標準、等效性、監控和嚴格的SLO。