如何利用MySQL进行分布式存储

总体思路与方案选型

• 用 分片 Sharding 将数据按规则分布到多台 MySQL 实例，实现横向扩展与容量提升。
• 用 复制 Replication 与 高可用集群 保障数据冗余与故障切换。
• 用 中间件或驱动 做路由、读写分离与负载均衡，降低应用侵入性。
• 典型方案对比：
  • MySQL Cluster（NDB）：官方分布式内存集群，自动分片与多副本，适合超高吞吐与低延迟的 OLTP，但配置复杂、对硬件与网络要求高。
  • InnoDB Cluster / Group Replication（MGR）：基于 Paxos/Raft 的多主/单主强一致集群，易用、自动故障转移，适合 读多写少 与强一致场景，但不替代分片，容量受单机限制。
  • 中间件分片（ShardingSphere、MyCat、Vitess、ProxySQL）：灵活扩展、对应用透明，需维护中间件与路由规则，注意跨分片事务与查询问题。
  • 云服务（PolarDB、TDSQL 等）：免运维、弹性好，成本较高、功能受云厂商限制。

落地步骤

1. 容量评估与分片设计
   • 明确数据量与增长、读写比例、延迟目标、一致性级别与预算。
   • 选择分片维度与键（如 user_id、tenant_id、order_date），避免热点与倾斜。
   • 设计路由与映射：客户端路由、代理层路由或服务端内置分片。
2. 选择拓扑与复制模式
   • 分片内用 主从复制 做读写分离与冗余；强一致用 MGR；极致性能与自动分片考虑 NDB。
   • 复制模式：默认 异步（性能最好、一致性最弱）、半同步（至少 1 个从库确认，折中）、组复制（强一致、复杂度高）。
3. 路由与中间件集成
   • 客户端分片：在访问层嵌入路由逻辑；中间件分片：使用 ShardingSphere-JDBC/Proxy、MyCat、Vitess、ProxySQL 统一路由与读写分离。
4. 全局表与字典表处理
   • 小体量、低频变更的字典/配置表做 全量副本 到各分片，避免跨分片 JOIN。
5. 分布式事务策略
   • 尽量按分片键设计，使事务 单分片化；跨分片强一致可用 XA/2PC，或采用 TCC/最终一致性 的业务补偿方案。
6. 监控、容量与弹性
   • 监控复制延迟、节点健康、连接与慢查询；预留扩容与再分片（resharding）能力。

关键设计要点

• 分片策略
  • 范围分片：按取值区间（如时间、ID 段）划分，利于范围查询，易产生热点。
  • 哈希分片：对分片键取模/哈希，分布均匀，范围查询复杂。
  • 目录/映射分片：维护键到分片的映射表，灵活但增加一次查找。
• 路由方式
  • 客户端分片：实现简单、延迟低，但耦合应用。
  • 代理/中间件分片：对应用透明、集中治理，有额外网络与 CPU 开销。
• 复制与一致性
  • 异步复制：性能优、可能丢数据；半同步（MySQL 5.7 支持 after_commit，8.0+ 支持 after_sync 更安全）；MGR 基于分布式一致性协议，强一致、网络要求高。
• 分布式事务
  • XA/2PC：跨分片强一致，存在阻塞与性能开销；TCC/消息补偿：高并发更友好，需业务侧实现。
• 跨分片查询与唯一 ID
  • 跨分片 JOIN/聚合通常通过 二次查询/广播 或 汇总库 实现；全局唯一 ID 可用 UUID 或 ShardID+LocalID 组合。

最小可行示例

• 目标：将 订单表 orders 按 user_id 哈希取模 4 分片，分片内一主一从，应用通过 ShardingSphere-JDBC 路由与读写分离。
• 步骤
  1. 准备实例：部署 4 组 MySQL（每组 1 主 1 从），开启 GTID，主库配置 server-id 与 binlog。
  2. 初始化复制（示例命令）
     • 主库：CREATE USER ‘repl’@‘%’ IDENTIFIED BY ‘pwd’; GRANT REPLICATION SLAVE ON . TO ‘repl’@‘%’;
     • 从库：CHANGE MASTER TO MASTER_HOST=‘master_ip’, MASTER_USER=‘repl’, MASTER_PASSWORD=‘pwd’, MASTER_AUTO_POSITION=1; START SLAVE;
  3. 应用集成（ShardingSphere-JDBC 片段）
     • Maven 依赖：shardingsphere-jdbc-core-spring-boot-starter、HikariCP、mysql-connector-java
     • 配置要点：定义 4 个数据源 ds0~ds3；分片规则 t_order.actual-data-nodes=ds$->{0…3}.t_order_$->{0…3}；分片算法：user_id % 4；读写分离策略：写主读从。
  4. 全局表：如地区字典表 region 全量复制到 ds0~ds3。
  5. 验证：按 user_id 路由到对应分片；跨分片订单统计通过应用层聚合或汇总库完成。

常见陷阱与优化建议

• 热点与倾斜：避免用时间戳或单调递增键做哈希；必要时引入 虚拟分片/一致性哈希 与再分片机制。
• 跨分片事务：优先设计为 单分片事务；跨分片强一致场景评估 XA/2PC 成本，或采用 TCC/消息最终一致。
• 唯一 ID：避免单纯依赖 AUTO_INCREMENT；使用 UUID 或 ShardID+LocalID。
• 复制延迟与一致性：读从库需容忍延迟；强一致读可路由到主库或使用 MGR 的一致性读。
• 运维复杂度：中间件/集群引入额外组件，需完善 监控、告警、备份与回滚 流程，定期演练故障切换。