正文共3592个字，4图，预计阅读时间18分钟。mysql
笔者刚开始进入公司的时候，主要是忙于分布式MySQL系统----MyShard的构建，公司使用了大量的IDC机房，基于这种网络特色，MyShard设计当初彻底是为了是一套支持Multi-Master操做的高可用性的分布式数据库，能够在多个机房中部署的业务上提供快速的写操做，实现了分布式高可用存储能力。面试
在业务增加期，MyShard解决了公司的不少大型的数据库存储业务，随着公司业务逐渐稳定下来，分布式存储需求愈来愈少。而公司却有大量的小业务以及不断尝试的各类新业务，须要愈来愈多的小数据量的数据库存储。算法
因此这时候发现，以前的工做方向一直集中在公司的10%不到的业务上，而公司的90%以上的存储需求是MySQL的需求，目前有好上千套的MySQL在给不一样的业务提供服务。而在当时，不论是MySQL的交付仍是管理都比较原始，极端状况下，咱们须要业务申请方本身提供服务器来部署MySQL，因此交付的周期也很长。而在高可用方面，都是须要业务方本身去处理主从切换等等问题，出现主数据库故障的时候，每每须要业务方本身去修改配置文件，重启进程，增长了服务的中断时间。sql
业界比较流行的MySQL的高可用方案主要有：MMM和MHA两种，对这个方案的分析网上有不少，MHA是优先选取的方案。数据库
MHA的工做原理：编程
clipboard.png缓存
当master出现故障时，经过对比slave之间I/O线程读取master binlog的位置，选取最接近的slave作为latestslave。其它slave经过与latest slave对比生成差别中继日志。在latest slave上应用从master保存的binlog，同时将latest slave提高为master。最后在其它slave上应用相应的差别中继日志并开始重新的master开始复制。安全
在MHA实现Master故障切换过程当中，MHA Node会试图访问故障的master（经过SSH），若是能够访问（不是硬件故障，好比InnoDB数据文件损坏等），会保存二进制文件，以最大程度保证数据不丢失。MHA和半同步复制一块儿使用会大大下降数据丢失的危险。服务器
MHA的优势网络
MHA提供了一个通用的框架，咱们能够自定义判断和切换操做的步骤；并且，MHA的代码开源，咱们甚至能够进行二次开发，这都为高可用系统提供了很好的扩展 能力。
MHA的缺点
须要在各个节点间打通ssh信任，这对某些公司安全制度来讲是个挑战，由于若是某个节点被黑客攻破的话，其余节点也会跟着遭殃；自带提供的脚本还须要进一步补充完善，固然了，通常的使用仍是够用的。
虽然一个MHA Manger能够管理多个集群，可是没有大规模集群的经验。
高可用依赖于vip的方案，譬如采用keepalive来达到vip的切换，可是keepalive会限制切换的主机必须在一个网段，对于跨机房不在一个网段的服务器来讲，就没法支持了。在大规模为每一个MySQL集群安排一个vip也是难以实现的。keepalive在一个网段内，部署多套也会互相影响。
为何不采用
咱们公司的数据库的特色：
数据库多机房部署
数据库集群规模上千
安全性考虑
除了MMM和MHA以外，MySQL还能够采用代理来实现高可用，MySQL代理会比MHA方案更适合大规模的使用。
当时阿里和腾讯分别推出了rds和cdb。咱们研究了腾讯的cdb方案，cdb是基于TGW也便是NAT的模式实现了4层代理模型，来达到MySQL的高可用以及负载均衡功能。
可是TGW方案有个比较大的问题就是须要修改MySQL协议，一旦修改MySQL协议，全部的客户端（各类语言的驱动）都须要进行修改，这在推广上是很是难的。
因此咱们采用了一种折中的方案，启动了RDS项目，主要用于提供MySQL内部云服务，其中高可用方案以下图所示，采用了iptables的NAT来实现MySQL的代理路由功能。
clipboard.png
4层代理层基本实现原理
业务方首先链接到代理服务器上，因为代理服务器上有NAT目标地址转换规则，因此会转到目标MySQL主机上，同时从MySQL主机回包到代理服务器后，因为有NAT源地址转换规则，又会转发回业务方，从而实现了代理功能。
下面举例说明咱们如何为一个业务启动RDS四层代理：
咱们先准备好如下几台机器：
客户端：172.26.14.16
代理 ：172.26.82.45 启动业务代理端口20000
目标机器：172.26.82.7 部署MySQL 端口号为3306
在代理机器上设置规则：
一、打开forward
echo 1 > /proc/sys/net/ipv4/ip_forward
二、设置从客户端请求的目标地址和原地址转换规则
iptables -t nat -A PREROUTING -p tcp -s 172.26.14.16 --dport 3306 -j DNAT --to-destination 172.26.82.7:20000
iptables -t nat -A POSTROUTING -p tcp -d 172.26.82.7 --dport 20000 -j SNAT --to-source 172.26.82.45
三、设置好规则以后，就能够经过mysql来链接到代理的20000端口了。
mysql -utest -ptest -h172.26.82.45 -P20000
这时候，实际访问的是172.26.82.7上3306端口的MySQL数据库。
笔者以前一直都在公司云存储中心工做，因为种种缘由，2015年年中调到了运维部的数据库团队，在这里才发现，rds项目其实只是在数据库运维平台中走出了很小的一步。为了提供全方位的数据库云服务平台，因而咱们开始打造了全新的数据库配置中心，同时提供MySQL、Redis、Mongodb等数据库和缓存内部云服务。
与此同时，以前在rds项目中实现的4层代理的缺点也愈来愈明显：
只能使用MySQL主库，M-M-S结构是的MySQL资源极其浪费；
只能在单机房使用，跨机房访问效率很是低；
运维功能太少，因为采用iptables，在代理机器上没法看到任何的链接信息，也没法捕获任何业务访问的指标，甚至于链接信息都没法获取；
基于以上几点缘由，笔者决定开发基于7层应用层的MySQL代理层平台，系统的具体架构以下所示：
clipboard.png
因为代理层是本身实现的应用程序，因此笔者在代码中很容易就实现如下几个核心的功能：
受权认证模型；
SQL拦截；
负载均衡；
读写分离；
高可用；
大SQL隔离；
除了这些特性之外，基于咱们公司的多机房特色，笔者给代理层添加了机房感知能力。在整个数据库配置中心，每一个代理层程序、每一个MySQL实例都有机房属性。有了机房属性，代理层能够实现自动就近访问MySQL的能力，从而提升了系统性能同时，简化了业务程序的部署。
一个典型的业务部署例子以下：
clipboard.png
从上图能够看出，应用程序永远也再也不须要考虑多机房高可用、负载均衡、读写分离的问题。并且因为代理层实现了高可用功能，一旦发现主写MySQL故障，会自动把主读切换为主写，从而在秒级实现FAILOVER。
平台级设计
因为咱们的代理层采用了平台级的设计，上图中的代理层能够链接多套业务（MySQL集群），新的业务只须要在zookeeper配置好，代理层就会自动感知，业务方立刻可以在代理层上使用，而不须要为每一个业务部署本身的独立的代理层，从而极大的减小了运维成本。
除此之外采用代理层还为数据库云服务平台带来很多好处：
业务方链接代理机器和相应的端口，底层MySQL主从切换能够对业务方透明；
MySQL实例维护或者迁移能够对业务方透明（一键迁移）；
MySQL业务扩容/缩容也对业务透明（一键扩缩容）；
代理层上线推广到如今，已经有好几百套的MySQL集群跑在上面了，MySQL的高可用平台成功落地。
Mongodb相对于MySQL的一个很大的优点就是高可用性，MySQL的高可用方案不少，可是完美的方式很少，代理层是在咱们公司成功实施的一套平台，但愿有机会能和业界一块儿探讨和学习，实现更多完美的解决方案。
代理层虽然已经在公司大规模使用，可是还有不少发展和改善的空间，随着MySQL 5.6和MySQL 5.7的普遍应用，GTID已经很是成熟，因为公司内部使用场景少，代理层的切换尚未实现GTID模式的切换，因此下一阶段，笔者会考虑实现基于GTID的高可用模式。
原文连接：https://www.jianshu.com/p/d32fade628c1
查阅更为简洁方便的分类文章以及最新的课程、产品信息，请移步至全新呈现的“LeadAI学院官网”：
www.leadai.org
请关注人工智能LeadAI公众号，查看更多专业文章
你们都在看