异地多活设计有哪些常见的难点和技巧？

业务的可用性对用户的体验至关重要，如果业务经常动不动就不可用，再好的业务都会没人用，异地多活正是保障业务即使在各种极端异常情况下都可用的利器，例如机房断电、地震、城市水灾、蓝翔挖掘机挖断光纤等。
异地多活虽然听起来很美好，但在设计上却有很多的挑战，很多人都会觉得“异地多活”的方案设计很难，业务、网络、数据、事务等各种问题混杂在一起，很多问题看似是无法解决的。比如说：“网络断了怎么保证数据一致性”、“怎么保证异地事务一致性”、“业务怎么无缝的在多个地点切换”。。。。。。等等。
[/url]


你的业务是否也有类似的异地多活的需求和困惑？如何才能设计优秀的异地多活方案？有哪些技巧 ？来吧，咱们一起聊聊 ：


下面是小编精选的云栖网友的答案：


来自云栖网友：1164827188210306
我们是做证券交易的，我们的案是先异地部署多个交易中心，有各自独立的数据库，然后将用户划分到不同的交易中心，并将用户请求路由到对应的交易中心，这样就实现了交易中心异地多活。交易中心本身支持异地异步数据复制。这样在某地区机房瘫痪时，受影响的交易中心只有未来得及复制的数据部分会有影响(丢失)，剩下交由业务层去判断和处理故障。这种方式不能够完全处理好故障，只能尽量减少故障影响到的用户，主要是因为是交易系统，我们还要兼顾性能，我们也头疼找不到一个比较完美的方案。


来自云栖网友： 初码
我的理解，余额等强一致性的场景，异地多活不现实，支付宝和银行都应该是一个核心主库吧，主要是在数据库上做文章。库存等展示型场景的异地多活，主要靠缓存和同步机制，也没必要做100%一致，如果再用一些云服务，比如大内网，再比如微软的SQL Azure等，又比如CDN的使用等等，这时候多做一些Web节点就可以其实云服务真的挺好，解决了很多架构设计上的的技术投入产出效率低下问题


来自云栖网友：wanl
我这边做的教育系统异地多活。按照地域分配访问到不同机房。每个机房的部署架构一致，多机房数据库互为主从，保证最终一致性，允许数据同步延迟，因为用户不会从一个地域瞬间移动到另一个的地域，他看到的始终是实时的数据。同步数据存在id冲突的问题，通过id生成器配置每个机房的id范围解决。异地多活解决的容灾，就近访问问题。有些事务要求强一致性要特殊考虑


来自云栖网友：痞子不俗
个人见解：数据，网路和应用都达到双活和多活才算真正意义上的有效的架构。现实中很难很难，宣传的很美，实际好多坑！分布式双活数据中心的建设是一个复杂的系统工程，它不仅仅要求网络系统双活，更是涉及到服务器系统、数据库系统和存储系统，甚至和客户的具体应用也是息息相关。上层应用通过大二层网络对外提供服务的通道对底层数据进行有效读写，还要实现可靠的负载均衡，真的太难了！数据中心间的网络延迟不能高于几毫秒，否则强一致性很难实现。根据业务要求划分有效的故障域是个不错的选择，数据的一致性可以分阶段分区域进行。


来自云栖网友： 1924229858864781
我的理解，余额等强一致性的场景，异地多活不现实，支付宝和银行都应该是一个核心主库吧，主要是在数据库上做文章。库存等展示型场景的异地多活，主要靠缓存和同步机制，也没必要做100%一致，如果再用一些云服务，比如大内网，再比如微软的SQL Azure等，又比如CDN的使用等等，这时候多做一些Web节点就可以其实云服务真的挺好，解决了很多架构设计上的的技术投入产出效率低下问题

欢迎大家参与讨论，原话题入口