当时我们做跨地域部署的时候，其实是没有做到完全的异地多活的。
入口方面通过dns就近将流量转往Slave机房，S只提供读服务
前端接入层将写流量转回Master机房
主库部署在M，通过MySQL主从同步将数据同步至S
这个方案的缺点是，主机房故障之后没地方切。
如果机房故障，可以快速切到另外一个机房，需要保障多机房的数据是一致的。
保障数据一致性的方案，
- 数据双向/多向同步
- 业务方双份/多份写
这里的数据包括MySQL中存储的关系型数据、MFS/NFS上存储的业务数据、缓存数据、消息等。
业务方多份写肯定不现实，平均响应时间受不了的。
数据多向同步需要保证同一时刻只在一个地方写，不然没法解决冲突。在数据同步方面还有两种场景，
- 用户一个时刻只在同一个地方写，但多个时刻可能写在不同地方，冲突后以最后一次写入为正确值。在分布式系统遇到的挑战是服务器时钟的完全精确性。这个基本是做不到的，线上的服务器是每半小时去ntp服务器同步一次时钟，期间会有毫秒~秒之间的误差，在这样的背景下，基本没法解决冲突的问题。
- 用户平时只一个地方写（路由规则），只有当故障的时候，触发路由规则的修改，将用户的请求切到其他机房。技术点
- 业务上需要设置路由规则，并且路由规则需要经常变化。我们一般的路由规则肯定是就近访问，但用户的地理位置是可能发生变化的。如果客户在S访问过，之后来M城市定居，我们的路由规则需要感知到这种场景，并把用户的流量转到北京。
- 由于故障时还是需要切流量，所以多机房之间还是需要做数据同步的。在数据同步延迟期间，发生故障，切流量，可能存在脏数据的问题。
做核心系统的跨机房部署，不仅你的系统需要多地域部署，你依赖的复杂的关联系统都需要做多机房部署，并且都需要解决上述的路由问题和数据同步问题。所以只是你的模块跨地域部署难度是N，那将核心系统跨地域部署，难度是N*M。
除了技术方面的难点，还需要推动和协调多个部门进行部署、测试、验证，并且会增加运维的复杂度。要协调多个部门做这样一个费力不讨好的事情，一定要有一个非常明确/大的业务收益。
