1. 综合盘业务数据模型全景图
综合盘数据库需要同时承载用户账户、赛事基础数据、实时竞猜系数、订单流水、结算记录以及风控日志等多种异构数据。传统单一关系型库在写入峰值与复杂查询并存时容易出现锁竞争和索引膨胀。我们将数据模型拆分为基础资料域、交易流水域、实时行情域和风控审计域，不同域采用不同存储引擎与拆分策略。
- 基础资料域：用户、商户、赛事、队伍、玩法配置，强一致要求，保留在 MySQL。
- 交易流水域：注单、结算单、资金变动，写多读少，按用户ID哈希分片。
- 实时行情域：竞猜系数、玩法选项、实时赛果预测指数，高并发读、低延迟更新，使用 MongoDB 文档模型 + Redis 热数据缓存。
- 风控审计域：登录日志、操作审计、规则命中记录，只追加不修改，按月归档。
这种分域方式让综合盘数据库的容量规划和索引设计可以独立演进，避免“一张大表打天下”带来的性能抖动。
2. MySQL与MongoDB混合存储策略
综合盘数据库中，关系型数据适合 MySQL，例如订单与用户之间的外键关联、事务性扣款。但竞猜系数快照、赛事事件、玩法模板等半结构化数据更适合 MongoDB，因为字段会频繁增加，且查询模式以文档为单位。
| 数据类型 | 存储引擎 | 典型读写比例 | 一致性要求 |
|---|---|---|---|
| 用户账户余额 | MySQL InnoDB | 1:1 | 强一致 |
| 订单流水 | MySQL 分片 | 20:1 写多 | 最终一致 + 对账 |
| 实时竞猜系数 | MongoDB + Redis | 1:50 读多 | 允许秒级延迟 |
| 实时赛果预测事件 | MongoDB 文档 | 1:100 读多 | 允许异步刷新 |
| 风控审计日志 | MySQL 归档表 | 只写少读 | 只追加 |
MongoDB 的 Change Stream 用于将竞猜系数变更实时推送到搜索引擎和缓存，MySQL 的 binlog 则负责驱动下游对账与数据仓库同步。
3. 水平分库分表与垂直拆分方案
综合盘数据库的订单表是最先出现瓶颈的对象。我们采用用户ID哈希取模作为分片键，例如 db_index = user_id % 64，每个库承载固定数量的分片表。这样同一用户的订单查询可以精确路由到单库单表，避免跨库 JOIN。
- 垂直拆分：账户库、订单库、赛事库、结算库、风控库分开部署。
- 水平拆分：订单表按 64 库 × 32 表拆分，单表控制在 2000 万行以内。
- 全局唯一ID：雪花算法 + 业务前缀，避免分片后主键冲突。
- 跨分片查询：通过 ES 冗余索引承接后台多条件检索，实时交易路径不依赖跨分片聚合。
分片规则写入配置中心，便于扩容时做一致性哈希迁移。扩容采用双写 + 灰度读方式，避免停机。
4. 实时数据同步与读写分离
综合盘数据库的写库压力集中在注单创建和竞猜系数更新。我们通过 MySQL Group Replication 或 半同步复制 搭建一主多从，从库只承接报表、后台查询和历史订单导出。实时竞猜系数则通过 Canal 订阅 binlog，写入 Kafka，再由消费者更新 MongoDB、Redis 和 ES。
读写分离的关键在于路由策略：事务内读主库，非事务读从库；从库延迟超过阈值时自动降级读主库。对于余额展示这类强一致场景，读主库并配合 Redis 缓存 300ms 防穿透。
MongoDB 侧使用 Read Preference=secondaryPreferred 分散读压力，写操作用 majority write concern 保证多数派落盘。
需要综合盘数据库架构设计方案？联系我们获取免费咨询。
5. 数据归档与冷热分离策略
综合盘数据库中的历史订单和审计日志占用了大量磁盘与备份窗口。我们按时间维度做冷热分离：近 3 个月为热数据，保留在 MySQL 分片集群；3 个月至 2 年为温数据，迁移到归档库或对象存储；超过 2 年的冷数据压缩后离线保存。
- 每日低峰期通过 pt-archiver 或自研归档任务按批次迁移。
- 热表保留索引，归档表仅保留主键和查询列，减少空间。
- MongoDB 使用 TTL 索引 自动清理过期竞猜系数快照，保留最近 7 天热数据在内存映射区。
冷热分离后，在线库体积下降 60% 以上，备份时间从 4 小时缩短到 40 分钟。
6. 备份恢复与灾难恢复演练
综合盘数据库的容灾目标是 RPO ≤ 5 分钟，RTO ≤ 30 分钟。我们采用 全量备份 + binlog 增量 的方式，每日凌晨全量备份到对象存储，每 5 分钟同步 binlog 到灾备中心。MongoDB 使用 mongodump + oplog 增量。
每季度进行一次真实切换演练，模拟主库宕机、机房断网、误删数据三种场景。演练过程中验证备份可恢复性、从库提升主库的耗时、客户端重连机制以及监控告警是否及时触发。
- 主库故障：MHA 或 Orchestrator 自动切换，应用通过 VIP 无感连接。
- 机房级故障：DNS 切换至灾备中心，Kafka 消费位点回拨重新同步。
- 误删数据：从备份中提取指定时间点，恢复到临时实例后导入。
只有把恢复流程跑成常态，综合盘数据库才能在突发流量和硬件故障中保持稳定。若您正在规划竞技娱乐平台的数据层，可参考定制开发服务中的数据库架构专项，或直接联系我们做技术评审。