MySQL高可用

白凡

分享：莫晓东
编辑：白凡

讲师介绍：我来自腾讯的莫晓东，我跟大家分享MySQL的高可用。我在2010年入职腾讯，负责MIG的相关工作，2014年底负责MySQL的数据架构和维护。

分享大纲：

• 为什么是MySQL
• 高可用和一致性
• 分布式数据库
• 鹅厂的MySQL集群
• 平台化和云

1. 为什么是MySQL

为什么从MySQL开始？数据库有那么多种种类，为什么腾讯会选用MySQL这个数据库以及我们金融级的服务，像微信支付每天从外部的报表可以看到，每天都是上百亿的资金，这些资金的订单全部都是存在MySQL里面。
MySQL的优势主要是开源免费、快速、健壮、易用，其实在90年代以前，数据库是商业公司的天下，一直到90年代MySQL发布，MySQL发布以后，在数据库领域才出现了关系数据库。最开始只是用于互联网公司，因为一般的话商业数据库的成本非常高，一般商业数据库价格用CPU或者是用户数来说，互联网的话单用户量就非常大，一般公司没有办法承受。

MySQL就是在这个关键时间点就发布了产品，赶上了2000年开始的互联网大潮。当然当时有其他的数据库。但是MySQL始终比较活跃，后来就出现了影响比较大的主从结构的复制，这个对于硬件以及一般的服务器不行，就算小型的内容。MySQL组成结构以后就组成了很经典的结构。就可以读写分离，有实现了初步分布式的架构。所以它就赶上了一个完美的时间点，他引入了最早的用户，用户又给他带来数据的体验，这样就拉开了和库存力的价值。

所以一直到现在，其实这个已经很稳定了。但是一些功能和MySQL相差不大，所以我们选型的话，我们首先要考虑成本，成本商来说MySQL对我们最有价值，其次是MySQL的代码，因为MySQL的原型从80年代就已经出现了，90年代的成熟，相比现在的数据库来说，它的历史也比较久，它的代码开源，我们可以审核它的代码，知道它有没有漏洞。基于这个原因我们选用了MySQL，很多公司选用MySQL也是这个理由。
2000年开始阿里巴巴最开始引入MySQL，后来他们潜入RLK，2010年去IOE，也是阿里巴巴提出的，业务支撑有限，因为在这之前一直都是在机器人SGP的扩容，就是单级对硬件的扩容不停的走地另外还迎来了2017年闭源的环境。高可用和一致性。如果你在更早的商业数据库来说，我们交钱，然后从商业数据库公司得到服务这样高可用和一致性不用我们自己考虑。如果我们自己做的话，选择MySQL就是为了开源。

2. 高可用和一致性

什么是高可用？高可用首先要保证业务最终一致性。cap和base都知道，允许丢失和对帐、异步达成。金融业务的特征是事物一致性高，oltp和acid，可靠性高。

大规模系统的问题就是单台设备故障导致整体不可用。服务关联性，互相影响故障扩散。基本可用Base，针对基本数据库的合理和拆分。

MySQL的单组高可用架构。最早就是为单机MySQL，就是以单机模型开始，然后MySQL增加一个或者是多个从机，实现容灾和读写分离，但是这种读写分离同步延时不可控，可能接受延时的场景，然后在这个基础上，人工操作，主机岩机后需要修改客户端配置。例如LVS+keepalived+MySQL、DRBD+heartbeat+MySQL，或者是网络存储，对hang住和网络异常的判断，脑裂。不必要的复杂度，已经不推荐使用了。MMM是Google的M-M failover方案，给主从模式增加监控、故障转移和管理的脚本套。不活跃。MHA是DeNA的更完善failover套件，支持VIP或者是Conf。国内大量基于MHA的改写方案，建议使用MHA搭建初期的MySQL高可用架构。Gelara是percona发布5年的成熟技术，多主强同步，性能较为稳定。MGR是Mysql在gelara启发研发的Paxos多主协议，性能较高，MySQL5.7以上支持。关注MGR，短期商用需要谨慎。这个是单机变成多机的统一数据库的架构。这就是现在的四个阶段。

在这个过程当中MySQL最大的技术就是复制技术的进步。复制是MySQL创造出来的模式里面最有用的。特别是主从复制、半同步复制、多线程复制、组提交、GTID五，增强多线程复制、改进半同步、组复制（MGR），Binlog格式、Row和Statement、Mixed，推荐MySQL5.7Semi-sync+row+read-committed。就是说在这个情况下MySQL是有可能执行成功的半成功的增强。这个Binlon-fomat=row，我们认为这个读体胶是更好的方式。这个是典型的半同步的机制。

3. 分布式数据库

如果实现了MySQL的单级数据的高可用以后就涉及到读级，前面始终是单级到多级的孵化。一般像我们互联网是使用分布式分标的方式。

以某一个K来进行切分，有两类，水平拆分和垂直拆分。按行分割，每个字表的结构相同。微信我们最早是存在MySQL里面，后来我们将图片那些分布到专业的存储，证书可以文件存储，昵称或者是留言或者是其他的用户属性可以用range，我们一般现在比较流行的就是针对某一个主件进行取模的东西。

路由工具数据库中间件一开始是MySQLProxy、Maxscale阿里是出现了amoeba、Cobar、MyCAT、360 atlas。套件ddb、tdsql、HotDB、radonDB等。通过中间的Proxy路由SQL到不同目标的MySQL，客户端路由阿里TDDL。MySQL Fabric。通过一个Proxy访问读组，就是一组的高可用然后再实现中间件，通过中间件来影射不同的表。也用了一个Proxy中间件，中间件也是流量的瓶颈，所以在这个基础上，就把这个分标规则集成在客户端。我们微信支付也是客户端的方式，微信支付把所有的分表规则集成在客户端，这样就需要比较强的开发能力。当然这中间也有一些取巧的办法。

业务降级和限流。我们对于实现这种高可用的有三种规则，有损服务、柔性可用、大系统小做。我们一般在业务的拆分规则上，只有核心业务，业务必须在控制下运行，万无一失，用户重试，我们有会把额外的资源拆分出来。以抢红包为例，抢红包首先假设是几千人去抢，用到数据会进行排序，有序落到数据库。像一些其他的功能会被拆分到不同的存储里面。这也是作为高可用在实现了数据库的高可用然后再做业务的核心。实现数据库高可用在单机到多机到流控以后进一步来做异地多活。

这里以红包作为例子，红包就根据用户的属性来拆分不同的IDC，就可以在执行的基础上进一步拆分。这样有两个好处，一个是耗时比较短，如果一个IDC出现问题，另外一个IDC可以继续提供服务。
我们微信支付现在一般以南北分布式设计，就是南方一个中心，北方一个中心，南方中心里面，比如说以深圳为例，就有多个机房，多个机房的数据是全链互相备份的，整个南方如果出现损失，在一部分恢复到北方，类似这样来实现。更进一步这样的高可用。因为南北同步，如果是跨城同步延迟太长，这是一个比较麻烦的事情。

4. 腾讯的MySQL集群

其实高可用这个事情从移动互联网开始发展，一直是比较重要的事情。一个是MySQL提供的主存机制，另外一个就是之2003年左右的GFS论文发布。再之后就是2007年，就是Dmk的论文发布，然后Google又发布了一个Spanner、F1论文引发了NewSQL，国内有TiDB、oceanbase；腾讯内部也有多个团队预研。因为从M-M到GCS、CDB、TDSQL、Galera，就是单组的多谢也是向NewSQL方向转变。这些方案如果大家使用腾讯云，一般推荐大家使用CDB，因为CDB有一个MySQL的改版，给大家有一个路由控制，非常简单。当然阿里云也有类似的措施。到最后是使用了真正的存储层和数据存分离，我们以前都是以MySQLProxy，然后用PD层调动资源，其实PD层就是类似于Google的GFS开源percona一样，就是以它来拆分一个一个的块进行扭转，这样就可以实现非常频繁的动态的扩容和缩容。

不管短期内我们可以研究，但是不能用在生产环节下。按照我的测试，THB一般使用环境下的耗时稳定性比MySQL差很多。目前来说CBD是比较好的方式。以微信红包为例，我们实现了一个单独的高可用是没有使用MCH的改版，每个特定端口都会指向主机，以Proxy为核心的模型的话，因为它不存在一个Proxy流量节点，单组数据里面就实现了客户端随便访问一组三从或者是一组两从的例子。

微信红包高可用。逻辑层控制水平分组、垂直拆分。冷热拆分，流量控制，串行化无分布式事务。单组自动分层屏蔽。微信支付的数据层分布式结合业务逻辑实现，这里就会有新个一层出来。

5. 平台化和云

下一步是平台化，平台化的代表就是云。我们腾讯内部不同部门之间技术站是独立的。我们内部没有使用腾讯云，但是我们还是向云来进化。其实我们自己实现了一个私有云，有运维团队开发的一系列也可以说是工具，把这些工具包装起来开发只是解渴，实现了一个数据库私有云。

我们这一步是云和工具的建设，从标准化开始到脚本，脚本之后再到流程，流程自动运行起来，接下来我们现在做的就是AI，会根据一些条件自动进行新的处理。要实现这个，用我们的经验CMDB是核心，在CMDB上可以做监控采集，监控采集可以做自动分析。依赖CMDB可以实现自助流程，自助流程就是像提供扩容这方面的需求或者是一些审核授权，最后到部署回收。然后在CMDB屋里面继续做安全控制和高可用。就是一般公司从传统运维到公有云，最后回到私有云。因为公有云只是取大家业务设施的交集。因为一般的情况下可以使用传统的方式，之后使用公有云。

数据库云服务，这个是从HotDB的界面截取的，公有云我推荐大家选择腾讯云或者是阿里云都可以，因为他们的区分很小，腾讯云的数据库产品有TDSQL和CDB，相对来说比较阿里云更好用。

私有云推荐HotDB，国内最专业的MySQL也还不错。之前找HotDB要了一个他们切换思路，大家可以看一下。一般的话就是Proxy比较成熟的，HotDB内置分片和自动容灾。具有低学习成本，系统成熟。第二点是使用透明，99%兼容MySQL。性能强悍，就会在Proxy实现一些功能。未来肯定是以NewSQL为主。现在是NewSQL的几十倍甚至是更高。如果大家用过以前老的Hbase应该有感觉，对于单机能力开发得非常厉害的关系数据库还是差的很远。

这里可以看到，如果一组关了以后就Proxy就会入组到另外一组。从单机一直到实现一个数据库私有云，私有云大家可以参考一下现在的例子。如果大家开发能力比较强的话，一般还是推荐大家像微信一样，直接把路由规则埋到客户端，这样灵活性相对于Proxy来说就会比较低一点，我们之前用过Proxy的方式，因为都到这一层的话，相对来说性能和维护商来说稍微差一点。

但是在初期，可以使用Proxy和使用单机数据库迁移，很多场景下是一样的，在初期可以省掉一部分开发工作。所以单机到一组多重再到使用公有云上的产品，到最后，就使用以客户端集成路由规则来用，这是我觉得比较合理的即时路径。