共计 5659 个字符，预计需要花费 15 分钟才能阅读完成。
在数字化时代，作为根底软件，数据库的自主可控对于企业的数据安全、业务稳固具备重要意义。只有实现“自主可控”能力从根本上保障信息安全，尤其是波及重大平安的政府和金融畛域，对数据安全的要求进一步增强。因而，在互联网安全回升至国家策略层面的背景下，如何在底层根底数据库层面实现自主可控成为云计算厂商一直谋求的指标。
基于微信领取 / 红包的简单业务场景，腾讯始终致力于实现数据库的自主可控，保证数据强一致性、高可用和程度扩大。实际上，腾讯推出的 TDSQL(TencentDistributed SQL) 金融级分布式数据库，在对内撑持微信红包业务的同时，对外也正在为中国金融行业技术自主可控分布式数据库解决方案
作为国内首家互联网银行，微众银行背地的 IT 基础架构摈弃了传统的 IOE，齐全采纳了互联网分布式架构。从 2014 年开始，腾讯云开始为微众银行提供外围交易数据库解决方案。TDSQL 在微众银行作为交易外围 DB，部署超过 800 个节点，承载全行所有 OLTP 业务。因为齐全采纳互联网架构，相比传统的 IOE 计划，微众银行在 IT 老本上大幅节约。同时，互联网架构的高伸缩性，使得微众银行的服务能力具备很高的弹性，足以轻松应答普惠金融场景下的潮涌。
“2017 年微众银行将每个账户的经营老本降至均匀只有 6 元人民币，仅为边疆传统银行的 1/10，相比国内银行则更低，只有其老本的 2% 至 5%。”微众银行副行长兼 CIO 马智涛说。
目前 TDSQL 已正式通过腾讯金融云对外输入金融级分布式数据库产品服务，除了微众银行，腾讯分布式数据库 TDSQL 还撑持着华通银行、华夏银行、潍坊银行、内蒙金谷农商银行、北京人寿、爱心人寿等泛滥银行和保险公司的互联网外围生产零碎。并曾经为超多家政企和金融机构提供数据库的私有云及公有云服务，客户笼罩银行、保险、证券、互联网金融、计费、第三方领取、物联网、互联网 +、政务等畛域，失去了客户及行业的统一认可。
那么在市场业务环境变动的场景下，TDSQL 是如何实现自主可控和技术迭代的呢？上面咱们从 TDSQL 的架构演进来具体分析。
业务场景暴发推动数据库进化
从架构上讲，TDSQL 是 Shared-Nothing 架构的分布式数据库；从部署形式来讲，TDSQL 是一款反对多租户的云数据库；从能力上讲，TDSQL 比以后风行 HTAP 更进一步，它从新定义了一种综合型的数据库解决方案，也能够调配 Noshard 实例、分布式实例和剖析性实例，同时反对 JSON/RockDB 等计划。当然，TDSQL 最次要的特点在于其具备 shard 架构能力。
在 2004 年，腾讯充值、财付通等业务暴发倒退，但那时腾讯和所有的守业公司有个共同点—“穷”，在这样的背景下，TDSQL 逐渐诞生了，所以腾讯金融类业务从一开始就没有 IOE。
因为期间经验了业务层对拆分的滥用，主从数据不统一导致的数据准确性问题，以及上百台设施集群的治理问题等。
所以，从 08 年开始，团队决定重构 TDSQL 解决方案，针对金融类业务的特点，列出以下几个要点：
数据强统一的要求
数据库集群的可用性、稳定性和容灾要求要达到银行规范
业务无需拆分超大表，数据库主动拆分
接入要简略，老业务革新要小，必须兼容 MySQL 协定
合乎并高于金融行业信息安全监管要求
TDSQL 的软件架构组成
整体来说，TDSQL 是由决策调度集群 /GTM，SQLEngine、数据存储层等外围组件组成的，其每个模块都基于分布式架构设计，能够实现疾速扩大，无缝切换，实时故障复原等，通过这一架构，TDSQL 的 Noshard、Shard、TDSpark 实例能够混合部署在同一集群中。并且应用简略的 x86 服务器，能够搭建出相似于小型机、共享存储等一样稳固牢靠的数据库。
在架构上，TDSQL 的核心思想只有两个：数据的复制（replica）和分片（sharding），其它都是由此衍生进去的。其中，
replica 配合故障的检测和切换，解决可用性问题；
sharding 配合集群资源调度、拜访路由治理等，解决容量伸缩问题。
同时，因 replica 引入了数据多正本间的一致性问题和整体吞吐量降落的问题，而 sharding 的引入也会带来肯定的性能束缚。在最终实现上，TDSQL 由 Scheduler、Gateway、Agent 三个外围组件加上 MySQL 组成，其中：
Scheduler 是治理调度器，外部又分为 zookeeper 和 scheduler server；
Gateway 为接入网关，多个网关组成一个接入层；
Agent 是执行代理，与 MySQL 实例一起，形成数据节点。多个数据节点形成服务单元 SET。
相比单机版的 MySQL，TDSQL 的劣势次要体现在集群维度，包含容灾、高一致性、高弹性等。
注：✔ 反对，✘不反对，○不实用
数据一致性考验
在金融行业，银行、风控、渠道等第三方通常通过读写拆散形式来查问数据，而在互联网行业，因为 x86 绝对较高的故障率，导致数据可能经常性的呈现错乱、失落场景。为了解决这个问题，就必须要求主从数据的强统一和良好的读写拆散策略。其关键在于，如何实现强同步复制技术。
因为 MySQL 的半同步和 Galera 模式不仅对性能的损耗是十分大的，而且数据同步有大量毛刺，这给金融业务同城双核心或两地三核心架构容灾架构带来了极大的挑战。
为什么会这样呢？从 1996 年的 MySQL3.1.1.1 版本开始，业务数据库通常跑在内网，网络环境根本较好，因而 MySQL 采纳的是每个连贯一个线程的模型，这套模型最大的益处就是开发特地简略，线程外部都是同步调用，只有不拜访内部接口，撑持每秒几百上千的申请量也根本够用，因为大部分状况下 IO 是瓶颈。
但随着以后硬件的倒退，尤其是 ssd 等硬件呈现，IO 基本上不再是瓶颈，如再采纳这套模型，并采纳阻塞的形式调用提早较大的内部接口，则 CPU 都会阻塞在网络应答上了，性能天然上不去。
因而，TDSQL 引入线程池，将数据库线程池模型 (执行 SQL 的逻辑) 针对不同网络环境进行优化，并反对组提交计划。例如，在 binlog 复制计划上，咱们将复制线程合成：
1、工作执行到写 binlog 为止，而后将会话保留到 session 中，接着执行下一轮循环去解决其它申请了，这样就防止让线程阻塞期待应答
2、MySQL 本身负责主备同步的 dump 线程会将 binlog 立刻发送进来，备机的 io 线程收到 binlog 并写入到 relaylog 之后，再通过 udp 给主机一个应答
3、在主机上，开一组线程来解决应答，收到应答之后找到对应的会话，执行下半局部的 commit，send 应答，绑定到 epoll 等操作。绑定到 epoll 之后这个连贯又能够被其它线程检测到并执行。
革新后，使得 TDSQL 能够应答简单的网络模型。当然，深刻理解过 MySQL 同步机制的敌人可能会发现上述计划还有小缺点：当主机故障，binlog 没有来得及发送到远端，尽管此时不会返回给业务胜利，备机上不存在这笔数据，然而在主机故障自愈后，主机会多进去这笔事务的数据。解决办法是对新增的事务依据 row 格局的 binlog 做闪回，这样就无效解决了数据强统一的问题。
2018 年初，英特尔技术团队应用 sysbench 测试计划，在跨机房、雷同机型、网络和参数配置和高并发下测试，TDSQL 强同步复制均匀性能是 MySQL5.7 异步复制的 1.2 倍。
基于规定和基于代价的查问引擎
以后大多数分布式数据库都设计的是基于规定的查问引擎 (RBO)，这意味着，它有着一套严格的应用规定，只有你依照它去写 SQL 语句，无论数据表中的内容怎么，也不会影响到你的“执行打算”，但这意味着该规定简单的数据计算需要不“敏感”。尽管金融业务都有本人的数据仓库，然而也会常常须要在 OLTP 类业务中执行事务、JOIN 甚至批处理。
TDSQL 在 SQLENGINE 实现了基于代价的查问引擎 (CBO)，SQL 通过 SQLENGINE 的词法，语法解析，语义剖析和 SQL 优化之后，会生成分布式的查问打算，并依据数据路由策略（基于代价的查问引擎）进行下推计算，最初对汇总的数据返回给前端。
而作为分布式的计算引擎，在存储与计算引擎相拆散的状况下，十分重要的一环就是如何将计算尽量下推的上面的数据存储层。因而 TDSQL 的 SQLENGINE 在通过大量业务打磨后，实现了基于 shard key 下推，索引条件下推，驱动表后果下推，null 下推，子查问下推, left join 转化成 inner join 等多达 18 种下推优化伎俩，尽量升高数据在多个节点传输带来的压力，以提供更好的分布式查问的能力，撑持金融交易的关联操作。
全局事务一致性与全局工夫戳服务 GTM
金融行业对事务处理的需要极高，转账、扣费，无一不是应用事务，而腾讯是少数几个将分布式事务处理，分布式 JOIN 用于金融外围零碎的企业。
TDSQL 依然是通过经典的 XA 两阶段提交加两阶段封闭协定实现了强分布式事务的语义，以撑持金融场景对事务管理的需要。在应用语法上与 MySQL 齐全一样，即后端的分布式事务处理对业务应用方是齐全不感知，以保障兼容性。
在二阶段提交实现上，在 begin 的时候从 GTM 获取全局递增的事务 ID，而后在参加事务的各个子节点通过这个事务 ID 开启事务，进行各种 DML 操作，提交的时候先对各个子节点执行 prepare。当 prepare 胜利之后，再更新全局事务 ID 的事务状态，同时获取到一个新的事务 ID 作为提交的事务 ID 对各个子事务进行异步并行化的提交，提供更好的事务操作性能。
以后 GTM 以一主两从的形式运行，主从节点底层通过 raft 协定进行数据的同步以及主从切换，外部交互以及对外通信均基于 grpc 协定。以后 TDSQL 的 GTM 组件性能齐全能够满足金融业务需要：
全局工夫戳：≈180w – 190w TPS，8 Clients，主节点 CPU 跑满状况下（24core），内存耗费约 23GB；
递增序列号：≈750w – 780w TPS，8 Clients，10 万个 key，主节点 CPU 跑满状况下，内存 耗费约 30GB；
从节点资源耗费：因为所有申请均由 Leader 节点实现响应，从只负责承受来自于 主节点的 raft 数据同步申请，并且 从节点上不缓存任何数据，因而 CPU 和 内存耗费都在极低的水平；因而，个别场景下，通常 GTM 与调度决策集群能够混合部署，极大的节俭了物理设施老本。
TDSQL 的 HTAP 能力
TDSQL 除了提供计算下推，分布式事务等个性，也针对 OLAP 需要演进了 TDSpark 个性。简略来说，是将 SQLEngine 基于 OLAP 场景做了批改，保留原生的 MySQL 协定接入能力。因而业务持续能够通过拜访 MySQL 的渠道接入到 OLAP-SQLEngine，OLAP-SQLEngine 在这个时候不是将分布式的查问打算间接下推到各个数据库节点，而是引入一个中间层，目前是采纳 SPARKSQL, 通过 SPARKSQL 弱小的计算能力能显著晋升简单 SQL 的执行性能。另外为了确保剖析操作与在线的 OLTP 业务隔离，咱们 TDSQL 的数据层为每份数据减少 1 个 watch 主数据库的数据异步节点，确保剖析操作与在线业务操作不相互影响。
数据安全与容灾
数据安全和容灾是金融类业务的命根子，而 TDSQL 现曾经利用在多个银行、保险的私有云或公有云环境。符合国家等级爱护信息安全要求，通过银保监会相干审核，取得了包含 ISO，SOC 等国内和国际标准。
而在容灾能力方面，TDSQL 能够反对：
同城数据强统一下的双活：以后腾讯私有云和金融云有大量的客户都抉择了相似计划。
主从读写拆散的异地多活：该计划实用于利用齐全不做任何革新，就能够实现跨城多活的能力。以后 TDSQL 很多客户不想对业务革新，然而又想具备跨城多活和切换的能力，通常抉择这个计划。
多主的异地多活架构，并反对双向同步：通过应用层依据用户维度做了辨别之后，能够使得多套 TDSQL 数据库别离承载不同的业务进行读写事务拜访，实现齐全的多活能力，然而如果业务零碎无奈保障调度平安和数据的辨别，可能存在数据异样的危险。
多主的异地多活架构，多套主从架构：综合了后面两种架构，实现了齐全的异地多活 + 读写拆散的能力，并且即便业务层路由谬误，也不会引起数据异样。当然，对应的应用层也要能配合批改。
当然越高要求对部署的要求约简单，目前私有云曾经提供了后面两种计划可供大家试用。
数据库自治经营
为了保证系统的运行做到所有尽在掌控之中，TDSQL 不仅有欠缺的管控零碎（赤兔）来实现零碎的自动化治理，从可用性、平安、效率、老本维度进行全方位管控。还在赤兔中引入了“数据库自治经营”的理念，构建了一套能自我学习的智能检测平台（简称扁鹊）
以 SQL 优化为例，该零碎能主动形象出以后效率最差的若干 SQL，并将这些通过解析 SQL 生成 AST 语法树，剖析语法树中表的连贯形式和连贯字段，而后遍历语法树中的过滤，排序等关键字段，再次剖析各字段的区分度，对于区分度较高的字段会提供举荐优化计划，综合字段区分度，过滤规定，表连贯程序等多个因素推提供优化倡议。
TDSQL 的自治经营的最终目标是利用私有云宏大的环境进行自我学习和自我进化，做到无需人工干预即可进行更新、调整和修复，从而解放人力、缩小人为过错，帮忙企业节约治理及经济老本、升高危险。
金融业务的数据库倒退及瞻望
金融业务波及国计民生的重点业务，一个小小的 BUG，一个操作失误，就可能影响到数以万计的百姓资产准确性。正因为这样的责任，腾讯云 TDSQL 团队始终坚守则“本心”。
目前，TDSQL 已在北京、深圳、成都三地建设研发团队，并通过 CMMI3 认证，同时在开源社区领有本人的开源分支。值得一提的是 TDSQL 已取得包含 ISO27001、ISO22301、PCI DSS、SOC 审计，工信部分布式数据库测试，IT168 技术冲破大奖，多项国家或国内认证和行业殊荣。并与包含中国人民大学，中国银行等发展产研联合、产用联合，并获得诸多翻新问题。
瞻望 2019 年，TDSQL 将继续通过产研联合、产用联合的形式进行研发冲破，并凋谢商用更多个性，拥抱开源社区。
