TDSQL 演进三部曲

TDSQL 前身在 2004 年开始启动研发，至今已经持续积淀了十数年。回顾它整个演进历程，可以分为几个阶段。

**互联网开放浪潮的前夕：分布式数据库如何一步步成型**

如果大家去充 Q 币，或者在腾讯业务内消费时，如果金额不对，这将是不可能接受的事情。所以最早从 2004 年开始，腾讯内部需要做计费业务时，我们当时迫切需要的是数据一致性和系统高可用等性能。

当时，还是互联网 IT 的早期，少有公司会愿意投入底层技术的研发。而作为一家互联网科技公司，为何不用技术来解决技术问题？于是，**从 2004 年开始，腾讯内部开始基于开源体系 MySQL 进行研发，以实现高数据一致和系统高可用等，这也是 TDSQL 的前身。**

也是在这样的背景下，TDSQL 就逐步诞生了。所以腾讯金融类业务从一开始就没有 Oracle，没有“IOE”。

基于 MySQL 来发展这样一套系统架构，在后来的经历中也验证了，这是一件非常困难的事情，但也验证了当初的巨大投入所带来的技术价值。

最初，我们没有对 MySQL 本身去做一些优化的工作，更多的是在效率的迫切要求下，结合 CAP 原理，在应用层去解决这些问题。

后来我们发现，在应用层做工作，**解决第一个系统问题时是快速的，但对于后续大规模应用开发时，和业务应用紧耦合的形式难以将这些数据一致性、高可用的解决方案推广到其他业务系统来应用**。因为它对于业务层、应用层而言，改造成本太大了，因为在业务快速发展的过程中，业务本身历史包袱越来越重，不太可能要来适应新的架构改造。

需求自然是迫切的，当时业务面临着业务拆分，以及上百台设备集群管理问题，所带来的数据一致性、数据准确可靠性等问题。

因此我们开始考虑，**我们必须将这些容灾、数据一致性等逻辑，全部下沉到数据库层面来开发构造，让应用层只需要专注在业务逻辑，而不需要管理容灾等逻辑。**

从开发的角度讲，这也是一件相对而言投入更大、难度更高的事情，然而那时大家有预感，我们将会创造一个全新的事物。

也因为这样，对未来事物的好奇战胜了困难的阻碍。2007 年的数据库开发中，团队几个人闭关在一个小黑屋里面，开始了疯狂的代码构建，主攻解决计费等公司级敏感业务高可用、核心数据的零流失、核心交易的零错账等问题。

针对金融类业务的特点，TDSQL 技术团队目标很明确，包括以下几个要点：

数据强一致的要求

数据库集群的可用性、稳定性和容灾要求要达到银行标准

业务无需拆分超大表，数据库自动拆分

接入要简单，老业务改造要小

符合并高于金融行业信息安全监管要求

而在解决这些问题后，整个技术团队开始思考未来的技术发展方向，并且对技术架构设计有了新的想法——我们希望做一套新的系统。在把数据一致性、可靠性等特性从应用层整合到数据库层过程中，基于业务腾飞的预判，我们认为，数据库层还需要具备分布式水平扩展的特性。

于是，团队开始对这个数据库架构进行重构。

非常幸运的是，就在 TDSQL 完成分布式水平扩展的自研开发时，大约到了 2009 年，腾讯马上迎来了腾讯开放平台时代。那个时候，互联网开始了真正意义的社交应用爆发的阶段，诞生了如开心农场等产品。

**而这个 TDSQL 的雏形，正很好地以高可扩展性、数据一致性、可靠性、高可用性等，支持了当时的开放浪潮。直至到今天，TDSQL 经历过了数百亿个账户的场景验证，具备了完善的支持金融级场景和监管要求的能力。**

**为金融场景而生：产品化的金融级分布式数据库 TDSQL**

**技术的迭代常常来自于业务场景的驱动。**

2007-2009 年中，随着腾讯开放平台的发展，我们迎来了大量的合作伙伴，面临的行业场景也越来越丰富多样。这时大家发现，这款数据库在支持腾讯内部业务体系是很完美的，但是无法很好的为合作伙伴提供服务——因为在发展的早期，它还不够标准化。

如何才能更好地服务合作伙伴的需求？如何才能让这样的分布式数据库系统服务更多用户，最大化发挥技术的价值？……

唯有持续的研发和迭代。

一直到了 2012 年，期间腾讯以“开源定制化+自研”为策略进行定制化，打磨出更加通用的数据库产品，并正式命名为 TDSQL，以解决金融等业务系统中高可用、数据一致性、水平伸缩等问题。

**可以说 TDSQL 的诞生，一开始就是为金融场景而生。**

逐渐地，随着对金融行业应用更深刻的洞察，TDSQL 逐步完善了分布式事务、分布式查询等能力，在性能和应用性之上持续发展，目标就是把 TDSQL 打造成一个类似单机版的关系型分布式数据库。我们知道，金融行业对事务处理的需求极高，转账、扣费，无一不是使用事务，而腾讯是少数几个将分布式事务处理，分布式查询用于金融核心系统的企业。

作为一款 Shared-Nothing 架构的分布式数据库，从能力上讲，TDSQL 比当前流行 HTAP 更进一步，它重新定义了一种综合型的数据库解决方案，也可以分配 Noshard 实例、分布式实例和分析性实例，同时支持 JSON/RockDB 等方案。当然，TDSQL 最主要的特点在于其具备 shard 架构能力。

**持续完善的技术生态和产品服务体系**

2016 年以后，TDSQL 正式开启自主可控之路，开放给更多的金融企业使用，得益于海量业务场景的锤炼，使得 TDSQL 成为一款产品化数据库，具备一个完整的产品体系。

目前，TDSQL 具备六大核心特性，包括数据强一致性、金融级高可用、高性能低成本、企业级安全性、线性水平扩展、智能化运维。而在一些事关数据安全的特性上，TDSQL 做了重点的加强，比如针对高可用等问题。TDSQL 可以轻松支持异地多活。

除了技术上保障之外，TDSQL 还从运营角度保障数据的安全。据分析，目前，金融行业大部分数据库产品化程度不够，相当多的安全事故均是由运营操作不规范带来的。TDSQL 通过提供“赤兔”自助运营和“扁鹊”智能 DBA 彻底规避人为误操作带来的安全隐患。

“赤兔”自助运营服务，可以从管理员视角，在可用性、安全、效率、成本维度进行全方位管控，90%的日常运营操作均可以通过 Web 页面完成，减少人为差错同时帮助金融用户节约管理及经济成本、降低风险。

“扁鹊”智能 DBA 则帮助金融用户防范系统异常，通过采集超过 400+运营指标，基于 AI+Policy 的智能诊断技术，帮助金融用户快速定位解决问题，并预防潜在风险，防范于未然。

此外，分布式数据库 TDSQL 为用户提供数据库防火墙、透明加密、自动脱敏等安全防护措施，减少用户误操作和黑客入侵带来的安全风险。

**持续积累，用时间锤炼出一款自主可控的数据库**

经过十数年的积累打磨，在持续地优化分布式、高可用、高性能等特性，以及不断完善满足客户的需求过程中，TDSQL 作为产业化自主可控数据库，持续在行业保持领先。

而 TDSQL 演进到今天的能力规模，来源于腾讯自身业务场景的驱动和锤炼。一款金融级分布式数据库，必须要经过多年产品生态体系的积淀，以及海量业务场景的锤炼。TDSQL 架构的迭代演进，正因为从腾讯海量用户场景、复杂交易的业务实践中来，才能更好地满足广大客户数据库技术和业务柔性的需求。

举个例子，在产品的质量保障方面，TDSQL 版本发布会经历严格的流程，最终才推广到客户场景中：首先是计费团队（技术孵化团队）使用验证，继而推广应用到腾讯公司其他业务团队，而在这些内部场景中，我们都能较好地控制和修复；在这两个阶段后，新版本发布才经历腾讯公有云用户的验证，最后发布在私有云上。

另一方面，在产品化过程中，TDSQL 结合实际应用和客户反馈，充分考虑数据库整个应用生产流程，来不断完善产品服务体系，包括运营体系、数据库多源同步迁移等配套设施。

基于这样的产品化打磨，腾讯具备开放的技术生态基因。开放并不是说一定要开源，而是提供开放的标准、完善的服务，比如数据库多源同步迁移，以及自主可控的开源生态，支持良性竞争，让客户免于被绑定风险。

**未来，如何与 Oracle 兼容、与 AI 和异构计算等前沿技术融合等等，都是值得思考的挑战和创新问题。TDSQL 将持续通过产研结合、产用结合的方式进行研发突破，并开放商用更多特性，拥抱开源社区**