异地多活（异地双活）实践经验

异地多活（异地双活）是最近业界讨论比较多的话题，特别是前一阵子支付宝机房光纤故障和携程网数据库丢失之后，更加唤起了技术人员们对异地容灾的考虑。


而异地多活比异地容灾更高一级，因为异地容灾仅仅是一个冷备的概念，而异地多活却是指有两个或者多个可以同时对外服务的节点，任意一个点挂了，也可以迅速切换到其他节点对外服务，节点之间的数据做到准实时同步。


网上看了很多技术分享，总结了以下实践经验：


1 如果业务量不大，没必要做异地多活，因为异地多活需要的运维资源成本、开发成本都非常高；


2 注意机房间的延时问题，延时大的可能达到100ms以上，如果业务需要多次跨机房请求应用的话，延迟的问题会彻底放大；


3 跨机房的专线很大概率会出问题，要做好运维或者程序层面的容错；


4 不能依赖MySQL双写，必须有适应自身业务的跨机房消息同步方案；


5 MySQL或者其他存储的数据同步问题，在高延时和较差的网络质量的情况下，考虑如何保证同步质量；


6 核心业务和次要业务需要分而治之，异地多活的业务形式越简单越好，甚至可以只做核心业务；


7 异地多活的监控、部署、测试等流程也要跟上；


8 在业务允许的情况下，考虑用户分区，特别是游戏、邮箱业务比较容易做到；


9 控制跨机房消息体大小，越小越好；


10 考虑使用docker等容器虚拟化技术，提高动态调度能力；