1.所有业务都要做异地多活
拿注册的系统举例子，A用户在a中心注册中，数据已经写入a，还没有返回给A注册成功，刚巧不巧的，a他妈给挂了，数据也还没有同步到b中心，这个时候用户A得不到注册成功的信息，于是乎会刷新，这个时候就轮到b....z中心提供服务。如果不是刚巧不巧那种情况，用户会注册成功。然后就尴尬了，a b中心都有一份A的注册信息，但是理论上注册只能允许一名用户注册一次，这就违反了业务核心法则。
有爱钻研的同学说了，那么在数据库中保存一个全局唯一递增的id，取最大的id作为最终的数据，这样就可以保证数据的唯一性。这个时候鸡生蛋蛋生鸡的问题就出现了，生成全局唯一递增id的这个系统需不需要做异地多活啊，别不做啊，你这么爱较真的人，肯定得做啊，那如果这个系统也出现刚巧不巧的问题你咋整？
所以啊，不是所有的系统都适合做异地多活的，把那些业务核心系统做了就成了，旁枝末节的不重要的，真没必要做，那些系统做了的话，付出就很大，而且注定得不到相应的回报，那你做他干啥？（解释一下为什么会注定得不到，因为有的系统压力很小，实时性要求不强，基本自己不捣乱不可能挂掉。拿注册举个栗子，互联网的人口红利早就没了，而且如果你写个注册的系统还能挂。。。你基本下半辈子就告别it吧，不合适，别瞎比耽误自己了）
说一下结论哈：优先给核心业务做异地多活
举个栗子吧，什么业务算是核心业务。比如你是一个创业公司的CTO，发展的还算小有成就，每天日活1000w的用户，够给面儿了吧。注册，一天撑死几万几十万，别告诉我你一个日活千万级别的公司，搞不定一个最多几十万访问量的注册系统。这种场景下，哪种算是核心业务呢？登录，日活辣么多，登录肯定也少不了吧，而且异地多活这种场景很适合做登录，每个中心都保存一份用户的账号密码，随便去哪个中心登录都可以，美滋滋。就算a挂了，去b去c去d！随便去！
哎，爱较真的你肯定能想到这么一个场景，你在a中心更改了密码，然后a又他妈刚巧不巧挂了(我给a中心郑重道歉一次)，数据还没有同步到其他节点，哎，用户他在其他中心登陆不上去了，这么想说明你洞察业务的能力很强，但是这里就有涉及到另外一个误区，继续读下去。
偷偷插一句啊，说了这么久还没有说异地多活的实际价值。
异地多活通过大量的数据冗余，来满足即使变态难的环境下，还能向用户提供良好的服务。所以核心就是大量冗余数据之间如何同步。
2.所有数据实时一致性
既然我刚才说了，核心是如何保持大量冗余数据之间的同步。这个时候追求完美主义的人，一定想要得到所有数据实时一致性。我呸，你咋不上天呢，这咋可能？你以为你三体？你以为你小水滴？你以为你二向箔？根本不可能，数据的传输是需要时间的，光速在真空中传播的速度是30wkm/s，在光纤中是20wkm/s，这还仅仅是传播速度，你还得考虑地震啦、蓝翔拿你家的光缆练手挖掘机啦等等等等，所以实时一致性，绝逼不可能。
既然实时一致性这个事不可能搞定，那么有什么其他的曲线救国的方法吗？
1.减少距离
异地的距离相对来说近一些的话，比如丰台机房和昌平机房，都在北京市内，距离没有差很多，再在中间拉一根专线，几乎就可以做到数据同步实时一致性。但是，遇到整个区域内的网络、地震、海啸问题就无力回天了。所以这点，还是和异地概念有些冲突，需要权衡。
2.保证重要数据一致性
老生长谈的问题，在资源有限的情况下，只能对重要数据进行一致性维护。但是会存在这样一个问题，不重要的数据如何保持一致，比如不重要的数据来自于客户端，那就需要客户端再次发起请求，影响用户体验。但是相比于用户体验，保证用户行为的确切性更加重要。
3.保持最终一致性
不同级别的数据，应该给予不同级别的操作顺序，这样可以最大化利用现有资源。
3.数据一致性的方案
- 应用较为成熟的现有方案，MySQL主从，Redis Cluster，ES的集群，但是没有方案能适配所有场景。
- 消息队列
- 溯源读取，根据请求判断最开始保存数据的中心，然后开始中间之间的数据获取与传递。
- 客户端重新访问
4.异地多活架构总结
在绝大多数情况下，牺牲一小部分用户的体验，满足绝大多数用户核心业务正常操作的一种架构方式。
