资深架构师、技术创业家。两者共同的特点是“够牛X”。正因此，很多奋战在第一线的程序师们会将他们定位为自己的目标，并期望可以向他们学习、取经。针对这个广泛存在的诉求，一场别开生面的京、广、杭三城“ 极客 & 创客大宴 ”悄然展开—— 9 月 19 日，又拍云 Open Talk 同时登陆北京、广州、杭州，一场三地联办的大型技术主题沙龙拉开帷幕。

这场名为“技术的三城形态”的实战分享会力邀了新浪、七乐康、河狸家、海蜜、贝贝网、图普科技、甘果移动、爱拍、淘粉吧的技术负责人、企业掌门人“压阵”，好东西自不会少。慕名而来的三地开发者们聆听了一场干货满满的技术与创业讲堂。杭州活动的主题为《实效的技术架构与开发模式》，海蜜 CTO 魏建 Tim 在活动上做了题为《MySQL高可用方案的技术选型 》。

大家好！很高兴和大家分享，感谢又拍云提供这么好的平台，分享交流经验，还可以结识朋友。今天主题是《 MySQL高可用方案的技术选型 》。

首先，数据库依然是电子商务系统的核心之一，虽然前几年 Key-Value 数据库的崛起，甚至一度有代替关系云数据库的言论。但目前来看，Key-Value 数据库和关系数据库，依然在各自的领域里发挥着作用。在我看来，他们依然是相辅相成的关系。

第二，因为海蜜全球购是跨境电商，和平时做的电子商务不一样，它面向的群体是全球的客户，就会碰到一些问题。海蜜是帮助我们发现一些有趣的海外商品，我们的买手在海外，绝大部分是海外留学生，他们在海外学习、生活的过程中会经常去奥特莱斯或超市，当他们发现一些好的商品，可以通过 APP 把这个商品拍下来。买家在国内，可以在海蜜上发现这些有趣的商品，当然也可以在 APP 里面促成交易。最后，在海蜜上可以进行分享和发现，留学生不仅在我们的平台上发布商品，也可以分享他在国外的一些生活和学习经历。

这是我们的买手分布图。遍布全球，美国、日本。除了绿色的区域，我也好奇为什么那个地方没有一个买手？因为那个地方叫格兰林岛，这么大的地方只有五万多人。从这张图可以看到，如果数据中心只建立在中国的话就会碰到一个问题，访问速度会很慢，因为虽然有的地区的买手很少，只有几十个或者几个，但每个地区都会有买手。

数据库的方案选择

根据这个情况，我们设计了第一套方案，第一套方案是初期的方案。当时，我们主要开拓的是美国的买手，设计的方案就是中国和美国各建立一个数据库的主从集群，为什么这样做？就是让美国买手访问我们的 APP 时，可以在美国访问本国的数据库，不需要回到中国来。

第二个做了主主复制，因为我们允许大部分操作直接在美国进行。但事物的操作必须回到同一个数据库上，保持数据库的唯一性。打个比方，如果一个订单，当用户付款之后，买家和买手同时操作，那么就会出现问题，不知道数据会变成什么样，比方说一个订单，买家付完款，买手可以把状况更改为“已发货”，而买家可以撤销订单，因为复制有延时，两边都可以更改成功，像这样的危险操作必须要回到国内的数据库。

这套数据库方案的优点是提高了国外大部分 CRUD 的速度，但它的缺点也很严重：第一，它的复制有延时，因为美国和中国数据库距离很远，我们并没有专线，走的是公网，复制的延时，随着用户量的增长会越来越大。第二，事物操作慢，虽然大部分在国内进行，但少部分必须回到国外的数据库，这样会造成用户的体验差。

这套方案上线之后，我们就开始调研下一套方案，因为这套方案时间很紧，上去之后紧接着业务就要开展了，技术要开始调研下一套方案的可行性。我们首先调研的是云计算方案，为什么要了解云计算呢？其实，我们一直很关注云计算，云计算内部很多繁琐工作，我们是一个创业型的项目，并没有很强力的运维，云计算绝对是上上之选。举一个很简单的例子，如果做云存储，图片存储，自己做需要做很多事情，要采购机器，要配置软硬件环境，开发系统，还要选择 IDC，也不可能放在一台机器上，要组成高可用，还要做异地灾备，要花费很多时间、精力和资金。

如果我们选择云计算的方案，比如说选择又拍云就很简单了，只要注册一下，使用他们的 SDK 或者是 API，只要把图片传上去，它给返回一个图片路径就可以直接使用，不需要考虑内部问题，只要按照流量付费就可以了。

当时我们调研的是 AWS 的方案，我们和 AWS 的技术曾经沟通过几次，他们也到我们公司，和我们一起调研项目的可行性。

首先，它在全球有十几个数据中心，数据中心里面有很多可用区，每个可用区是机房。可用区与可用区之间是有连接的，数据中心和数据中心有连接，可以把它想象成很大的内网。它有分布式的数据库系统，因为它是内网传输，所以复制速度非常快。

第二，可以在其中一个中心建立一个数据库，在其他的数据中心可以建立只读数据库，当用户访问的时候，通过他们的技术可以分辨出距离哪个数据中心比较近，如果只是读取的话，只要取数据就可以了。如果需要读写数据库，只需要网络到我这个数据库里面。

第三，高可靠性和高扩展性。因为他们的数据库，高可用不仅仅是通过主从复制的简单技术实现，他们机房与机房之间也有高可用，但就是这么厉害的产品，这么庞大的功能，最后我们还是没有选择他们，原因有两点，但这些都不是他们的原因：第一，他们在中国区是信息孤岛，刚才说他们的信息中心与信息中心有专线相连，但中国没有，因为他们要遵守中国的法律；第二，备案问题，他们有全国的资质，但却没有 ICP 增值业务许可证的资质，正是因为这一点我们彻底的放弃了。

接下来考虑的是阿里云。阿里云应该是国内云计算的翘楚。首先，它是一家中国的公司，备案非常方便，只要是中国的阿里云都可以备案，我从来没有见过其他的 IDC 可以做到这一点。第二，它是杭州唯一的 BGP 机房，我联系过杭州所有的机房，只有他们是 BGP 机房，带宽方面是质量比较好的。

它的带宽好到什么程度呢？上次我们公司在塞班举办了一个会议，当时我们的网站凡是存在IDC都打不开，凡是在阿里云都可以打开。但它也有缺点，目前还是发展期，发展很快，有时候用的过程中会在更新，碰到一些以前没有碰到的情况。其次，它费用比较贵，而且是线性增长。

通过比较这两个云计算的公司之后，我们就思考，是不是真的需要海外数据节点。海外数据节点如果没有专线的话，达不到这种带宽速度和质量。而且当时我们已经发展了一段时间，我们的买手不仅仅局限于美国，覆盖了很多地方，比如欧洲、东南亚、日本，我不太可能做到在每个地方建一个数据中心，造成我们的运维压力很大。但时间不等人，每次开会的时候，商务部门经常抱怨，好不容易拉过来的买手，因为 APP 速度太慢就流失了。

当时所有的技术都在找怎么才能解决这个问题，后来徐总让我们去看看 AKman 这家公司，它是一家印度的公司，费用非常贵，一年要四十万左右。它主营动态CDN加速，如果源站没有，他们的 CDN 案例会缓存一次到 BIM 节点，下次就不需要回到源站了。动态 CDN 也是一样，通过网络减少和源站之间的距离。

我们当时做了测试，这家公司的速度快到什么样子呢？如果从美国访问海蜜的源站，美国的服务器，每秒可以到 300K 到 400K 速度，如果使用他们的线路每秒可以达到 1.5M，甚至更高。当时测试过程觉得很惊讶，怎么可以做到这么高，但他们可以做到，他们号称全球三分之一的流量都经过他们，而且他们在全球有 150 多个节点，号称覆盖了全球的 CDN 节点，除了中国，因为它没有中国的资质。

重新制定方案

有了这个 CDN 网络之后，又回到我们的熟悉领域，如果有了 CDN 网络，可以把所有的数据中心放在中国，因为没有外部的网络环境了。我们很快从一堆方案里选择了两个比较，首先是官方的 MySQL cluster 方案，还有一个是日本专家写的 MHA 的工具。

首先看一下 MySQL cluster 官方的集群方案。它的优点：第一，没有单点故障；第二，扩展性很强，它的 score 和 data 节点都可以横向扩展，可以根据访问量在线扩容；第三，官方数据性能强劲，当时时间有限，我们没有真正测过它的性能和扩展性、可靠性。

没有测试的原因就是下面要讲的：第一，它缺少中大型项目的实践，我很少在国内技术群体里面发现有公司真正实践，应该也有，只是分享出来会比较少，没有分享，我们不敢做第一个吃螃蟹的人，因为电子商务的网站，出现问题，没有办法解决，会有很大的压力。第二，文档少，学习成本高，这个学习成本包括人力、时间。基于这两方面的考虑，我们没有采纳。但还是希望接下来可以研究一下，到实践当中去看一看这套方案是否真的能满足高可用的要求。

MHA 这套方案其实是一套工具，它的优点很多，重要的优点它是非侵入式的框架，可以按照现在的组成，不会动它们，只是在外面加了 MHA 这套工具做高可用的处理。

首先它的优点是 Master，当 Master 出现故障时，可以手动或自动进行转移。第二，切换时不会造成主从不一致，这一点我们在测试环境测试了很多次。我们用了三台服务器，一主两从，有一台服务器不停的写数据库，写的过程是首先开启一套事物，插入一条数据，然后+1，再写一条数据，这是一个死循环，一直在执行。

执行过程中，首先把主库网线拔掉，MHA 检测到主库无法响应的时候，自动切换到其中一个从库上来，接下来我们看数据库的数据，的确数据库的数据是一致的。然后我们又做了一个测试，还是刚才这种测试环境，手动执行切换，同样也保持数据的一致性。当切换完成之后，MHA 可以执行自己写的脚本，这个脚本可以更改程序上的一些 pet 文件，程序可以直接写到新的 Master，不会写到有故障的 Master 上。它的切换的速度非常快，1 分钟就可以切换完成。最后它是非侵入式框架，对线上环境没有任何影响。

它也有缺点：首先，配置环节非常繁琐；第二，需要打通各个主机的 SSH 免密登陆。这个实际中用了两次，有一次机房说要停机备份两小时，我们做了异地灾备，手动做了一次主库切换，虽然已经做了很多次，但现场执行的时候还是第一次，执行的时候心惊胆战，但还好顺利完成了。第二次是主库的数据库突然宕机了，当我们还没有发现的时候，MHA 自动帮我们主库切换走了。对我们的应用来说，基本上没有太多感知。

我们现阶段的方案是这样做的：首先，国内外都使用动态 CDN 加速；第二，我们做了异地灾备，在两个机房里各做了一个完整的环境，万一其中一个机房出现故障的时候，整个业务不会停止；第三，MHA 做了复制监测，它会每隔一分钟监测复制是不是正常，如果有延迟或者中端，或者有异常，都会发报警信息给我们；第四，故障手动和自动的切换。

海蜜现在的架构基本上就是这样子，谢谢！

又拍云 Open Talk 是由又拍云发起的系列主题分享沙龙。秉承又拍云帮助企业提升发展速度的初衷，又拍云 Open Talk 将用全干货的形态，为互联网从业人员呈现以技术为主，同时涵盖产品、营销、融资等各个方面的专业知识，帮助企业成员不断的提升自身专业技能，以推动企业更快的发展。