数据库共享和复制

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

简短的摘要

对于iGaming平台，流量增长（投注，存款，PSP网络手册，游戏事件）和可用性要求（≈99。9–99.99％）迅速达到一个DB的极限。复制提供了水平读取扩展和容错性；sharding-水平缩放记录和数据。关键是知情的PACELC折衷方案（拒绝后：CA/P，否则为Latency vs Consistency），明确的SLO和方案/键纪律。

术语和模型

复制-在节点之间复制数据。

Leader-Follower （Primary-Replica）：一个条目→很多读数。
Multi-Leader （Active-Active）：跨多个区域的条目,冲突/冲突。
Consensus-replication （Raft/Paxos, NewSQL）：定量记录（Cassandra/Scylla-AP定量,CockroachDB/Yugabyte-CP-定量）。
同步/半同步/Async：延迟平衡vs RPO。
Sharding是通过sharding水平分隔表/密钥。

散装散装（均匀性，比范围更复杂）。
范围抢购（密钥范围，热端风险）。
自我修饰（软添加/缩小nod）。
Geo sharding（按地区/辖区）。
功能抢购（按域：付款/费率/CRM）。

在iGaming中选择的时间和内容

仅复制（不加注）-当主要问题在阅读时：事件磁带、报告、公共目录。条目放在一个领导者中，读数放在副本中。
Sharding-当写入/存储瓶颈时：投注流、资产负债表交易、触发事件。

Multi-region:

玩家/PSP的潜伏期→副本的本地阅读。
调节性（数据本地化）→地理分隔。
区域间DR →异步副本+切换计划。

PACELC和保修属性

CAP：在分裂网络中,我们选择C（一致性）或A（可用性）。
PACELC：在没有故障的情况下,我们在Latency （L）和Consistency （C）之间进行选择。
现金路径（资产负债表，注销）：通常以C为导向（CP/strict serializable或Serializable+Business Idementity）。
较不关键的子系统（点击日志、目录）：以L为中心（AP/EC，eventual）。

复制： 实践

Leader–Follower

写入→领导、读取→复制副本（读取标注）。
Read-after-write：对于自定义操作，请阅读领导者或等待掉期（检查'last_committed_lsn'/'wait_for_replay_lag'）。
半同步在关键路径上（以潜伏期为代价降低RPO）。
Failover：自动（patroni/raft协调员）+fencing（因此没有双重领导者）。

Multi-Leader

适合分域和低冲突（例如，内容/设置），但不适用于没有特殊措施的单个玩家帐户。
Merja策略：最后写胜、CRDT、域整合规则。

Consensus/定额 DB

具有法定人数的条目（例如"WRITE QUORUM"），具有法定人数的阅读（"READ QUORUM"）→强/可自定义的一致性。
考虑跨亚利桑那州/地区的潜在性和法定成本。

Sharding： 策略和关键选择

如何选择钥匙

player_id/ account_id/ bet_id的稳定分布。
避免在range sharding-"热"尾巴中使用单调键（自动插入）。
对于付款-通常是"player_id"或"account_id"；博客-"event_time"+bucketing；内容为"tenant_id"。

二.战略

冲洗player_id：利率/资产负债表流的平衡。
分析/档案的时间范围。
Geo sharding： EU玩家→ EU shard（符合当地法律）。
混合体：根据管辖范围，区域内的混合体+geo。

与"热"密钥作斗争

Key-salting（在钥匙上添加盐/bucket）。
按实体写作，命令队列（序列执行器）。
在具有序列队列的单独栈中实现"聚合"（平衡）。

Cross Shard手术

汇款/补偿：避免在热道上2PC。
传奇模式：分解为本地交易+补偿活动，强硬的幂等性和outbox。
2RS/Commit协议：允许点数（后台蹦床），但价格昂贵的潜伏期和容错性。
投影：从流中更新跨域屏幕的读者视图（读取模型）。

方桉、索引和演变

电路转换：从后端进行迁移,在代码上进行特征值。
按硬盘密钥和频繁查询索引；避免越位加盟（做预加盟/非正规化）。
对于JSON/坞站存储-验证电路（JSON-Schema/Protobuf）和TTL用于"嘈杂"的集合。

在线缩放和重新设计

计划N≫tekushcheye数量的虚拟缝隙（slots） →灵活的重新平衡。
为软添加节点而进行一致性洗牌或"虚拟脚注"。

在线转发：

双重记录（旧的+新的shard），一致性验证；
chanks的背景副本（logical dump/table move/streaming clone）；
在"标记"+监视窗口中切换，然后删除双重记录。
无需停机即可移动领导者：切换角色,排水连接器。

SLO，可观察性和异位

SLO写入/读取：热表上的p99 ≤ X毫秒，有效的lag副本≤ Y秒，可用性≥ Z。
度量标准：TPS, p95/p99, repliclag,冲突性（multi-leader）, retry rate, deadlocks, lock wait, cache hit ratio, IOPS/latency驱动器。
跟踪："trace_id"在DB请求中,链接到事件代理/总线。
早期降解检测的金丝雀查询和合成交易。

安全性和合规性

静止和过境（TLS）加密，密钥旋转。
RBAC/ACL，跨域/tenant的细分，用于支付/KUS的单独群集。
数据本地化（EU/TR/LATAM）-结合地理缓存和重生策略。
审计：谁和什么读取/规则；伪装PII；导出审核。

Bacaps, PITR, DR

完整+增量备份，离网存储。
用于领导群集的PITR（点对点恢复）。

RPO/RTO:

关键域（余额/付款）-RPO≈0 -30秒（半同步或频繁的WAL-shipping）, RTO ≤分钟,带有自动故障切换。
不那么关键-RPO最长为分钟/小时。
DR演习（游戏日）和记录的切换运行手册。

表演和调整（简短）

内存/缓存：放大缓冲区（共享缓冲区/innodb缓冲池）,留意95%的缓存命中≥。
日志/引擎：快速NVMe，WAL/redo下的单独卷。
连接池（PgBouncer/Hikari）。
调度程序/统计信息：自动分析/自动空间（Postgres）, GC编译/调音（LSM引擎）。
法定人数/复制因子：p99与容错之间的平衡。

适用于iGaming的典型拓扑

1）资产负债表和付款（CP回路）

玩家区域中的Leader-Follower，半同步到近距离复制。
通过"account_id"进行重击。
"写后"阅读-来自领导者；Redis中用于API后端的投影。
Outbox →用于计算/分析的事件总线。

2）投注历史/游戏事件（以美联社为中心的日志）

在柱子/LSM存储中按时间排列或按"player_id"排序。
用于报告/OLAP的异步复制副本。
Eventual consistency可以接受，带宽更重要。

3）配置文件/CRM （Multi-Region read, localization）

按司法管辖区划分，用于阅读的本地副本。
通过最近的领导者进行记录；跨区域-异步+冲突解决仅适用于非关键字段。

示例（概念）

Postgres： 在"player_id"上声明性补丁'

sql
CREATE TABLE player_wallet (
player_id BIGINT NOT NULL,
balance_cents BIGINT NOT NULL,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (player_id)
) PARTITION BY HASH (player_id);

CREATE TABLE player_wallet_p0 PARTITION OF player_wallet FOR VALUES WITH (MODULUS 32, REMAINDER 0);
--... p1..p31

-- Репликация: публикация WAL на реплики, синхронность для «горячего» региона.
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (replica_eu1, replica_eu2)';

定量记录（伪记录）


WRITE CL=QUORUM  -- запись подтверждена большинством реплик
READ CL=LOCAL_QUORUM -- локальный кворум для низкой задержки

传奇而不是2PC（简化）

1.在shard-A（idempotent）上注销存货。
2.将事件"删除"→支付服务（shard-B）。
3.如果步骤2没有成功-通过"返回"事件补偿步骤1。

实施支票清单

1.定义数据域和SLO （p99、RPO/RTO、复制副本）。
2.选择复制模型（leader/follower、法定值）和缓存策略。
3.确定分隔键和电路（不可变!）。
4.输入read-after-write策略和读取路由。
5.设计在线转发（虚拟缝隙、双写）。
6.确保事件/命令的幂和输出。
7.设置备份，PITR，DR和定期练习。
8.包括可观察性：差、法定人数、热键、冲突。
9.记录运行手册：failover、split-brain、降级。
10.对比赛高峰进行负载/混沌测试。

反模式

一个巨大的碎片是"全部"，然后是"稀疏"。
在请求的热路径上进行交叉缝合。
缺少read-after-write（浮动错误）策略。
"断开"缓存键的电路迁移。
货币账户的多领导者,没有严格的冲突解决方桉。
没有PITR/DR-无法从逻辑错误中恢复。

三.成果

复制解决了读取和容错问题，解决了写入和体积问题。iGaming中成功的体系结构是清晰的SLO和PACELC折衷方案，稳定的sharding键，最低限度的交叉碎片协调（saga而不是2PC），阅读后写入学科，经过调试的在线转换和常规DR演习。这种方法可以扩展到锦标赛的高峰，经受住了数据本地化的监管限制，并且仍然可以预测。