再牛逼的架构也敌不过挖掘机，无论单机房内你的架构多么的高可用，多么的完善，当挖掘机挖下去那一瞬间，都是扯蛋，楼主所在的公司也被挖掘机挖断过光纤、电力线。

为什么大家都在谈论服务冗余，缓存击穿等高可用时，很少人谈到数据库的高可用呢？这是因为数据库是有状态的。服务可以部署到多个机房，并且同时提供服务，但是数据库却只能有一个机房做主服务，如果多机房，每个机房都有自己的主服务，那么多主同时写造成的数据冲突，同步问题所耗费的人力，物力将会得不偿失，而单主带来的问题是: mysql5.6/mysql5.5的同步模板是after-commit，也就是主服务器会保证主上binlog已经落盘，并且异步发送给slave，这个时候用户已经在主服务器上能看到提交的事务，假如此时出现网络问题，另外一个机房的slave变成主时，用户会发现刚才做的操作都回滚了，也就是事务不见了。

为了解决这个问题，mysql5.7引入了after-sync模式，这个模式下，master必须等待salve已经把binlog落盘，才会把事务提交到存储层，并且返回给客户端成功。

这个时候我们可以在同城搭建三个机房A、B、C，其中A、B机房做为冗余部署，服务，数据库都各部署一套，而C机房只部署数据库，做为数据库的日志机房。我们开启Mysql的半同步模式after-sync, 这个时候他可以保证在返回给客户端事务提交成功时，日志肯定已经同步给B、C中的任意机房，当某一天A的断电的时候，这个时候，我们只需要DBA对比B、C的日志文件，如果发现B比C多，那么直接把B做为主，C做为备，将所有流量切到B机房即可；如果发现C机房日志比B机房多，这种情况发生在，断电的瞬间，A和B之间的网络先断开，部分事务成功发送到C，这个时候，由DBA手动将C多出的日志同步到B，再开启B做为主服务，所有流量切到B机房，这个操作可以在半小时内完成。虽然此架构不能保证A断电的情况，B能立即提供服务，但是这个方案能保证不丢失数据，并且能在极短的时间内恢复。

架构图如下：

多机房架构图