异地多活(异地双活)实践经验

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/JeffreyNicole/article/details/48135093
异地多活(异地双活)是最近业界讨论比较多的话题,特别是前一阵子支付宝机房光纤故障和携程网数据库丢失之后,更加唤起了技术人员们对异地容灾的考虑。


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


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


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


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


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


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


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


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


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


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


9 控制跨机房消息体大小,越小越好;


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

没有更多推荐了,返回首页