mysql数据库架构分析_分布式MySQL数据库TDSQL架构分析

随着业务的发展，基于内存的NoSQL解决方案HOLD平台在高峰期一天支撑3000亿读写，证明了分布式Cache的巨大价值;但随着各种业务的接入，NoSQL方案的不足也逐步显现出来了，如下所示。

1、适用的业务场景比较有限，仅提供get/set操作，有不少业务场景希望能通过记录中的其他字段做索引来查询，比如流水类业务。

2、不是所有的数据都是热点，一台64GB内存机器提供的有效内存空间大概在50GB左右，而采用Fusion卡的机型容量一般在1TB以上，对比起来，如果所有数据放入分布式Cache明显是一种极大的浪费，最合理的当然是热点在HOLD，冷数据采用基于磁盘的存储。

3、计费平台部多年来在支付领域有了相当多的技术积累，HOLD作为NoSQL系统功能有限，因此建造一套更加强大通用的高一致性存储系统将整个支付领域的实时数据(重点是账户数据、用户订单数据，以及海量的流水数据)统一管理起来非常有价值。

基于上面的分析，结合我们在MySQL领域多年的应用和优化经验，最终决定在MySQL存储引擎基础之上，打造一套分布式的SQL系统。

1、保持原来的MySQL协议，这样以前访问MySQL系统的C++、Java各类系统都不需要修改，DBA能继续保持原来大部分使用习惯。

2、自动的跨IDC容灾切换，同时保证数据一致性，对于提交成功的事务保证一笔不丢，达到银行级对容灾的要求。

3、灵活的容量伸缩机制，对业务透明，解决MySQL本身扩容不灵活的问题。

4、重点支持OLTP类型的在线业务。

整体架构

针对上面的需求，TDSQL最终的结构如图1所示(与当前大部分中心化的分布式系统类似)。

图1 TDSQL架构

系统由三个模块组成：Scheduler、Agent、网关，三个模块的交互都是通过ZooKeeper完成，极大简化了各个节点之间的通信机制，相对于第二代HOLD的开发简单了很多。

Scheduler作为集群的管理调度中心，主要功能包括：

♦  管理set，提供创建、删除set、set内节点替换等工作;

♦  所有的DDL操作统一下发和调度;

♦  监控set内各个节点的存活状态，当set内主节点故障，发起高一致性主备切换流程;

♦  监控各个set的CPU、磁盘容量、各个表的资源消耗情况，必要的时候自动发起扩容流程;

♦  Scheduler自身的容灾通过ZooKeqzer的选举机制完成，保证中心控制节点无单点。

Agent模块负责监控本机MySQL实例的运行情况，主要功能包括：

♦  用短连接的方式周期性访问本机的MySQL实例，检测是否可读、可写，若发生异常，会将异常信息上报到ZooKeeper，最终会由上面描述的Scheduler模块检测到这个异常情况，从而发起容灾切换;

♦  检测主备复制的执行情况，会定期上报主备复制的延时和延迟的事务数，若发生了主备切换，自动向新主机重建主备，因此MySQL的主备不需要DBA干预，对于新增的实例会自动采用xtrabackup通过主机自动重建数据;

♦  检测MySQL实例的CPU利用率和各个表的请求量、数据量、CPU利用率，上报到ZooKeeper，ZooKeeper通过全局的资源情况抉择如何扩容、缩容;

♦  监控是否有下发到自身的扩容任务，如有则会执行扩容流程(下面会有描述);

♦  监控是否要发生容灾切换，并按计划执行主备切换流程。

网关基于MySQL Proxy开发，在网络层、连接管理、SQL解析、路由等方面做了大量优化，主要特点和功能如下：

♦  解析SQL，将识别出的DDL语句直接存到ZooKeeper，让Keeper来统一调度;

♦  Watch ZooKeeper的路由信息，拉取最新的路由表保存到本地文件和内存;

♦  将SQL请求路由到对应的set，支持读写分离;

♦  对接入的IP、用户名、密码进行鉴权;

♦  记录完整的SQL执行信息，与秒级监控平台对接完成实时的SQL请求的时耗，成功率等指标监控分析;

♦  对count、distinct、sum、avg、max、min、order by、group by等聚合类SQL一般需要访问后端的多个set，网关会分析结果并做合并再返回，暂不支持跨set join和分布式事务;

♦  网关无状态，既支持与业务部署到一起，也可以独立部署(可通过TGW或者LVS做容灾)。