前言

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

一、問(wèn)題背景

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

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

基于上述背景描述，我們?cè)谥贫ǚ桨傅倪^(guò)程中遇到了很多挑戰(zhàn)，主要分為三大類

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

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

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

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

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

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

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

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

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

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

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

四、方案構(gòu)思

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

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

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

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

（1）首頁(yè)、頻道頁(yè)

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

（2）門(mén)詳頁(yè)

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

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

因?yàn)榈讓右蕾嚨臄?shù)據(jù)源不一致，所以首頁(yè)、門(mén)詳頁(yè)分別制定不同的數(shù)據(jù)備份設(shè)計(jì)方案，首頁(yè)的由于和poi強(qiáng)相關(guān)，所以更復(fù)雜一些。門(mén)詳因?yàn)椴簧婕皃oi以及策略，所以相對(duì)首頁(yè)來(lái)說(shuō)容易一些。

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

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

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

重點(diǎn)來(lái)了！

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

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

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

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

Hexagon官方文檔：

如何識(shí)別網(wǎng)格熱點(diǎn)poi？

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

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

?

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

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

（2）門(mén)詳頁(yè)

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

策略選擇

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

（3）引入GIZP壓縮

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

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

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

（1）首頁(yè)、頻道頁(yè)

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

（2）門(mén)詳頁(yè)

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

五、落地過(guò)程

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


審核編輯 黃宇