稳定性相关异地多活

机房流量划分：

保证同一纬度查询写入尽量在一个机房

切流控制点：

• DNS：DNS 缓存，切流量无法立刻生效 流量无法通过 DNS 完全切干净，有剩余流量（对应入网框架中，在 httpdns 中改，有一点点本地缓存，webapp 无法用 httpdns）
• LVS（无法根据业务需求流量划分的）
• ROUTEr（改 nginx）。内部调用（inrouter 同上、thrift 本来就是 service 的 ip 直接服务发现时改，用同一份）
• 业务代码

选取 router
增加 nginx 的 dynamic_req_add key cityid $city_id
dynamic_req $upstream_name default_liddc=xx upstreamm_name=xx port=xx;

机房下线：
先 DNS 去掉，router 配置去

数据同步。本质是双机房要保持全量数据

mysql 主从
redis 见 https://segmentfault.com/a/11…
为什么 redis 不能和 mysql 一样用主从集群分机房？mysql 本身主从延时就大，不像 redis 这种本身作为缓存的东西，机房间链路不稳定，如果主从复制配置同步或者命令延时就拒绝写 / 集群夸机房影响稳定。同步全部异步，基本用 mq，否则要加丢失数据补齐太复杂。
mq。写入双写或消费双订阅。
切换过程中，因为重试等会有点问题。无法做到的。。。

机房迁移，迁移过程中双活。或维持上期双活

收敛配置，增加双机房配置
机器 ready
功能验证。QA 测
性能验证。指定 url 压测
数据同步
代码里用小流量测试
DNS 改 50
DNS 彻底改
残余流量：旧 route 中 IP 配成新机房的 VIP（不配为 IP 的原因是故障摘除方便，要一直持续发半年）

双活下机房迁移（有三活）
如果数据同步支持三活，没问题。如果只支持双活，可以：
验证 C 功能：A 与 B 做双活，C 读 A 的 redis
数据切 C：A 与 B 断双活，B 与 C 做双活，A 读 C redis
故障应对：C 有问题后，流量切回 A，A 读 Credis, C 与 B 同步数据