如何设计云端数据库？四大测试助你玩转AWS RDS！（二）

在传统的数据库读写分流模式中，我们通常会在应用层的配置上实现读写分流，通过代码让写流量集中放到Master数据库上处理，然后通过MySQL-Proxy之类的代理服务器对只读流量做负载均衡，实现一主多从的读写分流。当然在AWS上也能直接采用这种经典的模式，或者通过ELB弹性负载均衡在实际测试中也是可行的。

下面是传统的MySQL-Proxy模式架构图，其中采用keepalived来解决MySQL-Proxy的单点故障问题，实现整体架构上的高可用。

EC2_MySQL

如果我们直接采用EC2_MySQL的方式在AWS云端部署数据库。这套方案完全是可以直接copy到AWS云上去实现的。不过需要注意一点的是，在AWS云中，IP是绑定在ENI上的。如果要实现VIP的自动迁移，我们这边通过最佳实践得出的办法是通过断臂的模式，也就是当我们监听到服务器停止提供服务的时候，通过脚本自动去调用API的方式，把带有该IP的虚拟接口卸载并关联到备用的机器上，从而实现VIP的自动迁移。

附上实现脚本：

这个办法存在两个比较大的弊端，一是客户能感知到服务中断，二是在AWS云上，虚拟接口是无法跨AZ去使用的，这意味着要两台代理服务器都需要部署在同一个AZ上，也意味着要稍微牺牲掉一定的高可用性。

下面是我们的测试结果，数据库服务中断时间为2分18秒

当然我们也可以采用ELB来代替MySQL-Proxy实现只读流量的负载均衡。

AWS上的Classic 负载均衡器，可以实现七层应用的负载均衡。所以我们只需要创建一个Classic 负载均衡器，设置侦听MySQL的3306端口，并关联相关的EC2_MySQL从库，便能轻松实现只读流量的负载均衡。而且ELB有面向公网和面向内网的两种模式，当选择面向内网的模式时，ELB提供的DNS中只含有相关网段中的实例IP解析，并且只允许同个VPC内的实例访问，从而保证数据库的安全性。

RDS_MySQL

AWS提供的RDS服务不仅可以让你快速的部署和管理MySQL或者其他的关系型数据库外，还提供只读副本的功能。只需要右键点击主数据库便能十分轻松的创建只读从库。只读副本不仅能用来分担主库的读压力，而且在当主数据库宕机之后，只读副本会自动被提升为主数据库，从而保证主数据的高可用性。

不过因为RDS_MySQL只是做了MySQL的托管，没有开发中间件，再加上MySQL本身无法实现只读分流，所以现RDS提供的只读副本也是无法实现自动只读分流的。再加上ELB无法直接关联上RDS的只读副本。所以如果需要对RDS_MySQL做只读分流，只能采用上述传统的方法，通过MySQL-Proxy代理的方式来实现。但是这就不得不去面对MySQL-Proxy单点故障后VIP自动迁移的问题。

为了防止服务中断对客户体验的影响，我们采用了ELB+MySQL-Proxy+RDS_MySQL的模式，让ELB去侦听MySQL-Proxy，保证MySQL-Proxy的高可用性，但是多了一层代理之后，对服务的性能会不会造成影响。针对这个疑问，我们也做了一次相关的测试。

跟之间的测试一样，这次我们同样采用了Sysbench对数据库进行压力压测。

在MySQL-Proxy前面添加ELB后，我们能通过ELB提供的A记录直接访问我们的RDS数据库。

直接对MySQL-Proxy进行压测，代码如下：

期间我们可以观察到，所有数据库的状态都由unknown转换为up，这意味着只读分流已经实现。

整个压测过程耗时为18秒

采用同样的线程数与数据表大小对ELB进行压测：

整个过程耗时29秒。

由数据不难看出，采用ELB+MySQL-Proxy+RDS_MySQL的模式，虽然很大程度上提高了整体架构的高可用性，但是对于整体架构的处理性能，因为多加了一次TCP，所以难免会有些影响。

当然还有一种折中的办法，就是漂移DNS 记录法。具体怎么操作，在这里不做详细介绍，有兴趣可自行了解。

在整体架构设计的灵活性上，EC2_MySQL的方式要比RDS_MySQL更胜一筹，但是在主从数据库的构建，与数据的同步上，RDS_MySQL会更加简单与更便于管理。但是出于性能考虑，感觉在只读分流的实现上，我更倾向于使用EC2_MySQL的部署方式。