共计 5273 个字符，预计需要花费 14 分钟才能阅读完成。
背景
金融行业的数据库市场，尤其是银行的外围交易系统，始终是 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 在金融私有云这块的劣势，还在积极探索公有云业务（银行个别都是公有云部署），这对咱们零碎的可用性、文档全备性、周边配套完整性等提出了更高的要求，这也是咱们将来的投入方向之一。
