如何在iGaming中安排故障切換和備份

為什麼iGaming是一門特殊的DR/BCP學科

賭場平臺是實時現金（錢包/ledger），現場回合（RNG/Live），付款，隸屬關系和嚴格的合規性。可用性中的任何「漏洞」都會迅速轉化為財務和法律風險。因此，該體系結構圍繞可預測的恢復而構建：已知目標，已知場景，排練過程。

---

基本目標和術語

RTO（恢復時間目標）：服務恢復時間。

錢包/ledger：≤ 60-300秒（區域內捕獲器），≤ 15分鐘（區域間捕獲器）。

RPO（恢復點目標）：有效的數據丟失。

對於leder： 0-5秒（同步/準同步復制）,用於報告：≤ 15分鐘。

SLA和Error Budget：正式化變化速度和穩定性之間的權衡。

---

容錯層

1）基礎架構： Multi-AZ/Multi-Region

Multi-AZ（最少3個區域）：所有關鍵服務分布在各個區域,自動變頻器DB/總線。

多區域DR：「熱」（Active-Active）或「溫暖」（Active-Passive）第二個具有司法管轄區隔離的區域（數據駐留）。

決定何時使用哪種模式：

• Active-Active：對兩個地區的玩家的低潛伏率,通過事件同步交叉區域ledger+計算的嚴格單位真理「位置」。
• Active-Passive （warm）：更簡單、更便宜；passific擁有溫暖的實例+DB復制件，但流量不服務。

2）網絡和外圍

配音的ingress/WAF，Anycast或DNS收件箱帶有健康檢查。

收銀機和提供商的單獨的egress網關，兩個地區允許的IP列表。

3）數據和隊列

關系數據庫（Postgres）：Patroni/托管 HA，AZ中的同步副本，DR區域中的異步副本（帶有滯後監測）。PITR每隔N分鐘+WAL存檔一次。

OLAP（ClickHouse/BigQuery）：復制/硬化；上面允許的損失（RPO高達15-30分鐘）。

緩存（Redis）：具有失敗者的集群，但不包含真相來源；切換時-溫暖加熱。

事件總線（Kafka/NATS）：鏡像群集和/或跨群集鏡像、「at-least-once」保修、消費者異位控制。

4）應用程序和域

錢包/ledger：具有嚴格一致性的靜態內核，每個區域一個「主騎手」；在區域間DR中，是具有雙寫鎖定的「特寫」過程。

遊戲橋/API：無狀態，水平健康支票收件人；idempotencyKey適用於所有財務途徑。

獎金/通知/ETL：允許延遲處理，從隊列中重新啟動。

售票處（PSP/地下室）：多用戶策略（每個國家/地區最少2條軌道），快速切換商號/尾點。

5）現場直播

WebRTC/LL-HLS具有區域邊緣節點的網關；當WebRTC降解時，在LL-HLS上的後退路由。

將投註邏輯保持在播放器之外，以使流重新啟動不會影響計算。

---

Failover模式

資產資產（雙區域）

優點：最低RTO/RPO，接近玩家。

缺點：ledger的復雜性和記錄沖突，昂貴的網格。

練習：「每個域的一位作者」+事件源來復制鄰近地區的狀態。

資產放氣（溫暖）

優點：價格/復雜性平衡。

缺點：RTO更高，需要一個工作計劃「推廣」被動地區。

實踐：自動化+手動確認（4眼原理）,同時切換錢包。

區域內（Multi-AZ）

DB/緩存/ingress自動捕獲器。

不更改DNS/Anycast, RTO秒到分鐘。

---

按數據類別進行備份

原則：

• 後備箱在靜止和過境時加密，鑰匙在KMS/HSM中加密。
• 用於關鍵備件（擦除/勒索保護程序）的不可抗拒模式（WORM）。
• 帶有元數據的備用目錄（方案版本，WAL窗口，校驗和）。
• Ledger必須使用PITR。

---

數據和偶然性： 如何避免造紙器中的「漏洞」

IdempotencyKey在'bet請求上。place`, `payout.request`, `cashier.webhook`.

Ledger只是append-only：重新設置將創建校正條目而不是「重寫」。

當切換作家角色時，交易鎖/平衡旋轉可防止比賽。

事件重復數據消除（消費者側,關鍵字段散列）。

---

收銀機、PSP和加密： B計劃始終包括在內

每個支付方法（卡/ARM）至少有兩個提供商，兩個地區的預設商戶帳戶。

對於stablecoins，兩個網絡（例如TRC-20和ERC-20）和兩個on/off-ramp-ISP。

付款路由器：發生故障時,PSP會立即切換到備用,並記錄原因。

KYT/AML流重復；如果外部服務不可用-帶手動升級的「降級模式」。

---

操作程序（Runbooks）

自動化

ingress → API鏈的健康支票→ → DB →提供商的錢包。

退化錢包時自動連接「重型」功能（比賽/任務）。

Taymauts/retrai具有指數暫停和嚴格的截止日期。

手動（帶確認）

DR地區晉升為資產：步驟檢查表，日誌，通用模式（sapport/合作夥伴/監管機構）。

按回合計算的補償/VOID：原因代碼，視頻通用的鏈接，負責人的簽名。

雙重控制付款解凍。

---

演習和準備就緒檢查

Game Day/Chaos Drill每月：AZ關閉、DB降級、提供商下降。

Full DR Rehearsal季度：將DR地區「全面增長」，趕走實際投註/支付方案。

還原測試：在T 時間點恢復ledger，與對照P&L和哈希切片核對。

具有合規性的桌頂：誰和誰通知正在形成哪些報告（監管機構、PSP、附屬機構）。

---

Failover的可觀察性和信號

SLO指標：p95 latency錢包，股票'bet。rejected',settle round time, SLA付款,DB復制時差,Kafka消費者時差。

切換事件：「role change」、「repliclag> X」、「object-lock violation」等變量。

Dashbords DR：當前節點角色，RPO得分（WAL分鐘），PITR窗口狀態。

---

安全和合規性

司法管轄區數據隔離（EU/UK/CA/……）：法律允許的復制。

日誌不可變（S3 Object Lock/WORM），按監管期限進行重構。

秘密：關鍵輪換，DR操作的職責分工（雙控制）。

所有切換和恢復的審核跟蹤。

---

打破DR的反模式

每個國家/地區一個PSP/單個 stablecoin網絡-沒有備用導軌。

一個數據庫上的OLTP和OLAP-恢復阻止「實時」操作。

沒有idempotencyKey-回避借記/付款。

沒有定期還原測試的備用是「schrödinger備用」。

缺少WORM/immutability-內幕/惡意刪除漏洞。

沒有TTL短和變暖的DNS收割機。

同時在兩個地區的一位ledger作家是病情分裂。

---

事故準備清單

體系結構

• Multi-AZ適用於所有關鍵服務,記錄的拓撲。
• 具有描述角色（Active-Active/Passive）和預算的DR區域。

數據

• Postgres： PITR、snapshots、lag監測、定期恢復測試。
• Kafka/NATS：鏡像/存檔，繼電器計劃。
• ClickHouse/OLAP：派對備份,樣本恢復。
• S3： Object Lock （WORM）,版本,跨區域。

應用程序

• Idempotency在金錢,append-only ledger,轉換資產負債表.
• 事件（比賽/任務）中的自動功能等級。
• 在區域切換之前進行金絲雀檢查。

售票處和地下室

• 每種方法有兩個提供商，每種方法有兩個用於站點的網絡。
• 路由和切換原因日誌。
• KYT/AML在升級的階梯模式下。

業務活動

• Runbooks帶有RACI和值班電話。
• 每月混沌日和季度Full-DR演習。
• 通信模式（sapport、合作夥伴、監管機構）。

可觀察性

• Dashbords RTO/RPO，DB角色，滯後，投註/付款失敗的差異。
• 對切換和恢復進行審核。

---

iGaming的可靠性不是「騙子按鈕」，而是習慣系統：地理隔離，可預測的RTO/RPO，偶數貨幣，多軌現金，不可思議的備用，定期演習和透明溝通。這樣的紀律使失敗得以幸存下來，而不會在Ledger中造成損失，沒有「倒退」的回合，也沒有受到球員和監管機構的信任。