如何在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中造成损失，没有"倒退"的回合，也没有受到球员和监管机构的信任。