消息队列：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。