📖 前言：Web3 业务的双重账本
在 Web3 业务中，区块链（AMB）是不可篡改的"链上真理"，而关系型数据库（RDS/Aurora）则是承载用户资产、撮合逻辑和KYC信息的"链下业务核心"。对于追求全球化的高频交易项目，数据库的架构设计必须解决两个核心矛盾：跨国访问的物理延迟 与 资金数据的一致性。
第一部分：旗舰方案 ------ Amazon Aurora Global Database (深度解析)
这是针对跨国交易所（如币安、Coinbase 模式）的首选架构。
1. 核心架构原理：物理层复制 (Physical Replication)
很多架构师误以为 Global Database 是逻辑上的"双写"或"同步"。实际上，它的底层机制是：
-
存储与计算分离：数据库实例（计算）只负责处理 SQL，数据同步完全由底层的**存储节点（Storage Nodes）**完成。
-
物理块同步：主区域（如新加坡）的存储层将数据变更的物理块（Physical Blocks），通过 AWS 骨干网直接发送给从区域（如伦敦）的存储层。
-
优势 ：不经过数据库引擎，不消耗 CPU，跨海同步延迟通常 < 1秒。
2. 部署拓扑与连接逻辑 (核心误区纠正)
误区：认为全球只有一个统一的 URL，AWS 自动路由。
真相：每个区域都有独立的 Endpoint，必须在部署层面进行区分。
-
主区域 (Primary Region - 新加坡)
-
角色 ：唯一的读写中心 (R/W)。
-
包含：1 个 Writer 实例 + N 个 Reader 实例。
-
-
从区域 (Secondary Region - 伦敦)
-
角色 ：默认的只读中心 (RO)。
-
包含：N 个 Reader 实例（本地有完整的计算资源，而非仅仅是一个接口）。
-
3. 开发配置策略：代码一致，配置分离
由于没有"全球统一 URL"，为了让同一套 Java 代码在不同 Region 运行，必须采用环境变量注入的方式：
-
新加坡 EKS 集群配置 (ConfigMap)：
-
DB_READ_URL=sg-reader-endpoint.rds.amazonaws.com(读本地) -
DB_WRITE_URL=sg-writer-endpoint.rds.amazonaws.com(写本地)
-
-
伦敦 EKS 集群配置 (ConfigMap)：
-
DB_READ_URL=ld-reader-endpoint.rds.amazonaws.com(读本地，极速 1ms) -
DB_WRITE_URL=sg-writer-endpoint.rds.amazonaws.com(跨海写主库，延迟 300ms)
-
4. 进阶选项：写转发 (Write Forwarding)
如果你不想在伦敦的代码里配置新加坡的 URL，可以开启此功能。
-
原理 ：伦敦 Pod 连接伦敦本地库发起
UPDATE，数据库底层自动将请求转发回新加坡执行。 -
代价 ：延迟依然存在 (300ms)。
-
建议：仅适用于"修改头像"、"设置昵称"等低频操作。核心撮合业务建议在架构层直接路由回主区域。
第二部分：运维与灾难恢复 (DR) 指南
1. 故障场景 A：单机房故障 (AZ Failure)
-
场景：新加坡的主机房（AZ1）断电。
-
处理 ：全自动。Aurora 会在同区域的备用机房（AZ2）瞬间重启实例。业务仅抖动几秒，无需人工介入。
2. 故障场景 B：区域级灾难 (Region Failure)
-
场景：新加坡整个区域失联（海缆切断、特大灾害）。此时全球都无法写入数据。
-
处理 ：人工/脚本介入 (Manual Failover)。
-
剥离 (Detach)：运维在控制台将伦敦集群从 Global 中移除。
-
提升 (Promote)：将伦敦集群提升为新的独立主库（获得写权限）。
-
切流 (Switch)：更新 DNS 或应用配置，将写请求指向伦敦新主库。
-
-
数据丢失风险 (RPO) ：由于物理复制延迟极低，通常丢失的数据 < 1 秒。
3. 必开的"运维保命锁"
-
Deletion Protection (删除保护)：必须开启。防止误删导致全球数据同步消失。
-
Session Consistency (会话一致性)：在代码层开启。防止用户在伦敦刚转账（写），马上刷新页面（读）时发现钱没扣掉的恐慌。
-
Performance Insights：开启监控，用于分析高频扫链导致的 SQL 阻塞。
第三部分：标准方案 ------ Amazon RDS (Standard)
如果业务仅集中在单一地区，无需全球部署，则采用此高性价比方案。
1. 架构重点：极致的单点稳固
-
Multi-AZ (多可用区) ：【强制开启】。这是 RDS 的"免死金牌"。没有它，硬件故障等于服务中断。
-
存储选型 (gp3)：
-
选择 gp3 类型。
-
根据区块链交易量，独立调高 IOPS (如 6000+) 和吞吐量，避免因磁盘 I/O 瓶颈导致扫链程序积压。
-
2. 数据安全
-
PITR (按时间点恢复) ：保留期设为 35 天。
-
场景 ：当代码 Bug 导致账本逻辑错误时，可将数据库回滚到事故前 1 秒，是资金安全的最后一道防线。
📝 总结与选型建议
| 需求维度 | 推荐方案 | 核心特征 | 运维代价 |
|---|---|---|---|
| 全球化交易所 | Aurora Global Database | 本地读 (1ms)、跨区写 (300ms)、RPO < 1s | 高 (需维护多套 Region 配置) |
| 区域性 DApp | RDS Standard (Multi-AZ) | 单区域高可用、性价比高、管理简单 | 低 (仅需关注单点健康) |
特别提示：
无论选择哪种方案，数据库只能保证**"最终一致性"**（尤其在跨区场景下）。为了处理高并发下的"资金双花"风险和瞬时锁单需求，架构中必须引入 Redis (ElastiCache) 作为实时交易锁。