【3.工程開發】-穩定性相關異地多活

機房流量劃分：

保證同一緯度查詢寫入儘可能在一個機房

切流控制點：

• 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同步數據