1. 项目背景与整体设计思路1.1 为什么需要一款兼容 MySQL 的分布式数据库做数据库运维和开发的朋友应该都有这种感觉MySQL 单实例能扛的极限大约在千万级到亿级数据量、每秒几千到上万次写入的区间。业务一旦往上走单机 CPU、内存、磁盘 IO 都会最先被打满。传统的分库分表中间件虽然能解决一部分扩展问题但业务代码里会侵入大量路由逻辑运维侧还要自己维护中间件的高可用和扩容流程投入的人力成本相当高。TDSQL MySQL 这一类产品的出现本质上就是希望把“扩展能力”和“MySQL 兼容性”同时给到业务方。应用层还按 MySQL 的方式连接、写 SQL、做事务底层数据已经被自动拆分到多个存储节点上。对业务团队来说改造工作量通常集中在建表规范、主键设计和少数跨分片查询的改写而不是整套持久层重写。这也是很多传统行业客户愿意选它的原因原来跑得好好的 MySQL 生态不用推翻重来。1.2 从中间件到分布式数据库的选型逻辑早年不少团队为了解决单机瓶颈会选择自研数据访问层或者在中间层挂一个分库分表组件。这种方案的优势是灵活可以匹配业务的特定路由规则痛点也很明显SQL 语法支持有限、分布式事务要靠业务方自己实现、扩容时路由规则变更非常痛苦往往需要停服迁移数据。TDSQL MySQL 走的是另一条路通过接入层统一收口 SQL 请求底层由多个存储节点组成一个集群数据按分片键自动打散分片副本之间通过主备同步保证数据安全。从使用者的视角看它就是一台“容量几乎无限的 MySQL”路由细节、副本同步、主备切换都被屏蔽掉了。这套架构在生产上最有价值的一点是把复杂问题收拢到基础设施层统一处理而不是把复杂度摊到每个业务团队。业务方只要遵循分片键设计规范就能获得水平扩展能力。对于缺乏专业 DBA 团队的中小型公司这种“把复杂度内置”的选型是很现实的考虑。1.3 核心设计权衡强一致、容灾与运维投入我参与过几个从 MySQL 迁移到分布式库的项目最大的感受是选型阶段一定会纠结两个问题一是分布式事务能不能做到和单机事务一致二是容灾能力到底能覆盖到什么级别。先说事务。TDSQL MySQL 在分布式架构下实现了全局事务能力通过两阶段提交协议保证跨节点写入的一致性。这里要说明的是“两阶段提交”在理论上会有协调者故障时参与者无法立刻达成一致的问题所以实际生产环境还需要配合全局事务记录和超时回查机制尽量把不确定窗口压缩到足够短。作为使用者我通常会把分布式事务的适用场景限定在核心链路例如订单创建、账户扣减这类必须强一致的场景至于搜索记录、日志流水这类允许短暂延迟的场景其实用普通事务加异步补偿就够了。再说容灾。TDSQL MySQL 支持多副本部署可以在同城两机房或者更大范围的多中心模式下运行。在选择副本数量和容灾方案时需要同时考虑机房间带宽、延迟和整体成本。副本数不是越多越好三副本已经是多数生产环境的常见选择一份主副本、两份备副本既能容忍单节点故障也不会让网络交互过于膨胀。2. 核心架构与关键技术解析2.1 接入层连接管理与 SQL 路由TDSQL MySQL 的接入层承担了很关键的工作。客户端连接到接入层后接入层需要解析 SQL从中提取分片键的值然后按路由规则把请求转发到对应的存储节点。对应用来说这一层的主要意义在于“统一入口”应用不需要感知底层有多少个分片也不需要自己维护分片与物理节点的映射关系。接入层通常还需要处理连接数的收敛。如果每个业务实例直接连每个存储节点后台连接数会成倍膨胀通过接入层统一维持与后端节点的连接池可以把大量前端连接复用到底层连接上这对高并发场景非常关键。实际调优中接入层自身也需要留出足够的线程和网络缓冲区资源否则前端流量一打过来接入层反而会成为瓶颈。这里有一个很实际的注意点接入层对 SQL 的解析能力决定了它是否能正确处理复杂查询。像select * from t1 where a1 and b2这种查询如果分片键是a那路由非常明确但如果查询条件里没有分片键接入层就只能把请求广播到所有分片再合并结果。这类“分布式广播查询”不是不能做而是在数据量大的场景下性能一定扛不住后面我会专门讲这个问题的规避方式。2.2 数据分片与副本机制数据分片是分布式数据库的立身之本。TDSQL MySQL 把一张逻辑表按照分片键的哈希值或一定规则切分到多个物理分片中每个分片内部又保留多个副本。正常情况下一个分片的主副本对外提供读写服务备副本异步或半同步地从主副本同步日志。这里要提一个容易被忽略的点分片和物理服务器不是一一对应的。一台物理节点上可以同时运行多个分片的主副本或备副本这取决于部署规划。如果一个物理节点同时承载了多个分片的主副本那这台节点故障时影响面就会变大。所以部署阶段最好尽量把主副本打散到不同物理机上避免单节点故障引发大面积分区不可用。副本一致性是另一个重点。生产环境中我比较倾向于使用强同步或半同步机制确保主备切换时数据丢失窗口足够小。所谓“半同步”可以理解为主库提交事务时至少等待一个备库确认收到日志后再返回成功。这样如果主库突然宕机备库大概率已经拿到了最新日志切换后数据基本不丢。当然半同步也有代价每个事务的提交延迟会有所增加这在跨机房场景下尤其明显所以副本间的网络质量必须纳入容量评估。2.3 元数据管理与全局序列分布式数据库内部有一套元数据系统负责记录逻辑表与分片的映射关系、分片下的物理节点信息、账户权限信息、全局的自增序列等。元数据这个东西平时不太起眼但它一旦出问题整个集群的路由就会失效。很多生产事故的根因都出在元数据变更没有做好版本管理上例如新增分片、调整副本时如果新旧元数据切换不干净就会导致部分请求路由到旧位置。全局自增 ID 也是分布式数据库必须解决的问题。单机 MySQL 用auto_increment很方便但分布到多个分片后如果还在每个分片内各自自增就会产生重复主键。TDSQL MySQL 提供了全局序列能力可以生成全局唯一且趋势递增的 ID通常用于业务主键。使用时要理解它的实现方式序列生成器会分配一段区间给当前节点使用节点在这段区间内直接递增避免每次取 ID 都走网络请求。我在建表时有一个习惯不依赖数据库的全局自增作为唯一主键而是让应用层先生成业务主键如订单号再配合分片键一起路由。这样既保证了路由效率也避免了序列生成器成为全局热点。2.4 分布式事务从本地事务到全局事务这块是很多初次接触分布式数据库的同学最关心的问题。单机事务只需在本地做 Undo/Redo 就能保证原子性分布式事务则要协调多个分片上的操作同时提交或同时回滚。TDSQL MySQL 采用了两阶段提交思路一个事务协调者通常在这笔事务第一个连接的接入节点上先把事务派发给多个参与者参与者执行完 SQL 后进入待提交状态然后协调者广播提交指令所有参与者真正提交。两阶段提交在工程上有一个绕不开的问题协调者发出“提交”指令后自己宕机了参与者不知道该提交还是回滚只能等待协调者恢复或者查询全局事务状态。生产系统中通常会增加一张全局事务记录表记录每个分布式事务的当前阶段和参与者列表协调者恢复后可以根据记录完成后续动作。即使这样极端情况下仍可能出现“不确定状态”所以业务侧设计分布式事务时一定要考虑最终一致性方案作为兜底。对一个开发人员来说我给出的建议是能用普通事务解决的就用普通事务。比如一个订单模块既要写订单表又要写库存表且这两张表的分片键完全可以设计成同一个维度例如都用买家 ID 或店铺 ID那么这两张表的数据就能落在同一个分片上事务其实不需要跨节点。只有当业务数据天然分散在不同维度比如订单表和商品表分片键不同跨分片事务才不可避免。2.5 高可用与故障切换的容灾细节高可用是个系统工程不只是数据库产品本身的事。TDSQL MySQL 在主备切换时通常由接入层和调度模块共同完成存储节点故障后监控系统发现异常并触发主备切换把某个备副本提升为主副本同时更新元数据路由接入层随后把新的读写请求导向新主副本。实际操作中我最关心的是切换对业务的影响时间。一次普通故障切换如果能在 30 秒内完成业务方通常还能接受但如果超过几分钟就会产生大量超时和报错。为了缩短切换时间一方面监控探测要快另一方面元数据的更新要尽量原子化。另外业务侧的连接池也要设置合理的超时时间不能无限等一个坏连接。通常我会在数据库接入层之前再叠一层负载均衡或代理这样即使数据库发生主备切换应用的连接串也能保持不变代理层会负责把流量切到新的可用节点。3. 部署与接入实操全流程3.1 环境准备与容量评估部署一套 TDSQL MySQL 集群先不要急着敲安装命令容量规划往往决定了上线后的稳定性。我的经验是先按当前数据量和未来一年的增量做预估再留出 30% 到 50% 的余量。假设当前单表数据量 2 亿年增长 3 倍那么明年可能到 6 亿加上足够余量建议按 8 亿到 10 亿的规模设计分片数。硬件上存储节点建议采用本地 SSD 或高性能云盘随机读写性能对数据库影响极大。内存方面单节点建议至少 64GB 起步其中大部分用于缓冲池。网络至少万兆内网尤其是在跨节点参与分布式事务时网络延迟直接决定了事务耗时。CPU 则要看业务类型OLTP 高并发场景偏重多核高频分析型场景偏重大内存。版本选择也要谨慎。除非有新特性硬需求否则不要盲目追求最新版本。稳定的发行版本、活跃的社区或厂商维护周期比新版本上那些“锦上添花”的功能更重要。我曾遇到某个版本在特定场景下存在分布式自增 ID 回退的问题升级前需要仔细查阅修复列表和已知问题。3.2 标准部署流程与初始化部署流程可以概括为以下几个阶段基础组件准备NTP 同步、DNS、用户权限、防火墙放通、存储节点初始化、接入层初始化、元数据模块初始化、集群纳管。第一阶段的基础配置经常被忽视。数据库集群对时间同步非常敏感如果节点间时钟偏差过大主备同步的时间戳比对会出错分布式事务的记录也容易混乱。生产上我建议所有节点配置统一的 NTP 服务并加入定时校验。第二阶段是初始化存储节点。每台节点需要按照规划分配数据目录、日志目录和归档目录。数据目录和日志目录最好分开存储介质避免日志写入和数据读写互相争抢磁盘 IO。第三阶段是接入层。接入层本身不存储业务数据但它要转发所有 SQL所以也需要做多实例部署避免单点。初始化时一般要规划好接入层的虚拟 IP由网络层负载均衡对外提供服务。第四阶段是元数据和集群管理模块。它负责维护整个集群的路由信息、副本状态和账号权限需要独立的存储空间和较高可用性。最后是让集群纳管所有组件并做一个基础连通性测试通过接入层创建测试库、写入几条数据、查询数据确认读写链路、分片路由和副本同步都正常。3.3 创建账号与连接配置集群初始化完成后第一件事就是创建业务账号。分布式数据库的权限体系通常会区分集群级账号和库表级账号。建议为不同业务模块创建独立账号最小化授权避免一个账号权限过大导致误操作风险。应用侧连接方式与单机 MySQL 十分接近。以 Java 为例仍可使用标准的 JDBC 驱动连接接入层地址。不过有几个参数需要特别注意connectTimeout和socketTimeout不要设置太长建议 3 到 5 秒避免数据库故障时应用线程长时间挂起。useSSL如果网络环境不隔离建议开启避免数据明文传输。连接池最大连接数并非越大越好。每个数据库连接都会占用内存连接池过大会让接入层和后端节点连接数失控。建议结合业务并发合理评估比如一个节点预留 100 到 200 个连接已足够大多数业务使用。我见过不少生产问题是应用连接池配置不当导致的应用启动后瞬间创建几千个连接把数据库连接数打满DBA 排查时发现数据库端连接数异常但应用侧实际并发并没有那么高。所以连接池大小一定要和业务压测数据对齐而不是随手填一个很大的数值。3.4 分片键与建表规范分片键是分布式数据库设计中最重要、也最容易踩坑的一环。分片键选得好查询可以在单分片上完成选得不好大量查询变成广播查询性能会指数级下降。选择分片键的核心原则有两条一是查询并发最高的维度二是数据均匀分布。以电商订单场景为例最常见的就是按买家 ID 分片。因为用户查看自己的订单是最高频操作且买家 ID 天然均匀不易产生热点。如果按卖家 ID 分片大卖家可能产生数据倾斜且买家查询订单时需要广播到所有分片。建表语句示例伪代码不同版本细节会有差异create table t_order ( order_id bigint not null comment 订单ID, buyer_id bigint not null comment 买家ID, seller_id bigint not null comment 卖家ID, amount decimal(12,2), status tinyint, create_time datetime, primary key(order_id, buyer_id) ) shard by hash(buyer_id) shardnum 8;这段 DDL 表达的意思是逻辑表t_order会被拆成 8 个分片分片规则按buyer_id的哈希值计算。主键中包含了分片键buyer_id这保证了主键的全局唯一性同时让路由能直接定位到目标分片。这里有个必须注意的细节分片键必须是查询中最稳定的字段。表一旦建好并写入数据分片键就不能随意修改否则路由对不上。如果真的需要改分片键通常要做数据迁移和重新分片这是一个需要提前规划的大工程。3.5 性能调优与参数配置部署上线前我建议做一轮完整的压力测试不要等到业务上线后再发现问题。压测时重点关注三个指标吞吐量TPS/QPS、事务提交延迟、主备同步延迟。如果发现吞吐量上不去先排查分片上的热点。比如分片键选择不合理导致数据集中在少数分片即使整体集群资源充足热点分片也会先打满。其次排查接入层的线程配置和连接池大小看是否存在线程阻塞。参数调优方面MySQL 时代的很多习惯依然适用innodb_buffer_pool_size决定了缓存热数据的能力建议占总内存的 60% 到 70%max_connections要根据后端节点承载能力和业务连接池综合设置日志缓冲、磁盘刷盘策略也需要结合实际数据可靠性要求调整。分布式环境多了一个关注点那就是接入层与存储节点之间的网络参数TCP 缓冲区大小、长连接保活时间都需要保证足够稳定避免连接被意外断开。4. 常见问题与排查技巧实录4.1 分布式事务大量超时怎么办一个典型场景业务上线初期跨分片事务比例较高压测时发现事务提交耗时是单机 MySQL 的好几倍。首先要确认事务真的跨了分片而不是因为分片键设计失误造成的隐式跨分片。可以通过数据库管理端查看事务执行计划看是否涉及多个分片。如果确认跨分片就要从两个方向优化。第一减少跨分片事务的数量尽量把相关的表设计成同分片键。第二缩短分布式事务的持有时间把一次事务里的操作数量尽量减少不要在事务里执行耗时的网络调用或外部接口。第三排查是否有锁竞争。两个事务可能都操作了同一分片上的同一行分布式锁等待会放大整体延迟。我经历过一个案例一个扣款接口在事务里查了用户积分、读了优惠券、更新账户余额、写操作流水四个操作里有三个要访问不同分片。优化方案是把用户积分和账户余额设计成同一个分片键优惠券数据暂时允许最终一致用异步消息补偿。改造后跨分片事务占比从 40% 降到 5%事务耗时明显下降。4.2 跨分片查询慢甚至拖垮集群跨分片查询慢的本质原因是“广播”一条查询被拆成多份分发到所有分片执行然后汇总结果。数据量小的时候还感觉不到数据量一大任何一个慢分片都会拖慢整个查询而且这种查询还会消耗所有分片的资源影响正常的在线业务。排查思路很直接先定位哪些 SQL 是广播查询。一般通过管理端的慢查询日志或 SQL 审计能看到。找到之后优先想到的应该是“改查询条件让 SQL 带分片键”。比如订单表按买家分片运营后台要按卖家查订单这种查询天然要跨分片那么运营场景应该单独建一张按卖家分片或者按订单维度汇总的宽表而不是在线事务库上做全表模糊查询。另一类问题是排序和聚合。order by、group by在没有分片键条件的情况下接入层需要汇聚所有分片的数据再排序内存消耗非常大。我的习惯是大结果集的分页查询尽量限定分片键条件业务产品侧也可以通过“扫一扫”或“时间范围 状态”等方式减少返回数据量从源头规避这种慢 SQL。4.3 数据倾斜导致部分分片过热均匀分布是理想情况实际业务里数据倾斜很常见。比如按卖家的店铺 ID 分片某头部大卖家的订单量大它所在分片很快被打满其他分片却很空闲。这种情况下光是扩容分片数没有意义因为热点数据只集中在某一个分片内。解决思路通常有两种。一种是换分片键改成买家 ID 或订单 ID 这类更均匀的维度但已经上线的业务要迁移数据成本比较大。另一种是二次拆分也就是对热点分片继续细化把一个物理分片再拆分到多个子分片上同时在路由层增加一层映射关系。这个操作需要工具支持不能靠手工改配置文件。我建议在选型阶段就用真实业务数据做一次抽样分析看按照计划的分片键计算后每个分片的数据量是否基本均匀。有些时候看起来均匀的键在几个极端场景下也会倾斜例如定时任务批量产生某用户的数据。这种情况可以预先把分片数设得大一些让单分片容量更小也就是说热点被进一步分散。4.4 连接数耗尽与接入层保护分布式数据库的连接耗尽问题比单机 MySQL 更隐蔽因为除了后端节点连接限制还要考虑接入层的连接数上限。客户端连接接入层接入层再连接后端分片如果应用连接池突发增长接入层线程数、文件描述符数量都可能被瞬间打满。排查时先看接入层的连接监控曲线确认是前端连接数高还是后端连接数高。若是前端连接数高多半是应用连接池配置过大或连接泄漏需要在应用侧排查。若是后端连接数高说明接入层到存储节点之间可能存在连接未及时回收可能是长连接的空闲保活时间设置过长。预防措施方面我会在接入层和代理层都做好连接保护和限流。比如设置单客户端最大连接数、空闲连接回收策略、应用层连接池最小空闲数等。出现连接告警时宁可在代理层挡住大量新建连接也不要让请求直接压到后端存储节点。4.5 主备切换后事务状态不确定主备切换遇到分布式事务处于“已提交待确认”状态是比较棘手的场景。假设事务协调者在向参与者发送提交指令时宕机新的主库并不知道之前这个事务是否完成提交。如果新主库判断事务未提交可能选择回滚但此时部分参与者的旧主库其实已经提交过数据就产生了不一致。应对手段主要依赖全局事务记录。协调者恢复后会去查全局事务表找到未完成的事务根据参与者的实际状态决定继续推进提交还是回滚。这个过程通常是自动的但需要一定时间。如果业务反馈有少量数据“消失”或状态异常可以先检查是否有这种切换期间的后台事务恢复任务。从业务规避角度我强烈建议不要用一个分布式事务同时跨太远距离的多个分片比如同时操作位于不同机房的三个分片。机房之间的网络故障概率更高事务不确定窗口更长。能用同机房、同分片的本地事务完成的操作绝不因为设计偷懒变成跨分片事务。4.6 常见问题速查表问题现象可能原因优先排查方向分布式事务提交延迟高跨分片事务过多、锁竞争查看事务执行计划优化分片键缩短事务体某分片负载远高于其他分片分片键分布不均或热点数据抽样统计分片数据量考虑分片键变更或二次拆分查询无分片键时速度极慢广播查询消耗所有分片改写查询带分片键为报表场景建立独立宽表应用报连接数超出限制连接池过大或连接泄漏检查应用连接池配置、空闲连接回收、接入层限额主备切换后少量数据回滚分布式事务未完成恢复查看全局事务记录等待后台恢复确认业务补偿集群元数据变更后部分表不可访问新旧路由切换不一致检查元数据版本、各节点路由刷新情况5. 迁移与平滑切换实战经验5.1 兼容性评估与迁移工具选型从既有 MySQL 迁移到 TDSQL MySQL首先要做的是兼容性评估。虽然它兼容 MySQL 协议和大部分语法但分布式改造后有一些限制例如不支持跨分片的外键约束、部分复杂子查询需要改写、分区表能力与原生 MySQL 有差异等。迁移工具上常见思路有两种。一是逻辑导出再导入适合停机窗口充足的场景二是基于日志或数据订阅做增量同步适合需要平滑迁移的场景。实际项目里我会把全量导出和增量同步配合使用先全量拷贝存量数据再持续同步增量变更等追平后做切换。5.2 灰度切换与回滚预案一次成功的迁移重点不在“迁成功”而在于失败了还能快速回去。我会把迁移过程分成几个阶段准备阶段、全量同步阶段、增量追平阶段、灰度观察阶段、正式切换阶段。灰度观察阶段非常重要。先切换读流量观察查询正确性和延迟再切少量写流量验证分布式事务和主键生成是否正常。如果出现问题立刻把流量切回老 MySQL此时数据仍然双向同步回滚路径是通的。只有等小流量稳定运行一段时间后再逐步把全部流量切到新集群。这个过程中最需要关注的是增量同步的双向链路。正式切换前写入只发生在老库切换时要有一个同步断点确保新老集群数据一致然后再放写入到新集群。如果切换后还想回退老库这边的增量同步链路也要保留否则一旦回退老库就缺失了切换期间的新数据。5.3 上线后的观察与保障迁移完成后并不意味着事情结束了。上线后的一周内需要密切观察几类指标主备同步延迟、分片负载均衡度、慢查询数量变化、事务成功率。借助监控告警设定阈值任何指标出现异常趋势都要及时介入。我习惯在上线前提前准备好一份“回退手册”列出回退触发条件、具体操作步骤、负责人和联系方式。虽然大多数时候用不上但真到出问题时这份手册能省下最宝贵的半小时。数据库架构改造项目的风险控制拼的就是预案的颗粒度和执行速度。6. 写在后面的一点个人体会最后说一下我踩过几次坑之后形成的习惯。分布式数据库不是银弹TDSQL MySQL 让我印象最深的不是它有多强大而是它对 MySQL 生态的兼容设计做得非常克制。应用层把精力放在分片键设计和跨分片事务规避上而不是重写整条存储链路。如果只能给一条建议我会说上线前先想清楚分片键再想清楚每个核心查询的路由方式。很多人上来就部署集群、跑性能测试结果数据量上来才发现跨分片查询和热点问题频发。分片键设计这件事一旦数据写入后就很难推翻重来一定要在项目初期投入足够的精力。另外容灾演练不要只在纸面上过。真正做一次主备切换演练看看切换时间是不是符合预期、应用侧是否自动重连、分布式事务有没有遗留问题这些测试一定会暴露文档里看不到的问题。演练完之后把当时的操作过程和反应记录下来作为后续排障的参考。数据库系统不怕出问题怕的是问题出现时团队没有演练过只能慌慌张张临时排查。