什么是异地多活?
异地：数据中心之间地域跨度相对较大
多活：多个数据中心都接受用户请求（包括读和写）
为什么要做异地多活？
1. 异地容灾（电缆被挖断，区域性机房宕机）
2. 负载均衡，用户请求就近处理
怎么做异地多活？在有限的条件下
1. 区域自治 -- 用户的所有请求在单个数据中心内即可满足，杜绝或者减少跨数据中心交互
2. 请求粘性 -- 用户第一个请求落在哪个数据中心，后续的所有请求都落在该数据中心
怎样实现区域自治?
1. 商品数据全量复制，实时同步
2. 卖家数据全量复制，实时同步
3. 买家数据做sharding，副本库同步
数据库同步的方式
1. 需要两个数据中心双写的数据（由用户触发生成的数据）
2. 只需要单个数据中心写的数据（由运营触发生成的数据）
两个数据中心双写的数据
1. 这部分数据要做sharding（综合地域分布和flymeid）
2. 各数据中心另建副本库存储另外数据中心这部分数据的副本
3. 数据中心间failover时，副本库要接受读写请求
4. 数据中心恢复的时候，开放引流前，要保证副本库里写的数据已经同步到恢复的数据中心
5. 为同步尽快完成对方数据中心保存的副本库的数据写入需要暂停一段时间
为什么采取这种方案？
1. 现在并没有有效的手段在不更改表结构的前提下实现实时双向同步（死循环）
2. 将来扩建更多个数据中心数据量会呈倍数增长（shard，1个副本，两倍；全量实时复制，和数据中心数量成正比）
3. 复制泛滥的同时浪费大量宝贵的带宽
4. 用户端的共享变量，暂且不表，到后面再说
单个数据中心写的数据
1. 这部分数据要做提供单个数据中心写，写入后实时同步至其他数据中心
2. 数据中心恢复的时候对方数据中心写入的数据要增量同步至本数据中心
共享变量的处理?何谓共享变量？
两个数据中心共享的变量， 分单个买家共享的变量和商家共享的变量：
1. 单个买家跨数据中心共享的变量： eg. 用户的优惠券，用户的红包，用户的回购券，用户的M码
a. 对单个买家来说，这些都是多数据中心共用的
试想一下同一个用户ID多个数据中心同时发起一个红包的使用请求
b. 根据用户ID做sharding同时也是为了解决这个问题
2. 商家跨数据中心共享的变量： eg. 商家发布的优惠券数量，红包数量，库存，M码数量，资金池
a. 改造配置中心，在配置中心里设置权重（权重可根据大数据统计的区域历史请求比重设定）
b. 各数据中心从配置中心得到自己的权重，在返回剩余库存或者已用数量的时候减去或者加上对方数据中心权重对应的数值
c. User Routing Service引入实时库存，根据传入的Servlet Path， SKU ID和从配置中心里获取的权重及实时库存精准引流
两个数据中心都正常的时候，只需要引入对应的lib，在对应方法上加annotation即可
数据中心切换预计需要很长时间才能修复的，需要合并共享变量的剩余值
怎样实现请求粘性?
传统的基于DNS的GSLB分流机制：
1. local loadbalancer上报数据给global loadbalancer, global balancer汇总数据发给权威DNS
2. 用户打开浏览器输入域名，浏览器通过ISP DNS递归查询域名对应的IP,权威DNS返回IP给ISP DNS
3. global balancer根据每个集群的容量和已有请求进行集群间的流量迁移
这种基于DNS的分流方式的缺点：
1. 流量分配不均
a. ISP DNS, DNS解析结果会被缓存，一个DNS请求可能对应到成百上千个服务请求
b. 缺乏广泛的edns-client-subnet支持,这不仅会导致流量的跨地区访问，还会严重影响用户体验
c. 用户手动设置DNS服务器，得不到最优IP解析
d. 小ISP使用其他异地ISP的DNS，得不到最优IP解析
2. 没有办法及时failover，会有几分钟到几个小时的延迟
3. 缺乏有GSLB开发经验的工程师
那么在有限的条件下,我们该如何实现分流方案？
配合使用CDN回源机制是最好的选择
基于CDN的分流方案：
1. 所有对外暴露的引流页面对应域名都通过CDN加速（改造成本低）
2. 网宿CDN不同区域节点就近设置不同的回源地址（对应不同数据中心）
3. 备份回源地址设置另外一个数据中心
4. 不同数据中心的源生成的静态网页不同
a. 网页里link和ajax host都从指定的抽取出来的常量文件里获取
b. 不同数据中心源生成网页时通过配置中心引入不同版本的常量文件
c. 运营通过CMS录入的link根据配置中心里获取的数据中心属性动态替换成对应的URL
上述分流方法适用于PC端和H5
APP相对简单，只需要引入总部GSLB SDK做相应适配即可
User Routing Service, Database Routing, Butian这些服务PC, H5, APP共用
存量数据处理：
1. 数据库里只存最近三个月的数据，往前回溯超过三个月的数据DUMP进HBASE
2. HBASE跨数据中心复制
3. User Routing Service和Hbase Dump Service同步，每月从会员中心更新数据中心和d的映射关系
4. User Routing Service里的映射关系实际上就是聚集了三个月内跟用户相关的所有SHARD表里出现的用户ID和数据中心的映射关系
包括我的订单，我的优惠券，我的红包，我回购单，我的回购券，我的意外保，我的退换货相关表（消息和意见反馈除外）
不能用登录来判断，要不然登陆后做failover，部分用户下单永远不会成功
5. User Routing Service提供的映射关系只是一份为期三个月的租约，三个月后用户SHARD数据被DUMP后再有新的写入请求重新根据地域和ID确定数据中心
6. 分页是个有点技术含量的活儿
以上是之前我们做电商商城业务的时候落地的一套异地双活设计方案，后来看到饿了么的异地多活方案的介绍也是感触颇深，这里把链接贴出来大家一起看看
如何学习Java架构，如何才能快速入门并精通呢？
当真正开始学习的时候难免不知道从哪入手，学习时频繁踩坑，导致效率低下影响继续学习的信心，最终浪费大量时间。
为了让学习变得轻松、高效！今天给大家免费分享一套教学资源，帮助大家在成为架构师的道路上披荆斩棘。
群内已经将知识体系整理好（源码，笔记，PPT，学习视频）进群免费领取。
加Q群：948368769，免费领取资料
享给喜欢Java，喜欢编程，有梦想成为架构师的程序员们，希望能够帮助到你们。
最后，做一个爱思考，懂思考，会思考的程序员。