标签：设立 默认 业务逻辑 family 产生 book 选择 时间 下单
很多全球化的产品， 比如facebook、twitter， 它们的用户遍布世界各地。 工程师们往往会在全球设立多个数据中心（DC）供用户访问， 我们可以称之为异地多活。在后续一段时间里， 我会写一系列的博客，和大家一起探索异地多活架构。
这篇文章主要是讨论我们为什么需要异地多活， 以及实现这种架构所需要解决的问题。
一、异地多活的好处
1. 提升用户体验
一个产品最重要的是提供良好的用户体验，这对后端服务提出了几个要求：
服务的高可用
对于一些服务而言， 需要提供6个9甚至以上的可用性。 高可用的原则就是避免单点+自动故障转移。 为了避免机房粒度的单点， 我们需要提供多个DC， 彼此做灾备。
良好的响应速度
如果全球只有一个DC，那么所有的用户都只能访问这一个。 这种情况下，跨洲级别的RTT（一般来说>200ms），对于用户体验而言是个灾难。 所以全球级的产品需要在世界各地部署DC，供用户就近访问。
2. 降低成本
廉价的机器
我们都知道， 很多商品在不同地方的价格是不一样的，服务器也不例外。 如果能让非洲用户访问本地廉价的后端服务， 为什么要让他们的流量跑到美东去呢？
流量的分摊
一般而言，我们需要控制机器资源大于峰值流量的某个百分比, 比如为1w日活备好2w日活的机器。
如果你的DC已经遍布世界各地， 那么如果某地的流量疯涨时，你不需要担心机器资源不能及时到位、为高峰期扩容后的资源浪费这种问题。 比如过万圣节、圣诞节时，facebook美国流量疯长， 这时候我们可以选择把一部分流量切到亚洲地区的DC。
二、如何做到异地多活
要做到异地多活， 有几个问题我们必须解决：
接入层流量控制
用户默认访问哪个DC？ 什么时候做切换？ 如何控制这个切换过程？
各DC业务逻辑一致
对于用户来说， 他的流量被调度前后，业务逻辑是一致的。 比如facebook上有一些内容对于亚洲用户是不可见的，不能因为亚洲用户的流量被迁移到了美洲机房，这个限制就失效了。
跨DC的实时数据同步与冲突处理
还是以fb为例， 如果访问非洲机房的用户A给访问南美洲机房的用户B的一个帖子点了赞， 那么B应该能及时收到相关的通知。这背后就依赖数据的实时同步。
在多活情况下， 多DC的数据写入势必会引入数据的冲突， 比如facebook位于美东的的审核系统和位于东南亚的用户同时操作了一条帖子， 就会产生数据的冲突。
提供全球级别的强一致性
对于大多数业务而言， 我们只需要最终一致性即可（比如点赞之类的计数）。 但是某些业务，需要全球的强一致保障(比如下单、支付之类的操作）。
https://mp.weixin.qq.com/s/vkvYJnKfQyuUeD_BDQy_1g
获取更多学习资料，可以加群：473984645或扫描下方二维码
标签：设立 默认 业务逻辑 family 产生 book 选择 时间 下单
原文地址：https://www.cnblogs.com/lemonrel/p/11794042.html
