跨机房问题一直都是一个老大难的问题，先看传统数据库的跨机房方案。

    Master/Slave方案

    这是最常用的方案，适用于大多数需求。Master将操作日志实时地发送到Slave，Slave当成Master的一个Hot Backup。Master宕机时，服务切换到Slave，需要修改客户端逻辑使得Master失效时自动寻找新的Master。

    这个方案有一个问题就是数据库的Master和Slave一般不是强同步的，所以，切换到Slave后可能丢失宕机前的少量更新。如果将Master和Slave做成强同步的，即：所有的数据必须同时写成功Master和Slave才成功返回客户端，这样又带来了另外一个问题：Master和Slave中任何一台机器宕机都不允许写服务，可用性太差。因此，Oracle有一种折衷的模式：正常情况下Master和Slave是强同步的，当Master检测到Slave故障，比如Slave宕机或者Master与Slave之间网络不通时，Master本地写成功就返回客户端。采用这种折衷的同步模式后，一般情况下Master和Slave之间是强同步的，Master宕机后切换到Slave是安全的。当然，为了确保数据安全后，宕机的Master重启后可以和新的Master(原有的Slave)对比最后更新的操作日志，如果发现不一致可以提醒DBA手工介入，执行数据订正过程。

    Master和Slave之间强同步还有一个问题就是跨机房延时，对于关键业务，同城的机房可以部署专用光纤，在硬件层面上解决这个问题；异地的机房一般用来做备份，与主机房之间的数据同步一般是异步的，可能有秒级延时。

    Bigtable跨机房方案

    Bigtable跨机房部署两套集群，每个机房有各自的GFS存储和Bigtable Master。机房之间的数据同步方式为异步，类似Master/Slave方案。Bigtable Tablet Server将操作日志Flush到GFS成功后返回客户端，并生成异步任务将操作日志同步到备机房。这里的难点在于Tablet Server宕机时，某些操作日志还没有完成同步，因此，操作日志同步点也需要记录到GFS中，当其它Tablet Server加载宕机Tablet Server原先服务的tablet时，将继续发送没有同步完成的操作日志到备机房。如果主机房整体发生故障，比如机房停电，可以手工将服务切换到备机房，这时会丢失最后的一部分更新操作，需要人工执行订正操作。

    Bigtable跨机房方案还有一个问题，为了提高压缩率，Bigtable跨机房的同步是按列进行的，而Bigtable保证行事务，这样就可能出现某些行的部分列同步成功，部分列同步失败，破坏行事务。早期的Google App Engine底层存储为Bigtable，这个问题没有给出自动化的解决方案。

    Megastore跨机房方案(基于Paxos)

    一般来说，实际中使用的方案都是Master/Slave方案，Megastore中基于Paxos的方案理论上是目前最优的，但是实现过于复杂，只有Google在工程上做了实现。Master/Slave方案的问题在于Master宕机时切换到Slave需要时间，为了保证不会同时出现两个Master的情况，这个时间一般比较长，比如30s ~ 1分钟，而且不能做到自动化。Paxos的好处在于允许多个机房同时做Master，同时提供写服务，Paxos协议将通过Quorum-Based的策略保证达成一致。一般情况下，主机房作为Paxos协议的Leader提供写服务，当Leader发生故障时，备机房的节点可以被选为新的Leader提供写服务。即使多个机房认为自己是Leader，Paxos协议也能保证同一时刻只有一个Leader的写操作被大家同意并生效，并且做到了宕机切换的自动化。只要超过一半的机房没有出现故障，Paxos协议就能够保证不停写服务。

    Google App Engine目前依赖于Google Megastore，解决了机房宕机可能破坏行事务的问题。Amazon Dynamo也给出了一种Vector Clock的做法解决多点同时写入的问题，这是一种事后验证的做法，理论上很有意思，但由于弱一致性，实践上没有特别成功的案例。

    需要注意的是，Megastore中的复制方案在理论上很完美，但实现过于复杂，基本没有可行性。另外，无论采用怎样的跨机房同步和切换方案，都不能解决强同步写操作延时较长的问题，一般来说，这个延时将达到几十到几百毫秒。

    一种回避Paxos的切换方案

    选主一般可以通过引入开源的Zookeeper做到，不过Zookeeper本身的稳定性尚待考验，有一种回避Paxos的切换方案比较有意思。机房宕机切换自动化成本太高，但是对于很多单点服务，机房内部宕机切换的自动化很有必要。Oceanbase采用Linux的一个开源方案：Pacemaker，通过heartbeat和虚IP漂移的方式实现机房内部宕机自动切换。由于主备切换本质上是一个选主问题，理论上只有Paxos或者类似协议可以解决，而Pacemaker没有采用复杂的Paxos协议，它对硬件是有依赖的，比如要求主备节点之间通过直连线保证网络不会发生故障，而这在机房内部是可以做到的。机房之间采用前面提到的Master/Slave方案，可以写一个脚本ping主机房的Master，当确认主机房Master宕机时(比如一分钟不通)将服务切换到备机房并报警。

建议继续学习：

1. 机房介绍――中国电信八大节点城市是哪几个?    (阅读：3228)
2. 多IDC的数据分布设计(一)    (阅读：3218)
3. 多IDC的数据分布设计(二)    (阅读：2639)
4. 关于两个机房的讨论    (阅读：1793)
5. 保障IDC安全：分布式HIDS集群架构设计    (阅读：1059)