概要：技术挑战、业界方案（读多写少 &读写均衡 按用户分离）、机房流量的精确调度
一、技术挑战
1、机房间网络延迟和带宽限制, 租用运营商的专线非常昂贵，可靠性不保障；
2、业务依赖关系复杂；改动不能太大
3、机房之间流量的精确调度；
最大挑战是网络延迟一系列问题如一致性，成熟方案如阿里单元化，按用户把业务封闭在一个单元里；腾讯set方案，微博，主要是集中写，快速切换。
二、业界方案（读多写少 & 按用户分离）
2.1读多写少
接入端分三种业务，API、开发者社区、运营后台。
(1)API（只需对API提供多机房方案）：应用商店读取榜单数据给用户，“读”从缓存读取，少量“写”来自评论等。
(2)开发者社区：App厂商上传、维护应用，读写均衡
(3)后台：榜单维护、应用上下架，较多“写”
华东机房通过MySQL同步功能复制，榜单类数据与核心机房一致从Redis缓存读取。定时任务从DB里获取定时刷到Redis里。
单点写，跨机房写入核心机房。分两种，(1)消息队列写入远程机房，即网络出现问题，"写"在MQ里不影响。(2)实时性高，跨机房直接写入db， 如网络问题失败，可以做降级
另外机房间流量调度我们实用GSLB来调度，后面有详细阐述。
2.2读写均衡业务
读写均衡业务有重要特性，按照用户维度切分，相互关联不大。把（联系人、短信、 ...）同步云端，永不丢失。
跨机房方案：(1)直接按照用户做全局路由，路由到不同机房即可，存储到不同DB分片
(2)业务数据和服务打包到单个Unit(可单独部署)，一个Unit服务一定数量的用户。每个机房有多个Unit,本地远程备份
(3)API访问时，GSLB把客户端请求调度到就近机房，获取用户数据所在位置（用户数据同时仅在某一个机房提供服务）。
ps；Web服务无法使用GSLB不能精准调度
三、机房流量的精确调度
3.1最简单的流量调度：智能DNS服务
只能DNS根据LocalDNS请求IP来判定是哪个ISP，哪个区域用户，调度到对应ISP,区域的机房，核心在智能DNS的IP库。
缺点：
DNS劫持, 在我国时有发生，尤其二三线城市运营商，明目张胆无法解决
设置指定DNS无法对应ISP，随机解析到错误的ISP和机房。如8.8.8.8，智能DNS获取到的LocalDNS是美国地址，
无法根据用户信息来调度，有些数据只在特定机房有，DNS协议无法携带用户标示，不能精准解析。
无法感知服务器宕机
3.2 接入GSLB服务:
避开DNS请求，请求前，访问GSLB服务(或HttpDNS),带上用户标识，定位数据所在机房，用IP访问。所有客户端的访问，都接入GSLB
好处：
1* 根据IP或UID等精确调度。
2* 避免DNS劫持。
3* 设置DNS也不会调度错误。
问题：仅用客户端Http、Https请求，不适合浏览器访问，浏览器不清楚GSLB是什么。所以：
3.3 GSLB+智能DNS（最终路由策略）：
请求前找到DNS解析的服务器，获取数据，后端先找GSLB服务查数据所在机房，如在本机房直接返回，否则重定向发起请求。
缺点：可能导致用户浏览器里域名变换，无法避免域名劫持
问题：最终是上面两种组合？
