前言

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

一、問題背景

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

二、痛點/挑戰(zhàn)

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

1、如何緩存poi經(jīng)緯度數(shù)據(jù)

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

2、如何降低容災(zāi)數(shù)據(jù)存儲成本

每個月500多萬的存儲開銷成本顯然是不現(xiàn)實的，于是我們迎來了第二個挑戰(zhàn)，那就是怎么才能降低這么大的存儲成本，于是我們內(nèi)部多次討論，絞盡腦汁，得出結(jié)論：如果想讓用戶得到最好的體驗?zāi)敲此坪鹾统杀局g是互斥的，我們怎么才能尋找一個中間點，來平衡戶體驗和成本。

3、如何保障緩存數(shù)據(jù)資源的有效性

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

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

三、業(yè)界方案調(diào)研

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

某團的超市便利架構(gòu)：

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

四、方案構(gòu)思

調(diào)研無果的情況下，我們回過頭來重新整理下現(xiàn)有的邏輯鏈路，從中尋找一些突破點，為了整體容災(zāi)數(shù)據(jù)備份方案做預(yù)設(shè)計。

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

從中識別出：首頁、頻道頁、門詳頁是阻塞交易的環(huán)節(jié)，需要進行數(shù)據(jù)備份。

2、底層數(shù)據(jù)依賴的鏈路邏輯分別是什么

（1）首頁、頻道頁

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

（2）門詳頁

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

3、削減數(shù)據(jù)備份量級思路

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

（1）首頁、頻道頁（引入網(wǎng)格思想）

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

然而，網(wǎng)格的概念是值得借鑒的，因為它可以大幅減少我們的POI緩存數(shù)據(jù)規(guī)模。如果我們反其道而行之，直接緩存當(dāng)前POI下的推薦結(jié)果，就無需處理推薦邏輯的復(fù)雜性。接下來的挑戰(zhàn)是構(gòu)建一套盡可能與GIS網(wǎng)格重疊的網(wǎng)格系統(tǒng)。

重點來了！

如何選擇構(gòu)建網(wǎng)格類型？

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

如何去構(gòu)建網(wǎng)格？

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

Hexagon官方文檔：

如何識別網(wǎng)格熱點poi？

（選擇網(wǎng)格中的哪個poi作為當(dāng)前網(wǎng)格的緩存代表？）

構(gòu)建好網(wǎng)格后，問題又來了，因為網(wǎng)格是一組poi的集合，我們只有拿到一個網(wǎng)格內(nèi)部數(shù)據(jù)備份最好的poi經(jīng)緯度，才能去模擬線上用戶請求進行緩存，作為這個網(wǎng)格的容災(zāi)數(shù)據(jù)備份，從而達到最優(yōu)的數(shù)據(jù)備份效果。經(jīng)過和網(wǎng)格中臺溝通后得出，網(wǎng)格集成了格子內(nèi)的用戶請求分布情況，于是我們可以根據(jù)用戶分布最集中的經(jīng)緯度poi點進行數(shù)據(jù)備份，達到最佳效果。

?

?數(shù)據(jù)備份時間多久？

最后就是數(shù)據(jù)備份的時間，也就是數(shù)據(jù)一致性的問題。上面說過了，推薦包含了很多策略，同一個用戶 白天和晚上看到的首頁結(jié)果都不一樣，這個就是涉及到體驗和成本的問題，如果為了保持好的體驗，我們可以緩存2套數(shù)據(jù)，白天一套、晚上一套。但是考慮到晚上用戶占比過少，一期還是優(yōu)先緩存白天的數(shù)據(jù)。

（2）門詳頁

門詳頁的容災(zāi)備份上面提到了，我們只需要考慮如何緩存門店分類數(shù)據(jù)和商品數(shù)據(jù)，分類數(shù)據(jù)一個門店最多幾百個，但是商品可能往往上萬，掏出小本本，我們再算一筆賬：我們現(xiàn)在百萬+門店，每個門店的商品乘以每條商品數(shù)據(jù)平均按1kb算，那么成本預(yù)估15W元+/月，領(lǐng)導(dǎo)聽完匯報臉又黑了。

策略選擇

我們經(jīng)過討論后，決定先對每個末級分類的前兩頁商品進行緩存，并且剔除掉閉店的門店。經(jīng)過策略估算后，緩存量級可以壓縮到900元/月

（3）引入GIZP壓縮

經(jīng)過實踐后發(fā)現(xiàn)，gizp壓縮對于純文本的壓縮預(yù)估能節(jié)省60%的空間，但是需要注意的是QUERY數(shù)據(jù)解壓縮的性能耗時。我們在進行設(shè)計的時候，把所有的數(shù)據(jù)全部轉(zhuǎn)化成String字符串，并且通過gizp壓縮。最終得到以下備份數(shù)據(jù)量級：

至此，整個容災(zāi)數(shù)據(jù)備份量級壓縮方案可行，相比于最初的500W+/月，降低到了9018元/月。（還要啥自行車？領(lǐng)導(dǎo)當(dāng)即拍板，趕緊做完上線）

4、DIFF思路-如何去和線上做DIFF？

（1）首頁、頻道頁

到了驗證環(huán)節(jié)了，因為我們無法完全和GIS的網(wǎng)格重合，那么我們需要一套規(guī)則來做DIFF驗證網(wǎng)格的熱點poi數(shù)據(jù)備份是否和線上poi數(shù)據(jù)返回一致（不可能100%一致，但是需要知道是否達到90%以上的效果），我們選擇六邊形網(wǎng)格的六個定點poi以及中心poi，共計7個poi去請求線上，并且用返回的數(shù)據(jù)和熱點poi請求返回的數(shù)據(jù)做DIFF，核心39城每個城市抽查10組，最終得到一個比例。然后通過不同的空間索引精度，去挨個驗證出一個最佳的索引精度。

（2）門詳頁

門詳DIFF驗證，抽選出重點KA門店，定時任務(wù)check門店下的分類和商品情況。如果抽查整體DIFF異常率超過30%，我們則會觸發(fā)新一輪的異構(gòu)任務(wù)。

五、落地過程

上面的方案構(gòu)思經(jīng)過無數(shù)次的推演以及前期驗證確保了方案的可行性。那么接下來就是到了落地環(huán)節(jié)，在這個環(huán)節(jié)里，我們發(fā)現(xiàn)其實客戶端本身也有緩存，但是緩存的大小非常有限。客戶端采用的localStorage本地緩存存儲，是基于用戶的手機內(nèi)存做的，5M左右的大小空間。所以適合做一些兜底災(zāi)備的緩存，比如服務(wù)端徹底down的情況下，應(yīng)急去讀客戶手機內(nèi)存緩存。用戶每次成功請求服務(wù)端后，都會重寫更新緩存，于是，一個可行（邪惡


審核編輯 黃宇