背景

金融行业的数据库市场，尤其是银行的外围交易系统，始终是Oracle、DB2这类传统商业数据库的天下，然而：

2014年，微众银行选用TDSQL作为其外围交易系统的数据库解决方案；

2015年，腾讯金融云正式推出TDSQL数据库解决方案，在私有云以及公有云上投入商用，笼罩包含银行、保险、互联网金融、物联网等多个行业畛域。

这标记着TDSQL曾经开始进入这个畛域，尽管目前，金融、传统行业的外围数据库仍然是Oracle、DB2们占主导，然而TDSQL对外开放仅两年，曾经为40个金融政企机构提供数据库服务，部署Set数已达800+（一个Set由一主两备三个数据库结点组成），算是开了一个好头。

抉择TDSQL？

首先是金融行业本身受到了互联网行业的冲击。例如目前中国网民的两大节日：阿里巴巴的“11.11剁手节”，微信的“春节红包节”，给银行的领取零碎，尤其是快捷领取零碎，带来了很大冲击，原有的IOE架构面领比拟大的挑战。此外，金融行业外部也开始思考，如何通过云计算、大数据等技术，提供更为普惠的金融服务，晋升金融行业的服务效率。这些都使得基于TDSQL的分布式互联网架构来代替集中式的IOE架构成为可能。

其次，在诸多数据库产品以及内外竞争对手之中，TDSQL有着其本身显著的劣势：十年在计费及领取行业的应用，在数据的安全性，可用性等方面有大量的实战积攒，填了不少的坑。计费平台部从2007年开始，摸索数据库的高可用、高一致性，着力钻研如何为计费领取利用提供7*24的高可用服务，零碎经验三代更迭。

1）7*24容灾机制，是一套基于黑名单机制的主备容灾切换机制，就义极少数用户的可用性，确保零碎的数据高一致性。

2）厚德（HOLD）KV存储，是第一代容灾机制的连续，次要是将黑名单等容灾机制下沉到存储系统，彻底将容灾与业务逻辑解耦，业务开发人员不再须要关怀容灾。同时引入集群管理机制，及主动扩容技术，在申请量及时耗要求特地高的场景下，目前仍然大量应用，目前部署节点数达400+。

3）TDSQL，2012年开始，团队开始思考如何将咱们在数据库容灾切换、数据高一致性等方面的教训输入进来，于是就有了TDSQL，其能够说对计费前几代存储系统的整合之作：应用MySQL作为底层数据节点，把厚德（HOLD）中验证过的集群架构间接移植过去，将金融场景下最关注的一致性保障和程度伸缩等要害个性，都间接融入底层架构中。这样能完满兼容MySQL协定，升高原有基于数据库的业务零碎的割接难度。

最初，当然也有硬件行业的疾速倒退的契机，尤其是SSD在公司的大规模应用，使得TDSQL的云化成为可能。

后期的挑战？

第一阶段是2014年，微众接入之初。在此之前，TDSQL并没有为公司内部客户提供过服务，其产品化是一个比拟高级的阶段，尽管有十年计费应用教训作为背书，然而单方团队仍然有一个信赖的磨合期。

对于TDSQL服务承诺的信赖？TDSQL承诺在任意单点故障状况下，RPO为0，RTO为40秒，然而并没有其余第三方机构针对TDSQL出过相似数据。对此，单方测试团队坐在一起，耗时1个月，结构100+测试用例，在高并发场景下，模仿各种异常情况，以确保能合乎TDSQL的服务承诺。

对于数据库及利用架构的设计？因为单方理论生产环境的网络架构不一样，导致单方后期在数据库及利用架构部署上，有较大的一致，对此，单方架构师团队也是通过频繁的多层次的交换，最初在综合老本及零碎安全性之间做好均衡，分阶段设计出不同架构体系。

第二个阶段是在2015年，TDSQL正式为金融云提供服务后，较多的内部客户接入进来，带来了新的一些新的挑战。

TDSQL是否适应更为简单的场景？之前TDSQL更多的应用于OLTP场景，尤其是大量高并发的短事务场景，为了晋升吞吐量，并解决MySQL的连接数限度问题，引入的数据库线程池性能，而这个性能在某些场景下有些不实用，例如在同时有大量简单SQL（耗时至多几秒以上的SQL）并发时，零碎吞吐量急剧升高。而云上大量接入进来的金融客户业务开发团队，却仍然将TDSQL当作Oracle来用，这导致问题凸显，对此团队深刻MySQL内核，做了大量优化，例如对线程池的优先级队列进行优化，无效解决简单SQL高并发带来的吞吐量升高问题。

传统思维与互联网思维的抵触？团队与大量传统金融行业的IT人员交换之后发现，单方在如何应用分布式数据库等方面，仍然有比拟大的一致，例如传统行业的业务零碎极为依赖数据库，基本上一条SQL用A4纸都打印不完，大量应用存储过程，而互联网行业则将大量的逻辑放在应用层，数据层尽可能的轻量化、服务化。相似的抵触，可能不是一时半会能对立的，在不同的场景下，可能须要作出不同的抉择与衡量。TDSQL须要向Oracle学习，联结各个上下游服务提供商或集成商，尽量为客户提供一套残缺的分布式解决方案。

TDSQL的解决之道

上面将从外围架构、内核优化、部署计划、周边配套、产品化等方面来剖析一下，TDSQL是如何适应金融行业需要的。

1、外围架构
在一致性方面，利用MySQL binlog的严格有序性以及强同步复制机制，再联合Raft协定思维（Raft协定外围两点就是Leader选举、日志复制），咱们最终实现了TDSQL的强一致性以及数据零失落。

强同步机制：基于MySQL半同步复制优化，对于进入集群的每笔更新操作，都将发到对应Set（每一个Set蕴含3个MySQL实例：一主两备）的主机上，主机会将binlog发往两个备机，且收到其中任一一个备机应答后（仅仅是备机收到了binlog，但可能还没有执行这个binlog），而后才本地提交，并返回给客户端应答，这就能确保数据零失落。

可用性：在这种强同步机制下，倡议是存3个数据正本，且别离散布在3个 IDC，这样在任一IDC故障状况下，剩下两个IDC仍然可能提供服务。如果仅存2个正本，在某中一个正本故障状况下，零碎将会降级为只读服务。

Leader选举：MySQL节点自身无奈直接参与选举，于是咱们由Scheduler模块来负责这个事，如果主机产生故障，Scheduler会从两个备机中，抉择一个数据较新的备机（因为MySQL binlog是严格有序的，所以谁同步主机binlog的偏移量更大，谁的数据就更新。当然也能够基于GTID来判断）晋升为主机。

主动扩容：目前TDSQL有两个分支版本，一个是No-Sharding版本，一个是Group-Sharding版本，NS版本不反对主动扩容，GS版本反对主动扩容，然而该版本对SQL有肯定的限度。

Group-Sharding尽管不反对跨节点事务和Join，然而在一个Group内，能够反对Join和事务。举个例子，假如有两张表：用户信息表与用户账户表，咱们能够将这两张表组成一个逻辑Group，且这两张表都按用户ID字段Sharding，后续Group内任意一张表须要Re-Sharding时，该组内所有表都同时进行Re-Sharding（相当于按Group进行Sharding），这样单个用户相干数据肯定会落在一个Shard上（即同一个MySQL实例），于是在单个用户条件下，这些表之间是能够做Join和关联的。

2、内核优化
TDSQL在数据库内核这块的优化，次要集中在数据复制、性能、安全性等方面。

强同步机制。TDSQL针对金融场景的强同步机制，无效解决了MySQL原生半同步机制的问题：性能升高以及超时进化为异步。目前TDSQL在强同步模式下，零碎的并发量（TPS/QPS）与异步模式已无差别，根本能做到性能无损失。

性能优化。

1）咱们对MariaDB/Percona的线程池调度算法进行了优化，改良当零碎处于重负载时，查问和更新申请在线程组间散布不平衡等极其状况。并且可能更好地利用计算资源，缩小无谓的线程切换，缩小申请在队列中的等待时间，及时处理申请。

2）组提交（Group Commit）的异步化。工作线程在其会话状态进入组提交队列后，不再阻塞期待组提交的Leader线程实现提交，而是间接返回解决下一个申请。

3）InnoDB Buffer Pool应用优化。例如全表扫描时，防止占满InnoDBBuffer Pool，而是只取一块来应用。

4）InnoDB 在MySQL组提交期间防止与组提交有mutex抵触的流动，例如InnoDB Purge，升高抵触，以晋升性能。

相似的性能优化的点，还有不少，可能在某些场景下，单个点成果不显著，然而集合起来看，目前性能指标整体是不错的。目前TDSQL在云上TS85机型下（24核、512G内存、6T磁盘），用sysbench测试，纯写入操作能到10万TPS，纯查问操作能到40万QPS。

此外，咱们长期关注MySQL的三个分支版本：Oracle MySQL、MariaDB、Percona，对于社区的新个性，也会定期的合入。

3、部署计划
基于老本因素思考，不同的客户，甚至说同一客户在不同阶段，会有不同的网络架构，例如一些客户后期可能做不到两地三核心，前期也不会像腾讯那样，领有那么多数据中心。所以TDSQL能够针对客户不同的网络架构，在保障一致性及数据不丢的状况下，在可用性上做出衡量，做到灵便部署。目前常见的两种部署计划包含：

两地三核心，ZK散布在两地的三个核心内。

1）主IDC故障不会丢数据，主动切换到备IDC，此时堕落成单个IDC的强同步，存在危险。

2）仅仅主机故障，在比照两个同城备节点及一个同城Watcher节点后，切换到数据最新的节点，优先选择同IDC的Watcher节点，尽可能减少跨IDC切换。

3）备IDC故障，通过另外一个城市的ZK能主动做出选举：

a、备IDC的确故障，主动晋升主IDC的Watcher节点为Slave,由主提供服务

b、主备网络不通，与a)一样的解决形式

两地四核心，适应性最强，然而对机房数量要求也高一些。

1）同城三核心集群化部署，简化同步策略，经营简略，数据可用性、一致性高；

2）单核心故障不影响数据服务；

3）深圳生产集群三核心多活；

4）整个城市故障能够人工切换；

4、周边配套
给一个曾经绝对成熟的行业去推一款新型数据库，如果仅仅提供数据库底层是远远不够的，其配套设施、可维护性、透明性等对于客户来说至关重要，因为这决定了他们是否及时发现问题，针对问题能疾速的做出变更及应答。所以TDSQL公有云版本，提供欠缺的周边配套体系，例如：

1）冷备零碎。基于HDFS或其余分布式文件系统，能够做到主动备份，一键复原。

2）音讯队列。基于Kafka定制的Binlog订阅服务。基于该音讯队列，TDSQL还提供了SQL审计、多源同步（雷同表构造的数据合并到一张表）等服务。

3）资源管理。基于cgroup的对TDSQL实例进行编排，进步机器资源利用率。

4）OSS。对TDSQL的所有操作，例如扩容、备份、复原、手动切换、申请（批改／删除）实例等操作，均提供对立的HTTP接口，能够无效自动化，升高人肉运维的危险。

5）数据采集。TDSQL所有的外部经营状态或数据，都能实时采集到，业务能够基于这些数据做定制剖析或者构建经营监控平台。

6）监控平台。业务能够基于数据采集模块采集到的所有数据，对接自建的监控零碎，亦可间接应用TDSQL自带的监控零碎（需独自部署）。

7）治理平台。基于以上模块，TDSQL自带经营治理平台（外部平台代号赤兔），DBA基本上能够通过该治理台进行所有惯例的经营操作，不再须要登录后盾。

以上这些模块能够自由组合，没有强依赖关系，对于TDSQL的推广极为无力，因为纯接口方式，松耦合对于TDSQL对接客户的自建零碎，例如监控平台等极为不便。

5、产品化即云化
诸多案例来看，TDSQL及互联网架构齐全有能力撑持金融外围业务。而其低成本、高弹性以及凋谢的架构又恰好能补救传统IOE架构的有余。

看起来，TDSQL就是去IOE的银弹。然而，事实真的如此吗？

大家都晓得，互联网分布式架构的底层根底是凋谢的硬件和开源的软件，初始获取老本会比拟低。然而，要用于生产的话，还须要进行大量的、继续的优化和改良，而且对运维团队的能力要求也比拟高。如果企业想间接迁入分布式架构上，势必须要组建一个技术团队来搞定这些问题，这就相当于将原来IOE架构下投在软硬件上的老本转投到人力上。在IT零碎规模较小时，齐全没有劣势，甚至是得失相当的。这也是“去IOE”喊了这么久，实质性停顿却比拟小的一个起因。

然而，云计算的呈现扭转了这所有。在云计算架构下，这些原本要招一帮牛人才能搞得定的事件，当初曾经有一帮甚至更牛、更业余的人帮你搞定了。你要做的，只是“申请、应用”，就这么简略！

所以，TDSQL不是去IOE的良药，TDSQL on Cloud才是。目前与腾讯金融云团队，除了坚固TDSQL在金融私有云这块的劣势，还在积极探索公有云业务（银行个别都是公有云部署），这对咱们零碎的可用性、文档全备性、周边配套完整性等提出了更高的要求，这也是咱们将来的投入方向之一。