數據庫共享和復制

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

簡短的摘要

對於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演習。這種方法可以擴展到錦標賽的高峰，經受住了數據本地化的監管限制，並且仍然可以預測。