写点什么

拓路前行 -TDSQL 追求极致体验的这一路

发布于: 9 小时前

2007 年,计费平台的一帮年轻人为了实现银行级的高可用、零错账的交易系统,加班加点讨论方案,长达几个月的反复头脑风暴与论证,终于提出了“TBOSS 7*24”容灾方案,并用了一年多时间落地推广后,斩获 09 年公司级技术突破奖,获得了 Tony 的首肯,从此开启了计费平台打造金融级数据库的探索之路。


十年,一路走来,技术追求永无止境,打造一款更好用的高一致、高可用、高性能分布式数据库产品的初心从未改变,系统架构历经三代优化,2012 年立项的第四代产品 TDSQL,经过 5 年打磨与海量业务的实际运营优化,并与腾讯金融云合作产品化,正式以腾讯云金融级数据库对外输出,目前 500+金融客户覆盖银行、保险、基金证券、消费金融、第三方支付、计费、物联网、政企等多个领域,尤其在多家银行的核心交易系统落地,标志着 TDSQL 真正突破成为一款金融级数据库产品,正是这里的突破,使得项目团队今年再次斩获公司级技术突破奖,这也是公司对团队一直专注金融级数据库底层研发耕耘的认可。


当然,道阻且长,随着硬件不断在更新,业务越来越多样且复杂,数据库领域还有许多新的挑战还需我们去攻克。本文尝试着记录下过去十年一路摸爬滚打过程中,团队的一些思考与总结,希望后面的路越走越宽!


从本质上来说,数据库产品要考虑的问题依然还是用户体验的问题!细化来说,数据库产品主要有两类直接用户,分别是开发人员与运维人员,核心就是他们要用得爽。


例如对开发人员来说,他们经常关心的问题有:


1、开发接口是不是标准的?是否提供完善的开发指引?


2、在故障灾难出现时,开发人员需不需要关心数据是否会丢失?需不需要写很复杂的容灾切换逻辑?


3、系统性能好不好,能不能扛住业务浪涌式压力?


4、系统是否足够开放等等?


而对于运维人员 DBA 来说,他们经常关心的问题如:


1、系统的常规操作是否有标准化的工具或页面直接使用?


2、系统是否足够透明,使得在异常时,能否快速的定位问题?


3、是否提供了完善的系统运营手册?


4、配套设施是否完善,例如监控系统、发布系统、冷备系统、审计系统等等?


当然也还有一类间接用户,那就是这些使用数据库的业务系统的真实用户,他们关心的问题有:


1、他们的支付、转账等操作是不是正常的,会不会不到账,多扣钱?


2、他们是否能够随时随地发起交易等等?


通常来说,在资源和时间有限的情况下,这几类用户的需求是要区分不同优先级的,甚至有时候是冲突的,所以我们一路走来,始终保持这样一个原则:在保障用户的基本诉求(数据不丢,不错账)的情况下,然后不断优化开发人员与运维人员的使用体验。例如我们的第一代产品“TBOSS 7*24”就是优先保证高可用、高一致性,确保用户数据不错不丢,但是极大的损害了开发人员与运维人员的体验,需要业务开发人员开发大量的容灾代码,运维人员需要维护大量的灾难模式等,也就是说很多工作交给了业务开发与运维人员。在后面的几代系统更迭中,我们就是不断的将功能下沉,让业务开发和运维越来越简单,必然的数据库本身会更加复杂一些。尽可能的在数据库层面去解决三类用户的诉求,也就变成了 TDSQL 的核心挑战。


TDSQL 的核心挑战


TDSQL 经历大大小小无数版本,始终面对的核心挑战是:


1、数据的可靠性。在任何灾难情况下,例如主机故障、网络故障等等,都不能存在数据丢失的情况。


2、系统的可用性。基于数据多副本的情况下,系统如何保证在一些异常情况下,快速恢复可用,把不可用时长降至最低。


3、高性能。首先,单机性能提升,对于海量业务来说,能够极大的降低服务器等成本;其次,性能指标也是用户最能直接感受到的指标之一,所以性能优化一直是我们优先级最高的任务之一。


4、扩展性。也就是通常说的分布式。其实在金融行业,之前对分布式这块的需求并不大,但是随着第三方支付的快速发展,给银行的一些系统造成了很大的冲击,例如双 11、春节红包等活动,这类系统使用传统的 IOE 架构很吃力,所以他们也希望能采用分布式架构来解决这个问题。抛开从思维层面,分布式架构对传统金融 IT 行业人员的冲击外,其实从技术上来说,这里其实挑战很多,TDSQL 也是在逐步的优化与解决,例如最复杂的两个点分布式事务与分布式 Join 操作。目前我们已经完成了分布式事务功能的发布,而分布式 Join 还在内测过程中。


5、配套工具。一个数据库软件要体验好,那么就不能仅仅提供几个核心的包,必须要有相应的运营管理工具、问题诊断工具、性能分析工具等,并且是一个开放的、标准的接口,只有这样大家才能更好更无缝的使用。


上面的几个问题,前面 2 个是基本功能的问题,在第一个版本就已经基本保障了,但是是不是就足够了?远远不够,路走得不够多,遇到的坎太少,碰到新的坑时,依然可能会摔跤。我们只有在足够丰富的场景中,通过大量的实践运营经验,使得自己的系统经历足够的磨练,才能使得系统的可用性和数据可靠性保持足够多的 9。后面几个问题,本身也应该是一个持续优化的过程,TDSQL 也一直在寻找最优雅的方式去解决,所以下面就从这几个问题,看看 TDSQL 具体是如何做的。


核心架构


TDSQL 的核心架构大体如下:


Set 机制:TDSQL 所有的高可用机制均是在 Set 之内实现,每个 Set 之内多个数据节点(1 主 N 备),主备之间可以是基于 Raft 协议的强同步复制机制,也可以是异步复制机制。在主机出现故障的情况下,在调度模块的协助下,将挑选备机按照规定流程提升为主机,快速恢复业务,全程无需人工干预。在我们常规的使用过程中,通常是建议 1 主 2 备,主备之间强同步,这样在主节点故障情况下,能确保自动切换,RTO 为 40s,RPO 为 0。


水平扩容。分布式版本对外呈现为一个完整的逻辑实例,后端数据实际上是分布在若干 Set 上(独立的物理节点)组成。逻辑实例屏蔽了物理层实际存储规则,业务无需关心数据层如何存储,也无需在业务代码中集成拆分方案或再购买中间件,只需要像使用集中式(单机)数据库一样使用即可。同时支持实时在线扩容,扩容过程对业务完全透明,无需业务停机,扩容时仅部分分片存在秒级的只读(只读是实际在做数据校验),整个集群不会受影响。


分布式事务。TDSQL 基于 MySQL 的 XA 实现了分布式事务机制,对各种异常处理做了充分的鲁棒测试,且相对于单机事务,性能损失仅 30%。


高级特性


二级分区。第一级即我们常说的水平拆分,原理是使用 HASH 算法,使得数据能均匀的分散到后端的所有节点;第二级分区使用 RANGE 算法,使得相关的数据能够落在一个逻辑分区,例如可以按时间分区(类似每天每周每月一个分区等),亦可以按业务特性分区(类似每个省市一个分区等)等等。二级分片可以均衡数据分布和访问,为快速一键扩容提供基础支撑,也可以满足快速删除数据等场景。


读写分离。基于数据库访问账号的读写分离方案,DBA 能基于业务需求对账号设定相关参数,以确保既不会读取到过旧的数据,也不会影响写业务,且业务无需改动代码即可实现读写分离。这可以极大的降低业务运营成本。


此外,TDSQL 还有全局唯一数字序列、统一参数管理、兼容 MySQL 函数,热点更新等众多高级特性,可满足各类业务需求。


内核优化


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,降低冲突,以提升性能。


类似的性能优化的点,还有不少,可能在某些场景下,单个点效果不明显,但是集合起来看,目前性能指标整体是不错的。基于 SysbenchOLTP 测试结果,相同的硬件及测试环境下,TDSQL 性能相比原生版本提升 85%。


安全增强。在安全方面做了大量优化及增强,包括数据文件加密、SQL 防火墙、SSL 接入、安全审计等。


此外,我们长期关注 MySQL 的三个分支版本:MariaDB、Percona、MySQL community,对于社区的新特性,也会定期的合入。


部署方案


TDSQL 的强同步机制,本身是可以做到全球化部署的,但其实我们绝大部分客户无论是成本看,还是从业务场景看,都不需要做全球部署,常见的两地多中心基本都能满足需求。客户可以基于成本、自身业务数据的容灾要求,以及数据中心分布情况,选择不同的部署方案。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、整个城市故障可以人工切换


周边配套


对于 TDSQL 的开发者和运维 DBA 来说,其配套设施、可维护性、透明性等至关重要,因为这决定了他们能否及时发现问题,针对问题能快速的做出变更及应对。所以 TDSQL 经过这两年的产品化工作,提供完善的周边配套体系,例如:


1)冷备系统。基于 HDFS 或其他分布式文件系统,可以做到自动备份,一键恢复。


2)消息队列。基于 Kafka 定制的 Binlog 订阅服务。基于该消息队列,TDSQL 还提供了 SQL 审计、多源同步(相同表结构的数据合并到一张表)等服务。


3)资源管理。基于 cgroup 的对 TDSQL 实例进行编排,提高机器资源利用率。


4)OSS。对 TDSQL 的所有操作,例如扩容、备份、恢复、手动切换、申请(修改/删除)实例等操作,均提供统一的 HTTP 接口,可以有效自动化,降低人肉运维的风险。


5)数据采集。TDSQL 所有的内部运营状态或数据,都能实时采集到,业务可以基于这些数据做定制分析或者构建运营监控平台。


6)监控平台。业务可以基于数据采集模块采集到的所有数据,对接自建的监控系统,亦可直接使用 TDSQL 自带的监控系统(需单独部署)。


7)管理平台。基于以上模块,TDSQL 自带运营管理平台(内部平台代号赤兔),DBA 基本上可以通过该管理台进行所有常规的运营操作,不再需要登录后台。


8)审计模块。审计模块通过对用户访问数据库行为的日志采集及分析,用来帮助客户事后生成合规报告、事故追根溯源,同时加强内外部数据库网络行为记录,提高数据资产安全。


以上这些模块可以自由组合,没有强依赖关系,运维人员也可以通过 TDSQL 的提供的接口自行对接自己现有的平台(如监控、告警、审计等)。


写在最后


TDSQL 一路走来,在可靠性、可用性、性能、扩展性、配套设施等方面取得了一些里程碑式的成果,但是远没有到极致的用户体验。例如我们定位是 OLTP 数据库,适合高并发短事务的场景,但客户有时候需要在数据库上跑一些的 OLAP 操作,那这块我们能不能做?如何做?目前的分布式还无法真正做到一个单机数据库使用,那么在未来硬件发展情况下,能否做到呢?类似这些挑战还很多,数据库研发这块道阻且长,与大家共勉。

用户头像

还未添加个人签名 2018.12.08 加入

还未添加个人简介

评论

发布
暂无评论
拓路前行-TDSQL追求极致体验的这一路