「TEG+系列」破局者 - 腾讯金融级数据库TDSQL

背景

金融行业的数据库市场,尤其是银行的核心交易系统,一直是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在金融公有云这块的优势,还在积极探索私有云业务(银行一般都是私有云部署),这对我们系统的可用性、文档全备性、周边配套完整性等提出了更高的要求,这也是我们未来的投入方向之一。

上一篇:IBatis.net Sqlite 增删改查 Demo


下一篇:nginx+SLB