一、容量估算与分片数量计算14亿人口不等于14亿交易用户。按行业经验实际交易用户约为注册用户的50%70%即约710亿活跃交易用户。以下按保守场景估算数据量测算假设日活3亿日均交易1亿笔年产生约365亿条交易流水保留3年热数据累计约1000亿条交易流水记录MySQL单表工程经验值5000万行以内通常可控行数过亿后B树层级加深、查询和DDL都会明显变慢分片数量计算按单表5000万行计算1000亿 ÷ 5000万 2000张表考虑到分片倾斜率15%时需要预警取2的幂次方向上取整推荐方案32库 × 64表 2048张物理表单表约4880万行处于可控区间。二、分库分表策略2.1 分片键选择user_id 而非 order_id这是交易系统分片设计的核心决策。交易流水严禁按时间分片按时间分片会导致用户流水散落在不同月份表中用户查询需要跨表扫描性能极差。最优分片键为user_id同一用户所有流水全部落在同库同表用户查询精准单表路由无跨库、无广播查询写入均匀、无热点、无数据倾斜金融账户场景需严格保证同一用户的账户余额在同一分片路由算法db_index user_id % 32 → 定位到32个分库之一 table_index user_id % 64 → 定位到库内64张分表之一举例若 user_id 1001则 db_index 9table_index 41数据落入pay_core_009库的t_order_041表。2.2 各业务表的分片方案业务表分片键分片方案说明交易流水表t_orderuser_id32库×64表按用户路由查“我的订单”精准命中单表账户余额表t_accountuser_id32库×64表与交易流水同分片保证同用户账户和流水在同一库账户流水表t_account_loguser_id32库×64表同上支持余额变动追溯支付流水表t_pay_loguser_id32库×64表支付查询以用户维度为主对账明细表t_recon按“日期商户ID”按月分表哈希分库对账以商户和日期为维度独立分片策略2.3 分片算法选型方案优点缺点适用场景取模分片算法简单、分布均匀、路由高效扩容时全量数据迁移初期固定分片数一致性哈希扩容仅迁移少量数据、支持平滑扩容算法复杂需虚拟节点防倾斜长期存量数据首选推荐初期采用取模分片32×64固定后续若需扩容可引入一致性哈希平滑迁移。三、数据库命名与表设计规范3.1 分库命名格式业务系统名_子系统名_编号编号从0开始递增不足位补零。库名必须控制在32个字符以内字符集必须显式指定utf8mb4。示例pay_core_000 ~ pay_core_031 交易核心库32个3.2 分表命名格式模块前缀_逻辑表名_编号编号统一补零表名只使用小写字母、数字和下划线。示例pay_core_000.t_order_000 ~ t_order_063 pay_core_000.t_account_000 ~ t_account_0633.3 强制表设计红线主键必须为id BIGINT UNSIGNED NOT NULL使用分布式ID非自增避免随机插入导致InnoDB页分裂必备字段id、create_time、update_time、is_del软删标记、version乐观锁金额字段必须使用DECIMAL(18,4)严禁使用FLOAT/DOUBLE禁止项禁止外键约束、禁止跨库JOIN、禁止使用MySQL分区表存储引擎统一使用InnoDB支持事务、行锁、宕机恢复四、流水号设计流水号必须满足全局唯一、趋势递增利于B树索引写入、业务安全三大要求。4.1 方案对比方案核心原理优点缺点雪花算法64位时间戳41位机器ID10位序列号12位纯内存生成单实例理论峰值409.6万QPS强依赖系统时钟时钟回拨导致ID重复号段模式数据库预分配ID区间本地内存消费性能极高无时钟依赖高可用强依赖数据库ID连续易被遍历服务重启造成号段浪费4.2 推荐融合方案采用号段模式Leaf-Segment作为基础发号器数据库创建号段管理表按业务标签隔离订单号、支付号、账户流水号分别独立号段每次申请一个号段区间如step10000在内存中自增分配双Buffer机制当前号段消耗到10%时异步预加载下一个号段避免申请时的性能抖动号段管理表设计CREATETABLEid_segment(biz_tagVARCHAR(64)NOTNULLCOMMENT业务标签,max_idBIGINTNOTNULLCOMMENT当前最大ID,stepINTNOTNULLCOMMENT号段步长,update_timeDATETIMENOTNULL,PRIMARYKEY(biz_tag))ENGINEInnoDB;4.3 安全性增强纯递增ID会暴露业务量级必须对流水号进行混淆处理在号段ID基础上插入2~4位随机因子或使用可逆加密算法如AES对原始ID加密后返回前端禁止将原始自增ID直接暴露给前端防止竞对扒取单量五、高可用架构5.1 容灾架构两地三中心金融级交易系统要求RPO0、RTO30秒的容灾能力。推荐架构层级部署方式数据同步容灾目标同城主中心双可用区部署主库同步从库同步复制RPO0单机房故障RTO30s同城灾备中心与主中心构成同城双活同步复制RPO0机房级灾难秒级切换异地灾备中心异地异步复制异步复制RPO≤10s城市级灾难分钟级恢复核心保障机制RPO0通过同步复制实现主库事务提交时等待Redo日志成功写入备库后才返回成功RTO30秒基于Raft自选举协议实现自动化故障切换避免人工切换的分钟级延迟脑裂预防通过仲裁机制确保网络分区时集群仍可用5.2 读写分离与分片路由组件选型职责分片中间件ShardingSphere-JDBC客户端分片SQL路由改写无代理层网络开销读写分离一主多从1主4只读写操作路由到主库查询路由到从库分布式事务Seata AT模式跨库事务一致性保障5.3 冷热数据分离根据访问频率分层存储避免历史数据拖垮在线交易数据温度时间范围存储方案访问延迟热数据近3个月MySQL分库分表集群≤50ms温数据3~12个月Elasticsearch≤500ms冷数据1年以上HBase / 对象存储分钟级批量查询数据流转通过Canal监听MySQL Binlog异步推送到ES和HBase实现无侵入的冷热分离。5.4 服务熔断与降级交易链路订单、支付、账户与非核心链路推荐、搜索、统计必须解耦。当数据库压力过大时优先保障交易写入降级查询服务。核心链路设置独立的线程池和连接池避免被非核心业务拖垮。六、整体架构总结┌─────────────────────────────────────────────────────────────┐ │ 接入层API Gateway │ ├─────────────────────────────────────────────────────────────┤ │ 交易服务 │ 账户服务 │ 支付服务 │ 对账服务 │ ├─────────────────────────────────────────────────────────────┤ │ ShardingSphere-JDBC分片路由 读写分离 │ ├─────────────────────────────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │pay_core_0│ │pay_core_1│ ... │pay_core_31│ ← 32个分库 │ │ │ 64张分表 │ │ 64张分表 │ │ 64张分表 │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ ┌────▼──────────────▼─────────────────────▼─────┐ │ │ │ 一主四从 同城双活 异地灾备 │ │ │ │ RPO0, RTO30s │ │ │ └───────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────┤ │ Canal → ES温数据 / HBase冷数据 / Kafka异步消息 │ ├─────────────────────────────────────────────────────────────┤ │ 号段发号器Leaf-Segment │ 分布式事务Seata │ 监控告警 │ └─────────────────────────────────────────────────────────────┘关键设计要点回顾分片策略32库×64表以user_id为分片键保证同用户数据单表路由命名规范pay_core_000~pay_core_031表名t_order_000~t_order_063流水号号段模式发号双Buffer预加载前端展示时加密混淆高可用两地三中心 同城双活RPO0RTO30s冷热分离MySQL热→ ES温→ HBase冷Canal实现自动流转