腾讯私有云MySQL解决方案—TDSQL

TDSQL是腾讯提供的一套完整的MySQL数据库集群化管理解决方案,作为私有云TStack平台重要的数据库产品能力,旨在解决高可用、高性能、分布式、配套设施等方面问题

TDSQL除了在腾讯内部有大量的使用场景,在外部市场中也有诸多应用场景;2014年被WeBank选中,作为其核心交易系统的数据库解决方案,以私有云方式交付;2015年,在腾讯云上正式推出。目前已经为500+机构提供数据库的公有云及专有云服务,客户覆盖计费、第三方支付、银行、保险、互联网金融、物联网、互联网+、政务等领域。

TDSQL私有云版本的核心思路是:标准化、模块化、丰俭由人

例如TDSQL的模块设计是充分解耦的,彼此之间通过接口衔接,客户可以自行组装或用自己现有模块替换;又比如在设计部署架构时,客户可在成本(自身数据中心建设情况),业务数据安全可靠性、业务可用性三者之间做不同的平衡选择,可以做到N地N中心的部署,数据副本亦可做到一主N备(N>=0);甚至在设计读写分离机制时,只读账户可根据主备延迟状态,选择是从备机读取,还是从主机读取,还是直接返回错误;数据库引擎,TDSQL也提供MariaDB、Percona、MySQL社区版三个版本支持。类似这样的设计贯穿TDSQL私有云版本的整个研发过程,以给予客户足够的灵活性和选择权。

TDSQL关键特性

  • 数据可靠性 在各种异常灾难情况下,例如主机故障、网络故障、数据中心故障等,都能确保数据安全可靠。
  • 系统可用性 基于数据多副本,系统保证在各种异常灾难情况下,可根据客户不同的数据可靠性级别,快速恢复可用,把不可用时长降至最低。强同步数据节点之间自动切换,RTO为40s,RPO为0。
  • 高性能 对MySQL三大分支(MariaDB、Percona、MySQL community)深度优化,使得在主备网络延迟5ms的情况下,能做到跨IDC强同步性能相较于异步同步零损耗;同时sysbench OLTP TPS数据是原生版本185%。
  • 水平扩展性 提供Auto Sharding机制,可实现实时在线无缝扩容,确保集群性能和容量呈线性增长;同时提供健壮的分布式事务机制,在性能损耗极低(损耗30%)的情况下,大大降低了传统业务迁移分布式架构的难度。
  • 自动化运营 提供完善的运营体系,自动化运营发布平台,机器资源自动管理,智能监控平台及展示,数据库智能诊断等。
  • 配套设施 TDSQL还提供Binlog订阅、安全审计、冷备系统、多源同步等配套系统,供客户选择。

核心架构

TDSQL的核心架构大体如下:

Set机制

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

水平扩容

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

分布式事务

TDSQL基于MySQL的XA实现了分布式事务机制,对各种异常处理做了充分的鲁棒测试(发现了10多个XA相关的Bug并进行修复提交到社区,并做了大量性能方便的改进,扩展了事务状态方面的统计信息以实现全局分布式死锁检测),且相对于单机事务,性能损失仅30%。

高级特性

二级分区

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

读写分离

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

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

内核优化

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

强同步机制

TDSQL针对金融场景的强同步机制,有效解决了MySQL原生半同步机制的问题:性能降低以及超时退化为异步。目前TDSQL在强同步模式下,系统的并发量(TPS/QPS)与异步模式已无差别,基本能做到性能无损失。

性能优化

1、我们对MariaDB/Percona的线程池调度算法进行了优化,改进当系统处于重负载时,查询和更新请求在线程组间分布不均衡等极端情况。并且能够更好地利用计算资源,减少无谓的线程切换,减少请求在队列中的等待时间,及时处理请求。

2、组提交(Group Commit)的异步化。工作线程在其会话状态进入组提交队列后,不再阻塞等待组提交的Leader线程完成提交,而是直接返回处理下一个请求。

3、InnoDBBuffer Pool使用优化。例如全表扫描时,避免占满InnoDB Buffer Pool,而是只取一块来使用。

4、InnoDB在MySQL组提交期间避免与组提交有mutex冲突的活动,例如InnoDB Purge,降低冲突,以提升性能。

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

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

部署方案

基于成本因素考虑,客户可根据自身业务数据的容灾要求,以及数据中心分布情况,选择不同的部署方案。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私有云版本,提供完善的周边配套体系,例如:

  • 冷备系统 基于HDFS或其他分布式文件系统,可以做到自动备份,一键恢复,支持物理备份,逻辑备份,增量备份等各种策略。
  • 消息队列 基于Kafka定制的Binlog订阅服务。基于该消息队列,TDSQL还提供了SQL审计、多源同步(相同表结构的数据合并到一张表)等服务。
  • 资源管理 基于cgroup的对TDSQL实例进行编排,提高机器资源利用率。
  • OSS 对TDSQL的所有操作,例如扩容、备份、恢复、手动切换、申请(修改/删除)实例等操作,均提供统一的HTTPS接口,可以有效自动化,降低人肉运维的风险。
  • 数据采集 TDSQL所有的内部运营状态或数据,都能实时采集到,业务可以基于这些数据做定制分析或者构建运营监控平台。
  • 监控平台 业务可以基于数据采集模块采集到的所有数据,对接自建的监控系统,亦可直接使用TDSQL自带的监控系统。
  • 管理平台 基于以上模块,TDSQL自带运营管理平台(内部平台代号赤兔),DBA基本上可以通过该管理台进行所有常规的运营操作,不再需要登录后台。
  • 审计模块 审计模块通过对用户访问数据库行为的日志采集及分析,用来帮助客户事后生成合规报告、事故追根溯源,同时加强内外部数据库网络行为记录,提高数据资产安全。

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

写在最后

TDSQL经过多年发展,上面提到的特性,均在腾讯内部的海量业务实践运营过程中得到检验,这也是TDSQL对外版本发布的基本原则:只有经过现网运营验证并觉得充分成熟的特性,才会发布给客户,所以大家可以放心使用。

原文发布于微信公众号 - TStack(gh_035269c8aa5f)

原文发表时间:2017-09-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏直播系统开发

专业直播APP开发服务商教你直播平台搭建需要准备些什么——流媒体CDN服务篇

网络直播可谓是近年来互联网的“热门关键词”,如今直播平台已经深入到了各行各业,诞生了数不尽的行业解决方案。这些解决方案都离不开直播系统源码,通过一套功能全面的直...

4274
来自专栏老九学堂

号称“开发者神器”的GitHub,到底该怎么用?

相信这么努力的你 已经置顶了我 老九学堂 你身边的IT导师 提醒:大师兄会员课讲解视频在文末哦。 GitHub是一个拥有数十亿行代码的网站,每天有数百万开发者...

34311
来自专栏跨界架构师

分布式系统关注点——「负载均衡」到底该如何实施?

        前面两篇《分布式系统关注点——初识「高可用」》、《分布式系统关注点——仅需这一篇,吃透「负载均衡」妥妥的》看完后,相信大家对实现高可用的思路和负...

1501
来自专栏NetCore

对于大数据大流量情况下微软架构的水平扩展的遐想(瞎想)

最近回顾SAAS的书籍,书中的扩展架构都有点让我痴迷,但书中介绍的都是以Java,Apache,JBoss,Hadloop等技术实现负载均衡,大数据处理,对于微...

2288
来自专栏数据和云

【从根源出发,化风险为可控】应用到数据库的连接数管控

作者介绍 ? 巩飞(Morinson) 云和恩墨技术专家 网名Morinson,现服务于云和恩墨西北区,有14年在IT公司的技术类工作经验,特别是在 Ora...

3195
来自专栏章鱼的慢慢技术路

游戏服务器存储系统设计

data——>file(database)——>file system——>hard driver

4723
来自专栏沃趣科技

备份重于一切:远离“Gitlab删库事件”,QBackup是你的最佳选择!

作者简介:孙朝阳 沃趣科技高级产品经理。 案发现场: Gitlab删库事件回顾 Gitlab是大家很熟悉的开源Git代码托管工具,国内公司大多使用社区版自行搭...

3748
来自专栏陈树义

官方老爹之痛:为什么苹果能收到推送,而安卓不行?

还记得上次我们做过的试验么? 我们在 iOS 设备杀掉进程后能收到推送,而 Android 设备却不行。这个问题可困惑了小树很长时间,这天趁着工作清闲,又跑到小...

3678
来自专栏CSDN技术头条

一场完美的“秒杀”:API加速的业务逻辑

一天清晨,我被一个客户电话惊醒,客户异常焦急,寻问CDN能不能帮助他们解决“秒杀”的问题,他们昨天刚刚进行了“整点秒杀活动”,结果并发量过大,导致服务宕机,用户...

3309
来自专栏企鹅号快讯

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系...

3859

扫码关注云+社区

领取腾讯云代金券