活動流和實時數據

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

簡短摘要

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。它提供了毫秒的響應，在線/離線分析的一致性以及負載增加的受控復雜性。