本文根据潘安群老师在2017年12月3日【DBAplus数据库年末盘货大会】现场演讲内容整理而成。点击此处下载PPT~
讲师先容
本日在座的大部分高朋都是Oracle的专家，在Oracle的高可用、数据安全性等方面有着非常深厚的履历，而我地点的腾讯公司，在关系型数据库的利用场景下，根本还是以MySQL这套开源产物为主。
而MySQL这套开源产物，与Oracle这类成熟的贸易产物在利用上大概说理念上有着很大的差别，以是我在这里会分享一下我所负责的分布式数据库产物TDSQL的十年研发运营之路，盼望能给各人带来不一样的思绪。
分享大纲：
腾讯十年纪据库技能发展之路
TDSQL核心特性
分布式程度扩展
腾讯内部及部分客户的摆设实践
腾讯数据库技能发展之路
我来自腾讯TEG计费平台部，一开始负责公司整个计费体系的存储体系研发，如今重要负责TDSQL数据库的研发。这是我们产物的几个发展阶段：
我是2007年进入公司的，在此之前公司业务是一个蛮横生长阶段，以是腾讯在数据库的高可用、安全性方面思量不多，到了2007年左右，业务履历了第二次腾飞之前的一个安稳阶段。
趁这个机遇，团队启动了一个7*24高可用服务项目，目标就是包管计费等公司级别敏感业务高可用、核心数据的零流失、核心买卖业务的零错账。这也是TDSQL的前身。
当时提出的办理方案更多还是在应用层办理，两个DB之间数据假如差别步，则会在业务层锁定，在出现故障时做主备切换，并让没有同步完数据的用户买卖业务不可用，别的用户正常买卖业务。按照CAP原理来明白就是：当故障（P）出现时，我们捐躯少数用户的可用性（A），来包管100%的数据同等性（C）。
在业务层做有一个非常大的长处——可以或许知道锁什么样的数据，但假如当时在数据库层面做的话，必须思量到业务会涉及到很多张表的数据，非常不好做。
这内里最大的弊端就是——对应用层来说耦合度太高了，包罗数据层的容灾，比方说主DB非常了要去切换到备机时，什么时间检测故障？什么时间是真的故障了？什么时间切换？怎么做切换逻辑？这个逻辑是业务开辟职员控制的，以是落地时间周期很长。由于一个体系完成改造，并通过多次现网演练终极到达稳固且符合预期，必要非常长的时间才华搞定，而我们体系又非常多，是一个非常艰巨的过程。
到了2009年，思量到如许的高同等性办理方案易用性并不好，我们基于雷同思绪做了一套KeyValue体系，这比研发一套SQL体系要简单很多，但依然有一个题目，KV体系不像SQL是标准化的东西，而且功能没有SQL丰富，以是业务体系从SQL迁徙到KV存储，相称于存储架构都改了。而我们线上业务是7*24服务的，以是改造及迁徙工作量也比力大，推广时间周期依然长。
以是很天然地，在2012年左右，我们就想做一套基于SQL的分布式数据库，取名TDSQL，目标就是让数据库来办理高可用、数据同等性、程度伸缩这些题目，而让业务体系只必要关注业务逻辑。
2014年腾讯投资了微众银行筹办，它的定位是要做一家互联网金融科技银行，以是一开始确定架构是基于互联网架构去做的。在对比了很多公司表里多个数据库产物方案后发现，TDSQL刚好跟他们的场景是比力符合的，在高可用、数据同等性方面比力切合金融行业的需求，以是整个微众银行的核心买卖业务体系全部的数据库全部都是基于TDSQL，在银行核心买卖业务体系里用如许的架构在无论在当时还是如今来看，都还是开创性的。
在微众乐成落地投产后，我们盼望我们的产物能为更多金融机构提供服务，以是在15年在腾讯云上也发布该产物，如今我们提供公有云PaaS服务，也提供私有云产物。
以上就是腾讯十年的数据库技能发展之路，接下来是本日分享的重点，我会先从TDSQL核心特性开始，然后讲讲分布式程度扩展，末了分享在腾讯内部以及在部分客户的摆设实践。
一、核心特性
开源MySQL的玩法跟Oracle简直实有很大的差距，Oracle看起来就是一个高富帅，而MySQL看起来怎么也是一个经济实用男。比方我们支持的业务以及客户，清一色的X86服务器，网络也是平凡的专线网络，还是很经济实惠的。
以是有些传统企业的客户跟我们交换，问假如一台呆板挂了怎么办？浮夸一点来说，就是这台服务器咱就不要了，但这在Oracle生态下是不大概发生的事变。以是基于呆板坏了就不要了的理念，在容灾方面上的计划就很不一样了。
别的，Oracle的功能确实非常强大，以是很多传统的运营商、银行客户过于依靠数据库，把大部分的逻辑都放在数据库层面，让数据库搞定，但MySQL很多时间搞不定如许的事变，以是互联网对数据库的依靠没有那么重，很多功能还是在业务层面做。
那像开源体系比力突出的一个题目是什么？就是坑特别多，在规模小的时间，大概题目不突出，一旦规模上去了，各种题目就蜂拥而至。官方团队对题目或Bug的相应是比力慢的，以是很多题目得必要本身去办理；而Oracle作为一家贸易公司，相对来说就要好很多，根本上客户出了什么题目，都能比力快速的相应并帮忙办理。
以是这也是我们为什么将TDSQL在腾讯云上开辟出来的一个目标，就是盼望TDSQL在近十年在腾讯海量数据运营下走过的弯路、以及办理的题目，在别的团队不要再走一遍。
刚开始我们是定位金融这一块，这当中有几个题目必须要办理，一是高可用题目，二是数据可靠性、零丢失的题目。由于之前在行业内做分布式数据库的人以为，MySQL体系做不到数据零丢失大概是主备之间数据的同等性，但着实这个东西是没什么题目的，是完全可以做到的，看看我们是怎么做这个点的。
图：TDSQL核心架构
这是TDSQL的架构，如今分布式架构一样平常分为三个核心模块，第一模块是数据节点（上图右下角），通常是一主两备的方式。上面的两个模块构成调治体系，临时是用ZooKeeper来做元数据管理。第三模块是接入盘算层，当发生故障时主备切换和对路由的更新都在网关层面上做。上面的调治体系还包罗负责监测故障、故障切换的操纵，以及分布式场景下的扩缩容任务管理等，别的包罗一些复杂SQL的重新以及盘算工作。这是大要的核心架构。
1复制主备数据复制方式
我们再从右下角的Set讲起，通常是一主两备的方式。如今MySQL是两种复制模式，一种是异步复制，一种是半同步复制。但我们实测时会发现题目，当主备之间同步超时时，半同步复制会由超时时间退化为异步，这在金融场景下风险是比力大的。
按照CAP的原理，甘心捐躯肯定的可用性也不肯意把数据丢失，假装备机非常了，退化为异步了，主机继承买卖业务。
假如此时主机再发生故障，数据库层面很大概出现数据丢失，一旦数据库层面出现数据丢失，过后要去修复黑白常困难的，以是这种时间我们是不让它退化，继承强同步（大概买卖业务失败），固然在具体实现时会做调解，根据业务特性去做设置设定是否退化异步。两个备机里只一个备机乐成出现故障的概率会低很多，但不是说完全不会出现故障，但概率会低很多。
强同步更新流程
别的，在实际测试时做同城跨数据中心，这时的性能斲丧会非常大，在MySQL5.6版天性能斲丧要降到原来的非常之一左右。如今5.7版本，在同步这里官方做了一些异步化处理惩罚，性能降落题目已经好很多了，但依然会有性能斲丧。以是在复制这块，我们重要是去办理这两个题目。刚才讲的一主两备，两个备机是都做强同步复制的。
半同步复制的不敷
这是我们本身实测的结果，TPS降落非常快，以是我们做了两个异步化处理惩罚。
颠末这些异步化改造，在性能方面我们如今可以做到同城跨数据中心，5毫秒以内的耽误的环境下，可以或许包管数据强同步和异步之间TPS不会降落，网络单笔时耗大概会增长，但增长网络耽误这是很正常的一种环境。也正是由于有了强同步TPS不会降落的题目，以是我们也敢在业务大规模推行同城三中心架构，这个架构我在下面会再具体睁开讲。
SET布局
一样平常在同城三个数据中心之间一主两备，这三个数据节点放在三个数据中心。在这种环境下，做强同步任何一个数据中心非常都可以或许主动地切换已往，切换到别的的数据中心。以是这种可用度黑白常高的。如今可以或许答应的是同城做强同步的话可以到RTO40秒，RPO为0。
在跨城通常还是做异步的同步，这里假如必要强行切换到跨城异地的备份中心，会有数据丢失的风险。固然这也是概率的题目，我们以为只有像在整个深圳三个数据中心全都挂掉了，或地动级别的劫难才会出现到这种环境，以是假如真要做跨城切换的环境下，有少量的数据丢失是可以担当的。
固然我们跟上海也可以做强同步，但有两方面的因素：
第一是做了强同步以后单笔哀求的网络耽误就太大了，原来在同城做强同步大概只必要2-3毫秒的哀求访问，但跨城的话至少要30-40毫秒。而且一笔买卖业务每每涉及上百次数据库操纵，这将是指数级的放大，会对前端业务体系的资源斲丧非常严峻，以是没有须要为了如许非常小概率的事变让平常的资源有这么大浪费。
第二是跨城网络稳固性会差很多，在腾讯同城内部数据中心是环形的专线网络，三个数据中心当中任何一条专线断了根本上不会有影响，以是同城的网络稳固性非常高，但跨城的网络稳固性就要差一些，而且常常有颠簸，以是我们也没有须要为了小概率变乱做如许的操纵，以是跨城做异步，依然是本钱与体系可用性之间的一个均衡。
刚才我们在同城跨数据中心切换答应的是40秒，为什么说是40秒呢？我们是分成了两部分，第一部分20秒是故障检测阶段，第二部分是服务规复阶段，服务规复阶段重要是根据Raft协议选主、等待数据回放完成等工作，我们守旧一点答应是20秒完成，不外在我们实际运营环境中，通常3-4秒就可以完成这些工作。相对来说，服务规复阶段在业界是比力成熟的，理论也比力完备。
在这里我想重点要提一下故障检测阶段。着实故障检测黑白常难的事变，起首我们都是基于X86的服务器，固然如今服务器硬件一年比一年往上翻，性能越来越好，但实际上依然会有很多业务在上线时计划得不公道，每个用户来的时间都会做全表扫描，偶然你根本防不胜防，假如轻微没留意放已往了就一下子把体系给冲毁了，整个数据库节点表现就是不可用了。
那么，在资源被斲丧光的环境下要不要做切换？在业务看来，数据库根本上是不可用的，理论上是必要切换的，但是你切换后，发现没啥用，SQL哀求内里又把新主机压垮了。
别的，我们如今广泛利用的SSD盘，SSD有一个题目是寿命的题目，坏也不是一下子忽然坏了，这中心有一条曲线，IOPS和磁盘相应时间有一个渐渐变差的过程。那这种环境下怎么切，在什么时间点切换呢？
在故障检测这个点上，如今来看很难有同一的一个理论说怎么发现故障、怎么去切换，这黑白常难的事变，更多还是履历方面的积聚，我们承袭的原则还是：切换后，假如体系可用性能提拔，才切，否则免切。这确实可以克制很多没故意义的切换。
2主备高同等性保障数据高可用性的保障机制（规复）
故障检测时间是可以设置的，我们设置3秒钟一次监测，大概要连续6次出现非常环境才会去触发切换，而且连续6次的环境下还要匹配到本身内部的逻辑——是不是切换已往就可以或许办理题目，假如像刚才那种由于业务利用不当导致了体系数据库不消的话切已往也没什么用，在这种环境下不会做无谓的切换。
假如偶然间体系出了题目大概会引发连续的切换，连续切换对体系也没什么长处，比如说我们切换了一次后，设置在将来的一段时间不会做切换，用如许的逻辑做判定。
这里是我们在服务规复阶段的示例演示。刚开始A是主机，B、C作为备机，而且B轻微耽误一些，C备机数据更新一点，此时a+3这个事件，仍旧是未提交乐成的，此时假如A主机故障了，那么调治体系会选择C作为新主机，B作为C的备机，构成一主一备的Set。
此时，我们会优先思量，A节点是否能快速规复（如MySQLbug，大概网络闪断等），假如能，则对a+3事件Rollback后，作为备机，继承提供服务；假如A节点不能快速规复（如磁盘故障，服务器故障），则必要重新找一台服务器，通过物理备份+追Binlog的方式，快速构建一个新备机，尽大概地快速规复为一主两备的三节点Set提供服务。
高同等性容灾：怎样包管没有脏数据
整个切换流程是一个严谨的操纵，每个操纵是有次序的，否则大概会出现双写的环境，这都是靠切换流程来保障。
通常同城三中心架构，每个数据中心都是对等划一的。一旦由于故障，导致主备发生切换，除非再次发生故障，我们不会主动切换返来，这是同城三中心高度对等架构的长处。
任何一个中心的节点都可以提供主服务，这种更加标准化的摆设，运维可以做到主动化操纵，对运维管理的复杂程度要轻微低些。
可靠性保障体系
这是冷备体系，每天会做全量的镜像，并及时做Binlog的增量备份，这些都会颠末压缩后存储在分布式文件体系上，以便客户可以规复到汗青某一个时候的数据点。如今我们在公有云上默认提供30天的恣意时间点回档。
为什么必要每天做镜像呢？还是为了规复的速率题目。比如说游戏出现了庞大Bug必要快速回档，第二是DBA误操纵删除数据了，这些环境都必要从冷备规复。固然，每天一个镜像在一些环境下规复时间也会比力长，假设每天破晓4点钟做备份，但刚幸亏备份前一两个小时数据被删掉了，那这种规复就必要用前一天破晓4点的镜像数据，外加追一天的Binlog日记规复，这个时间是比力长的。
在内部有雷同变乱的时间会有几个点从流程上优化：
第一点，一旦发现出现删数据的环境，无论是DBA误删还是由于体系内部Bug，一旦报了故障过来，立马申请新实例，并行开始规复数据，不管终极会不会用上。
第二点，我们会有一个冷备验证环境，专门用于验证冷备体系及冷备数据的可用性。腾讯会有大量的数据库实例，每天随机挑选一些实例主动规复，并跟现有生产环境去比对数据。我们要确保冷备备份出来的数据是可用的，我们通过这种随机抽查的冷备验证机制，确保整个冷备体系的可用性。
3性能性能指标：单节点
性能绝对数值本身没什么太大意义，差别的厂商可以用差别测试场景，发布对本身产物有利的数据。这里我想增补一点就是关于硬件。
硬件发展着实很快。大概两年前，我们本身内部用一个代号为Z3的服务器，大概1.3TSSDFusionIO卡。到了2017年年初，我们如今已经开始用上了TS85服务器，这种机型已经相称锋利了，是24个物理核，512G内存，4块1.8TNVMESSD卡，我们把它做成RAID0，在数据库里很少有人说数据盘是用RAID0的，但在我们架构里通常都是RAID0。条件就是数据三副本，我们体系的可靠性及可用性不依靠单个副本，一个副本故障了就重新构建一个副本。
读写分离
基于数据库账号的读写分离
基于Hint的读写分离
二、分布式集群
1程度扩展性
下面讲一下分布式实践。TDSQL一开始是定位在腾讯内部做计费、金融付出这类场景，是常见的OLTP场景。思量到OLTP场景，一个体系的及时买卖业务数据量并不会超等大，以是我们采取预分片的战略，一开始把数据帮你做好逻辑分片，比方设置为64个分片大概是128个分片，固然要做到1024个分片乃至更多都没什么题目，但通常来说用不了那么多分片。
你想想，单节点基于当前硬件可用是6T存储空间，假如到达128分片，就将近有大几百个T，对买卖业务体系来说数据量是绝对够的。
为什么要做预分配呢？如今有很多数据库是主动扩容的，大概一开始做了哈希，但这类也谋面临一个题目——数据大量地删除，假如仅仅删除一部分数据的话空间不肯定会开释。以是一开始做好预分配在运营管理上会有非常大的方便，比如说你删除分区的话速率黑白常快的，别的就是空间会立马得到开释，以是在运营层面会非常友爱。
别的，有些表的数据没有须要做分布式，大概是设置表，以是会有广播小表大概是NoSharding表，如许做买卖业务事件会非常方便。
三种数据Sharding方式
SQL支持
MySQL本身在复杂SQL场景下处理惩罚会比Oracle差一些，尤其是在数据分析方面。但通常来说，标准的聚合函数都是没什么题目，我们如今也支持基于两阶段提交的分布式事件，但Join是有差别的。。
有很多场景下不让做Join，直接克制一些复杂JoinSQL。这里重要从体系可用性坚固性方面思量，我们担心一旦放开限定，客户在本身测试环境测试，由于数据量小，以是性能啥都完全OK，但在实际生产环境中，数据量一旦上去了，数据库就扛不住，导致生产环境体系可用性低落，这黑白常严峻的题目。
假如背面万兆网卡遍及的话，环境大概会有变革，但如今环境下，复杂关联查询SQL带来网络带宽斲丧以及对中心节点存储内存斲丧是必要去思量的，绝对不能由于这些导致生产环境出现变乱，以是我们前面限定非常严，存在风险的话都会限定住，让你在开辟、测试的时间就可以或许发现、杜绝风险，克制答应给你是可用的结果到末了发现不可用、线上轻易出题目，否则对我们来说，负担的风险黑白常大的。
以是我们更加方向于守旧一些，而且只管地把错误在前面开辟测试阶段发现，而不是到生产的时间才处理惩罚，固然我们也在渐渐放开一些限定，在体系层面去做好控制、确保安全。
2分布式事件
分布式事件最核心的点是非常处理惩罚。我们的分布式事件是基于两阶段提交的。做分布式体系最复杂的一个题目就是当出现网络故障、网络超时的环境时如那边理惩罚。
任何一笔网络哀求大概有三种结果：精确、失败、超时。对于超时怎么处理惩罚是最关键的，以是我们有一套测试环境，专门随机模仿各种非常，包罗网络、服务器各种环境下，用于验证我们分布式事件机制的坚固性。
第二点是分布式事件的死锁检测。我们在MySQL的锁信息内里增长上了分布式事件ID，在出现肯定超时时间后，会主动去测试整个集群内里是否有多个事件之间占用的锁构成了环，也就是死锁，一旦出现死锁，我们会根据我们的战略，Kill掉某个事件，确保别的事件正常实行。
分布式事件性能对比
分布式事件不可克制是对性能的对比，如今我们的性能是丧失大概是在30%左右，这是一个相称不错的性能了。而且TDSQL也是通过TPCC测试验证的。
两种模式
我们也提供了两个版本，一个是分布式版本，一个是No-sharding版本，如前面提到的在分布式版本里SQL会有一些限定，No-sharding提供的是完全SQL兼容的高可用方案。
TDSQL团体视图
前面也提到了MySQL和Oracle对比生态体系不敷美满，Oracle的配套工具相称美满，别的就像Oracle有很多专家，客户出了什么题目，ITPUB发个帖子说有没有专家过来帮我办理题目，就会有很多专家过来办理，在MySQL体系下还没有如许的方法行止理惩罚。
确实周边配套、内部监控的处理惩罚包罗本身的优化没有提供很好的工具，以是在这方面我们也投入了很大的精力。假如做产物化的话，这黑白常紧张的过程，无论是公有云还是私有云，如今提供给腾讯内部的别的业务也是云方式，整个这一套东西摆设进去就能实现DBaaS服务，你可以直接购买TDSQL的实例应用。
三、摆设实践
末了讲一下我们常常用的摆设实践。
1同城主从双中心
同城双中心没有什么很大的鉴戒，这是微众银行最开始的架构。微众银行是天下第一家互联网新筹民营银行，以是是从零开始建构的，最开始的时间同城只有两个数据中心，最大的题目是出了故障时相互都不知道到底是谁出了故障。
比如说网络数据中心的网络断了不知道谁出现了故障，以是同城不能主动切换，体系不知道谁出了题目，就必要人工去判定的。
但同一个数据中心内是可以做到切换的，像微众银行每个季度会做演练，由于两边都有数据中心、应用程序，以是每季度会跟羁系机构申请窗口时间，比如说5分钟把业务停掉，比及数据全部传输到备中心以后验证是不是完备可用的。通过演练的方式确保备中心是可用的。
但本年微众银行已经彻底换成同城三中心架构，任一中心都可以切换，数据的架构看起来比力简单，可用性会好很多。这确实对本钱的要求比力高，建立一个符合羁系规范的金融级数据中心本钱相称高，以是很多客户不肯意为了你再去搞多一个数据中心，只有微众是做雷同金融科技才会搞三中心的架构。
微众当时评估本钱，当它的账户量到达2000万以上时，单用户本钱可以或许到达原来传统IOE架构的非常之一左右，越到背面用户量越增长就越划得来。
2两地三中心
思量到客户当前的数据中心及本钱环境，更多的是客户会做两地三中心的架构，比如说深圳两个中心一主两备，通常在主数据中心会加一个备机，这个备机是为了做异步复制。
由于异步复制跟强同步复制本身上来说没有区别，以是异步大部分环境下数据也是最新的，假如真的主机出现故障要切换时会去优先选择本地备机，克制跨数据中心切换，假如数据确实跟别的的强同步节点最新的数据是同等的，固然没有异步节点也是没有什么题目的。
3两地四中心（主动化切换的强同步架构）
在腾讯内部通常就是这种摆设架构，根本上可以或许满意大部分客户的需求。同城三个数据中心对等，任何数据中心及故障都能40秒内切换，数据零丢失，性能也稳固可靠，以是对业务来说黑白常友爱的。
本日和各人简单交换这些，如有疑问欢迎留言探究，谢谢各人！
CopyrightYourWebSite.SomeRightsReserved.
京ICP备2023016396号-1PoweredByESCLINK.
我要评论