前言

在面向服務的架構（SOA）系統中，容災能力是保障系統穩定性的重要組成部分。通過引入多數據中心部署、自動化故障轉移、數據備份等技術手段，可以有效提升系統在面對突發災難事件時的恢復能力。例如，采用主從復制和異地多活架構，可以確保在某個數據中心發生故障時，其他數據中心能夠迅速接管業務，避免服務中斷。此外，定期進行災難恢復演練和系統壓力測試，也是提高容災能力的關鍵措施。通過這些手段，SOA系統能夠在各種極端情況下保持高可用性和穩定性，從而為用戶提供持續可靠的服務。今天重點聊一下LBS場景下的數據備份方案。

一、問題背景

隨著秒送業務的上線，基于LBS的用戶交易的流量逐漸提升，不同于JD主站的B2C場景，O2O場景下的資源場景劃分的非常精細，根據門店履約圍欄劃分3公里、2公里、1公里等不同的范圍，資源與資源之間互相交錯、覆蓋，構建成一個具有LBS特性的資源網。作為入口級流量的后臺SOA服務，我們需要根據業務特性區分哪些數據強實時/弱實時來制定不同的數據備份策略、還需要弄清楚底層數據生產的邏輯鏈路，才能保障數據備份的真實性、還需要考慮用戶使用的這份備份數據體驗等等因素。因此，LBS場景下的容災數據備份的難度瞬間升級。

二、痛點/挑戰

基于上述背景描述，我們在制定方案的過程中遇到了很多挑戰，主要分為三大類

1、如何緩存poi經緯度數據

如果要按照全國poi經緯度去緩存數據，為了降低數據差異，我們把不同poi點的距離精確到（米級），那么全國poi的數量是多少呢？根據主站網格地址統計，精確度在75米的poi點在6.8億+，如果按照1米算，估計千億+級別的poi。如此量級的poi數據，我們如果每一個poi都做數據備份的話（理想狀態）；拿秒送首頁、頻道頁舉例，首頁一次交互數據大小600kb左右，頻道頁核心5個，每個400kb左右，那么每個poi需要2600KB的存儲，按照75米的poi距離，需要6.8億*2600kb=1646TB，C端數據最終存儲在redis中，按照5G=1核=15元/月，那么需要花費500萬+人民幣/月，老板聽完方案匯報臉都黑了。

2、如何降低容災數據存儲成本

每個月500多萬的存儲開銷成本顯然是不現實的，于是我們迎來了第二個挑戰，那就是怎么才能降低這么大的存儲成本，于是我們內部多次討論，絞盡腦汁，得出結論：如果想讓用戶得到最好的體驗那么似乎和成本之間是互斥的，我們怎么才能尋找一個中間點，來平衡戶體驗和成本。

3、如何保障緩存數據資源的有效性

在進行數據備份時，數據一致性問題是不可避免的關鍵點?？紤]到如此龐大的數據量，若采用實時請求備份的方式，SOA層面的請求負載將可能對底層RPC造成極大的查詢壓力。相對而言，異步構建方法則要求我們復制主站搜索、推薦和GIS定位等異構邏輯（因為秒送首頁、門店詳情等資源來源于主站搜索、推薦和GIS），這不僅意味著需要處理上千個中臺的消息隊列（MQ），還要確保邏輯與現有系統保持一致，這顯然是個巨大挑戰。

因此，我們的選擇余地有限。有觀點認為，數據備份并不需要完全真實，稍有偏差也是可接受的，甚至可以使用靜態圖片代替。我們承認，實現數據容災備份與線上數據保持100%一致是不現實的。但我們的目標是盡可能保證90%的用戶體驗與線上相似，同時確保交易流程的連續性，并在系統異常時為用戶提供無感知的體驗。（此處價值觀強調升華，用戶為先）

三、業界方案調研

flag立完了，但是確實沒啥好思路，B2C場景的不適用，只能是去跟隔壁同行取取經，通過多方渠道找到了一些靠譜的某團的技術大佬，并且做了1對1的溝通。大致梳理了下他們的架構和容災方案。

某團的超市便利架構：

通過溝通得知，某團在SOA層，沒有做任何的數據備份容災，完全依賴底層的數據提供，如果底層數據返回空，那么頁面也會空白...至于底層數據有沒有做容災數據備份，就不得而知，我相信是有的。于是到這里，感覺前路又被堵死了。

四、方案構思

調研無果的情況下，我們回過頭來重新整理下現有的邏輯鏈路，從中尋找一些突破點，為了整體容災數據備份方案做預設計。

1、首先根據業務篩選下，哪些入口是阻塞交易鏈路，不可降級的

從中識別出：首頁、頻道頁、門詳頁是阻塞交易的環節，需要進行數據備份。

2、底層數據依賴的鏈路邏輯分別是什么

（1）首頁、頻道頁

首頁和頻道頁充當著網站的主入口，它們利用CMS系統和定向投放系統實現了基于地理位置服務(LBS)的樓層內容過濾。網站內容通過商品組合、廣告組合以及推薦機制構建，核心資源主要依賴于推薦系統的數據池。我們分析后注意到，不同用戶在同一地點或同一用戶在不同地點可見的內容各不相同，這主要是由推薦系統的數據池結合特定策略實現的。推薦數據所依賴的因素來源于多種策略的分配，而這些策略因素又會反過來影響推薦結果。這導致我們無法僅通過備份當前數據來保持數據的一致性，因為策略的即時變化可能會使備份數據的結果發生變化。若要備份數據與線上數據完全一致，我們需要復制一整套推薦系統的數據流轉過程，這是目前的一個難點。為了應對這種情況，我們采用了一個通用賬號執行普通策略來進行數據備份，以盡可能排除變量因素，雖然這犧牲了一定的個性化推薦能力，但確保了數據正常展現。

（2）門詳頁

門詳頁是秒送流量的關鍵交易通道，其核心門店分類和商品信息均通過搜索引擎和商家分類中臺獲得。盡管集團的主搜索引擎已經分離出專門的垂直搜索服務供秒送場景使用，但數據源仍然是共用的，區別僅在于網關層面的分離。與首頁和頻道頁不同，門詳頁專注于門店層面的分類和商品數據，不需涉及廣告投放和目標人群等因素。只要門店能在首頁展示，用戶點擊進入后看到的分類和商品就會保持一致。因此，我們的主要關注點是確保當前搜索引擎的數據源是準確的。我們對線上100家不同類型的門店（包括連鎖品牌和非連鎖品牌）進行了一周的觀察，發現門店分類變動較少，而分類下的商品狀態和庫存變化較頻繁。基于此，我們可以對門店分類實施全量緩存（考慮到較低的時效性需求），而對于分類下的商品則根據情況實施緩存（需要較高的時效性）。

3、削減數據備份量級思路

因為底層依賴的數據源不一致，所以首頁、門詳頁分別制定不同的數據備份設計方案，首頁的由于和poi強相關，所以更復雜一些。門詳因為不涉及poi以及策略，所以相對首頁來說容易一些。

（1）首頁、頻道頁（引入網格思想）

在整理推薦系統的數據鏈路時，我們注意到推薦結果中的門店商品資源高度依賴GIS系統。深入分析GIS邏輯后，了解到GIS維護著不同覆蓋范圍的網格圍欄，如3公里、5公里和20公里網格，并且每個網格下的門店商品資源是相同的。這啟發了我們，如果我們也能構建一個類似GIS的網格系統并緩存門店商品，豈不是能顯著提升數據的一致性？然而，現實告訴我們，推薦系統調用GIS接口是基于策略模型的選擇，并非易事。若要完整復制推薦系統邏輯幾乎不可能。

然而，網格的概念是值得借鑒的，因為它可以大幅減少我們的POI緩存數據規模。如果我們反其道而行之，直接緩存當前POI下的推薦結果，就無需處理推薦邏輯的復雜性。接下來的挑戰是構建一套盡可能與GIS網格重疊的網格系統。

重點來了！

如何選擇構建網格類型？

開源的網格grid構建空間索引又很多種，墨卡托、geohash、H3、S2等等，那么我們如何去選擇呢？GIS提供的網格接口使用的空間索引是geohash四邊形網格，但是為了以防萬一，我們通過主站網格中臺封裝的JMF組件，異構了包含了geohash在內的多種空間索引，目的是全方位覆蓋，為了后續的diff提供多種選擇，得到最優結果。這里我就挑一種H3作為demo去講述如何構建的網格。

如何去構建網格？

另外一個問題，構建網格的分辨率應該如何選擇，也就是我們常說的網格精度。我們去門店中臺查了秒送的門店范圍，發現90%以上的門店都是基于3公里圈定的不規則履約范圍，而這個也是作為GIS判斷網格是否覆蓋該門店的核心因子。所以在構建網格的時候，每個蜂窩格子的面積限定3公里顯然不能得到最優結果，于是我們通過H3的空間索引構建了 Hexagon六邊形網格，盡可能的模擬線上真實不規則的履約圈選范圍。同時Hexagon的邊長精度劃定為7也就是1.4km，得到最小六邊形面積3.12m2，最大六邊形面積6.22m2。同時針對精度8的也異構出一套數據作為diff參照。經過計算后得出（刨去偏遠地區），精度7的熱點網格數量在幾十萬+，精度8個網格數量在百萬+，和原本的百億級別相比，降低了99%~~，最后經過成本計算：①精度7的=2973元/月 ；②精度8的=14133元/月 （相比于最初的500萬+/月，打折到骨折?。?/strong>