活动流和实时数据

（部分： 技术和基础设施）

简短摘要

Event-Streaming是事件出现时的处理和交付。对于iGaming来说，这意味着对投注、存款、反欺诈信号、负责任的游戏限制、积分榜和个人离场员的即时反应。基本砖：事件总线（Kafka/Pulsar），流媒体引擎（Flink/ksqlDB/Spark Structured Streaming），事务性DB（Debezium）的CDC，用于在线ML的功能商店和真实时间分析（实例化视图，OLAP）。

在iGaming中至关重要的

反亲和风险：在<100-300毫秒内进行交易计分，行为模式，锁定和升级的相关性。

负责任的游戏： 控制极限,损失率,异常行为-alerta和自动限制实时.

付款：状态通风，PSP webhooks，智能背影，资产负债表投影，"时间到钱包"SLA。
游戏活动：计算锦标赛领导者（滑动窗口）,现场游戏回合,CRM/营销的实时提要。
个性化：在线fichi （RFM, propensity） →触发活动,推送/电子邮件秒钟。
操作分析：p95/p99 latency,漏斗步骤转换,平台健康信号。

体系结构模型

Lambda vs Kappa

Lambda： batch （DWH/ETL）+streaming（操作）.另外-灵活性和"便宜"的后盾；减去双逻辑。
Kappa：一切-就像来自杂志（Kafka）的线程。加上一个代码，一个事件重播；减去对基础架构的严格要求。

练习：对于关键的实时轮廓-Kappa；报告/ML培训-附加的击球回路。

事件输送机（参考）

1.制造商：投注/支付服务发布域事件（outbox → Kafka）。
2.总线：kafka按键分期（"player_id"，"bet_id"）。
3.CDC：Debezium将从OLTP（平衡、限制）的变化拉到流中。
4.流处理：Flink/ksqlDB/Spark-聚合、窗口、CEP、join's。
5.投影：实例化表（Kafka Streams state store/ksqlDB tables/Redis），OLAP（ClickHouse/Druid）。
6.消费者：防冻剂、CRM、通知、行车记录仪、触发漏洞。

数据和图表

Avro/Protobuf+Schema Registry：严格的合同，可逆迁移。
转化："域。event.v{n}`;禁止断断续续的变化。
PII：令牌/加密，掩码，目标限制（GDPR）。

交付语义和幂等性

Onc-least-once是事实上的标准（可能是重复的）→必须进行偶数处理。
仅在流媒体中出现：Flink/Streams中的Kafka+EOS交易生成器；更贵,应用点数（金钱/资产负债表）。
Outbox+CDC：来自服务DB的单一真相来源，双重录制保护。
Dedup： key（"idempotency_key"）,TTL重复数据消除表,upsert/merge。

时间窗口和"延迟"数据

窗口是：

Tumbling-固定插槽（例如，周转分钟）。
Hopping-带步长滑动（例如，带步长1分钟的窗口5分钟）。
会议-非活动（玩家会议）。
Watermarks：事件时间处理，"poznyaks"（lateness）公差，DLQ/side-output疏散。
CEP（复杂事件处理）：模式"A然后在3分钟内"，"M秒内的事件"，"取消/补偿"。

状态和缩放

Stateful运算符：聚合/joins保持状态（RocksDB state backend）。
Changelog topics：可靠性和状态恢复。
Backpressure：自动速度调整，系统sink/外限制。

密钥分配： 热键（重击）→键盐,skew mitigation.

监控和SLO

流量SLO： p99端到端延误（例如，≤ 2 c），有效的消费者lag，可用性≥ 99。9%.

度量标准：分批计算,分批计算,watermark delay, drop/late ratio, backpressure,忙碌时间操作员,GC/JVM。
Alerts： DLQ的增长、积压的水上市场、EOS checkpoint的失败、线上/线下的rassinh fichs。
Tracing：通过Prodewser Stream Consumer的韩元ID （'trace_id'、'message_id'）。

安全性和合规性

TLS/MTLS，ACL/RBAC到拓扑/表，敏感域细分（付款/CUS）。
过境/磁盘上的PII加密；Vault/SOPS中的秘密。
数据Retention&locality：按地区（欧盟、土耳其、LatAm）存储,删除策略。
审计：谁发表/阅读，脚本的可重复性。

高可用性和DR

Kafka: `replication.factor ≥ 3`, `min.insync.replicas"，"acks=all"，DR的跨区域复制（MM2）。

Flink/Streams： 用于受控发行版的周期性checkpoint+savepoint；HA-JobManager.

OLAP：段复制,read replicas；failover测试（游戏日）。

性能和调音

Prodewsers：战斗（'linger。ms`, `batch.size'）、压缩器（lz4/zstd）。
消费者：正确的'max。poll.interval'，在后门下暂停派对。
参与：来自目标TPS和并发性的政党帐户。

State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.

网络：10/25G、TCP调谐、n+1 sink请求的威慑。

实施： 关键技术

轮胎：Apache Kafka（替代品：Pulsar，Redpanda）。
流媒体处理：Apache Flink，Kafka Streams，ksqlDB，Spark Structured Streaming。
CDC：Debezium（MySQL/Postgres），Outbox连接器。
投影存储库：ksqlDB tables, Kafka Streams state store, Redis for low潜伏期,ClickHouse/Druid/Pinot for OLAP。
Fichestor： Feast或自己的-在线（Redis）+离线（Parquet/BigQuery）,一致性保证。

设计模式

Outbox → Kafka：DB事务中的每个域事件。
传奇：通过事件进行补偿；编排是串。
Fan-out：一个事件→反氟化物，CRM，分析，符号化。
Materialized Views：领导板、平衡、限制-以表格形式从流中更新。
Reprocessing：复制拓扑以重新计算单元/复古分析。

示例（概念）

ksqlDB： 锦标赛领导者（滚动窗口）

sql
CREATE STREAM bets_src (
bet_id VARCHAR KEY,
player_id VARCHAR,
amount DOUBLE,
ts BIGINT
) WITH (KAFKA_TOPIC='bets. placed. v1', VALUE_FORMAT='AVRO', TIMESTAMP='ts');

CREATE TABLE leaderboard AS
SELECT player_id,
SUM(amount) AS total_stake,
WINDOWSTART AS win_start,
WINDOWEND  AS win_end
FROM bets_src
WINDOW HOPPING (SIZE 10 MINUTES, ADVANCE BY 1 MINUTE)
GROUP BY player_id
EMIT CHANGES;

Flink（伪代码）： 反亲缘计分c late-events

java stream
.assignTimestampsAndWatermarks(WatermarkStrategy. forBoundedOutOfOrderness(Duration. ofSeconds(10)))
.keyBy(e -> e. playerId)
.window(SlidingEventTimeWindows. of(Time. minutes(5), Time. minutes(1)))
.aggregate(scoreFunction, processWindow)
.sideOutputLateData(lateTag)
.addSink(riskTopic);

线程质量测试

方案和演化的合同测试（方案注册）。
负载：目标TPS，p99，sink降解行为。
Failure/chaos：经纪人/节点下降,网络延迟,分裂脑。
Deterministic replays：重新运行拓扑→相同的结果。
金丝雀流：延迟和完整性检查轮廓。

实施支票

1.定义SLO （p99 E2E ≤ X c, lag ≤ Y,可用性≥ Z）。
2.标准化电路和密钥（player_id/bet_id)。
3.选择体系结构（关键轮廓的Kappa）。
4.配置outbox+CDC并隔离PII。
5.设置窗口、水库、后期策略和DLQ/side outputs。
6.在货币路径上启用EOS/等效性。
7.在lag、watermark、DLQ上引入监控和Alerta。
8.提供HA/DR和reprocessing法规。
9.部署Feature Store和在线/离线同步。
10.进行游戏日：练习故障和恢复。

反模式

在没有知情策略的情况下混合事件时间和处理时间。
缺乏计划管理→"打破"版本。
忽略后期数据和热键。
缺少replay策略和斧头转换。
不带附加费率和EOS的投注/付款。

结果

实时流媒体不是"另一种运输"，而是思维方式：域事件，明确的SLO，数据合同，窗口和状态，安全性和可观察性。对于iGaming，可持续套装是Kafka+Flink/ksqlDB+Debezium+Materialized Views+Feature Store。它提供了毫秒的响应，在线/离线分析的一致性以及负载增加的受控复杂性。