分布式MySQL数据库TDSQL架构分析
175 浏览量
2021-02-20
21:15:41
上传
评论 1
收藏 409KB PDF 举报
分布式分布式MySQL数据库数据库TDSQL架构分析架构分析
摘要：摘要：腾讯计费平台部为了解决基于内存的NoSQL解决方案HOLD平台在应对多种业务接入时的不足，结合团队在
MySQL领域多年应用和优化经验，最终在MySQL存储引擎基础上，打造一套分布式SQL系统TDSQL。本文是对该系
统架构分析。
腾讯计费平台部托管着公司90%以上的虚拟账户，如QB、Q点、包月服务、游戏的二级账户等，为了保证能顺畅支撑
公司各大业务的实时在线交易，并且在各种灾难场景下数据是一致并且可用的，对系统的可用性、一致性切换要求非
常高，因此计费团队历来都非常重视高一致性存储系统的建设。
到目前为止，计费高一致性存储层的解决方案大致经过了3个阶段，本文将分享最新的基于MySQL的分布式解决方
案。
随着业务的发展，基于内存的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作为集群的管理调度中心，主要功能包括：
1. 管理set，提供创建、删除set、set内节点替换等工作；
2. 所有的DDL操作统一下发和调度；
3. 监控set内各个节点的存活状态，当set内主节点故障，发起高一致性主备切换流程；
4. 监控各个set的CPU、磁盘容量、各个表的资源消耗情况，必要的时候自动发起扩容流程；
5. Scheduler自身的容灾通过ZooKeqzer的选举机制完成，保证中心控制节点无单点。
Agent模块负责监控本机MySQL实例的运行情况，主要功能包括：
资源评论
