前言
相比同城異區和跨國異地，跨城異地其複雜度是最高的。跨城異地的架構設計主要是解決在資料不一致的情況下，業務不受影響或者影響很小。下面主要介紹一些跨城異地的一些設計技巧：保證核心業務的異地多活、保證核心資料最終一致性、採用多種手段同步資料、只保證絕大部分使用者異地多活。
保證核心業務的異地多活
異地多活是為了保證業務的高可用，但是在設計架構時，容易陷入一個誤區：需要保證所有的業務的異地多活。如果要實現所有業務都支援異地多活，實際上是很難的，有的問題甚至是無法做異地多活的。其設計原則應該優先保證核心業務的異地多活，需要考慮哪些業務是核心業務。
保證核心資料的最終一致性
異地多活的本質是透過異地的資料冗餘，來保證極端情況下業務能夠正常的返回給使用者，因此資料同步是異地多活的關鍵。這又容易陷入一個誤區：想要保證所有的資料實時同步。
資料冗餘是將資料從A地同步到B地，從業務的角度來看是越快越好，最好是和本地機房一樣快。但實際是：異地多活是不能很快，這是由物理定律決定的。因此所有資料是實時同步是一個無法實現的目標。
既然無法徹底解決，那隻能儘量減少其影響。
儘量減少異地多活機房的距離，搭建高速網路。
儘量減少資料同步，只同步核心業務相關的資料。
保證最終一致性，不保證實時一致性。
最終一致性在具體實現上，需要不同的資料特徵，進行差異化處理，以滿足業務的需要。
採用多種手段同步資料
資料同步是異地多活設計的核心，基本上儲存系統本身都會有資料同步的功能。如：Mysql的主備複製、Redis的Cluster功能、ES的叢集功能。對於這些儲存系統本身帶有資料同步功能的系統，直接拿來用就可以了。但是我們在設計時，不僅僅需要使用儲存系統本身的資料同步功能。儲存系統本身的資料同步功能，在某些場景下無法滿足業務需求的。
我們應該拓寬思路，採用多種資料同步方式。
訊息佇列方式
對於賬號資料，可以採用訊息佇列的方式同步到其它業務中心。
二次讀取方式
在訊息佇列同步延遲的情況下，我們可以採取二次讀取的方式。如使用者在A中心註冊後，然後在B中心訪問服務，由於B中心沒有使用者的資料，在本地讀取失敗後，根據路由規則，再去A中心讀取一次，這樣就能夠解決異常情況下同步延遲的問題。
儲存系統同步方式
對於使用者修改頻率很低的資訊，比如密碼、使用者資訊這類資訊，可以透過資料庫同步方式同步到其它業務中心。
回源讀取方式
比如對於使用者session這類資訊，由於資料量大，可以不同步。比如：使用者在A中心登入後，又在B中心操作，B中心可以拿到使用者上傳的sessionid，根據路由規則，去到A中心請求session資料。
重新生成資料方式
對於回源讀取方式，如果A中心宕機了，B中心請求session失敗，就只能重新登入，讓使用者在B中心重新登入，生成新的session資料。
只保證絕大部分使用者的異地多活
某些場景下我們無法保證100%的業務可用性，總是會有一定的損失。比如密碼不同步導致無法登入、使用者資訊不同步導致使用者看到舊的資訊等。
在設計架構時，非常容易陷入這樣的誤區：我要保證業務100%可用。但是在極端情況下就是會丟失一部分資料，就是會有一部分資料不同步，有沒有什麼辦法可以解決這些問題達到100%的高可用呢。
實際上是沒有辦法的。異地多活也是無法保證業務的100%可用。這是由物理因素決定的，光速、網路的傳播速度、硬碟的讀寫速度、極端異常不可控等，都無法保證業務100%可用。所以在這種情況下，我們必然需要忍受這一小部分使用者或業務上的損失，否則本來想為了保證最後0。01%的使用者可用性，設計一個所謂的完美方案，到最後99。99%的使用者都無法保證。
對於某一些強一制性的業務，可能受影響的使用者會更多，甚至達到1/3或更多。
雖然無法做到100%的可用性，但並不意味著我們什麼都不做。可以採取一些措施補償或安撫使用者。
掛公告
事後對使用者補償
補充體驗
對於為了做異地多活帶來的體驗損失，可以想一些方法來減少或規避。比如：對於使用者轉賬來說，為了讓使用者不需要確認是否轉賬成功。可以在轉帳成功或失敗後，給使用者傳送一條簡訊，告知使用者轉帳狀態。
總結
異地多活的關鍵就在於：採用多種方式，保證絕大部分使用者的核心業務的異地多活。
