美團酒店直連項目自2013年末開始，通過業(yè)務(wù)上的不斷完善和技術(shù)上的不斷改進(jìn)，至今已經(jīng)接入200多家供應(yīng)商，其中在線酒店3萬以上，在線SPU30萬以上。經(jīng)過兩年的成長，美團酒店直連平臺終于在2015年末發(fā)展為國內(nèi)最大的酒店直連業(yè)務(wù)平臺，其接入的業(yè)務(wù)類型也從最初的經(jīng)濟連鎖，拓展到高星渠道、小連鎖集團、非標(biāo)準(zhǔn)住宿等，獲得了業(yè)界一致好評。

隨著美團的日益壯大，客戶的需求和系統(tǒng)體量的不斷增加，直連平臺的技術(shù)架構(gòu)和數(shù)據(jù)應(yīng)用面臨著諸多挑戰(zhàn)。為了保障美團的用戶體驗度，對技術(shù)方面會提出更高的要求。 - 如何在合作方接口極不穩(wěn)定的情況下保持高可用效果？ - 如何在不影響系統(tǒng)穩(wěn)定性的前提下提升接口響應(yīng)時間？ - 如何解決龐大數(shù)據(jù)帶來的一致性問題的同時降低系統(tǒng)運營風(fēng)險？

這些是直連平臺每天都在思考的問題。技術(shù)平臺和數(shù)據(jù)應(yīng)用的改進(jìn)完善并非一蹴而就?？紤]到數(shù)據(jù)是業(yè)務(wù)運營的核心，這里先以產(chǎn)品數(shù)據(jù)一致性問題的解決方案作為切入點與大家分享，也希望借此拋磚引玉，歡迎更多的同學(xué)一起探討，共同進(jìn)步。

為了使數(shù)據(jù)一致性完善方案更直觀易懂，這里引用美團酒店直連項目中直連平臺與供應(yīng)商酒店產(chǎn)品數(shù)據(jù)一致性方案作為分析案例，通過面臨問題、總體思路、解決方案和總結(jié)思考四個方面進(jìn)行論述。

酒店直連系統(tǒng)的主要工作是將供應(yīng)商的酒店產(chǎn)品（房型），通過系統(tǒng)對接的方式，轉(zhuǎn)化為美大點評平臺可以售賣的產(chǎn)品（房型）。

酒店產(chǎn)品購買是一個可預(yù)訂日期跨度比較長的業(yè)務(wù)。以美團App為例，可以預(yù)訂60天內(nèi)的酒店。

因此我們的系統(tǒng)需要將供應(yīng)商全部酒店全部房型信息以及60天內(nèi)的價格、庫存、售賣取消規(guī)則等信息，獲取到我方，落地后形成產(chǎn)品數(shù)據(jù)，一則用在C端給用戶進(jìn)行展示，二則參與交易環(huán)節(jié)。

下圖為產(chǎn)品供給流向圖：

問題：直連系統(tǒng)在上單流程中如何保證產(chǎn)品緩存與供應(yīng)商系統(tǒng)的數(shù)據(jù)一致性？

上述面臨的情況很像數(shù)據(jù)庫的主從同步問題，那我們是不是可以借鑒主從同步的方式來解決該問題呢？我們來看一下MySQL主從備份的實現(xiàn)細(xì)節(jié)：

MySQL使用3個線程來執(zhí)行復(fù)制功能（其中1個在主服務(wù)器上，另2個在從服務(wù)器上）。當(dāng)開始同步時，從服務(wù)器開始創(chuàng)建一個I/O線程，以連接主服務(wù)器，并且讓主服務(wù)器發(fā)送在其二進(jìn)制日志中的語句。主服務(wù)器創(chuàng)建一個線程將二進(jìn)制日志中的內(nèi)容發(fā)送到從服務(wù)器。 該線程即為主服務(wù)器上show processlist輸出中的Binlog Dump線程。從服務(wù)器I/O線程讀取主服務(wù)器Binlog Dump線程發(fā)送的內(nèi)容，并將該數(shù)據(jù)復(fù)制到從服務(wù)器數(shù)據(jù)目錄中的本地文件（即中繼日志）中。 第3個線程是SQL線程，由從服務(wù)器創(chuàng)建，用于讀取中繼日志并執(zhí)行日志中包含的更新。 在從服務(wù)器上，讀取和執(zhí)行更新語句被分成兩個獨立的任務(wù)。當(dāng)從服務(wù)器啟動時，其I/O線程可以很快地從主服務(wù)器索取所有二進(jìn)制日志內(nèi)容。

如下圖：?

以上的數(shù)據(jù)同步方案廣泛的運用在數(shù)據(jù)庫的數(shù)據(jù)一致性問題上，而這也正是我們長久以來一直尋求的解決之道。

具體對應(yīng)到我們的系統(tǒng)，美團直連平臺和供應(yīng)商的關(guān)系為：在供應(yīng)商數(shù)據(jù)產(chǎn)生變化的時候，將變化的部分推送至直連平臺。

聽上去這是個很不錯的方式，但這只是個美好的目標(biāo)。諸多擺在我們面前的問題無法忽略：供應(yīng)商的支持力度低、供應(yīng)商網(wǎng)絡(luò)穩(wěn)定性差、供應(yīng)商系統(tǒng)可用性差。

大思路有了，但是還有很多具體問題，接下來我們就來說說是怎么解決的。

直連產(chǎn)品數(shù)據(jù)一致性的演進(jìn)大致可以分為四個階段，按照落實的時間順序具體的解決方案是： - 從無到有：沒有數(shù)據(jù)全量拉取 - 分而治之：數(shù)據(jù)太多分段拉取 - 精益求精：熱門數(shù)據(jù)分析拉取 - 合作共贏：數(shù)據(jù)變化主動推送

第一階段：從無到有

拉取全量產(chǎn)品數(shù)據(jù)

前期合作的供應(yīng)商經(jīng)濟連鎖集團大都有一個特點，他們會提供一套標(biāo)準(zhǔn)的API給有合作意向的OTA進(jìn)行開發(fā)，供應(yīng)商不會對API進(jìn)行任何邏輯上的修改。

因此，初期我們選取的產(chǎn)品數(shù)據(jù)同步方案為：從無到有，定時拉取供應(yīng)商全量產(chǎn)品數(shù)據(jù)。

應(yīng)用前提：數(shù)據(jù)量級不大，數(shù)據(jù)傳輸效率高，拉取耗時可控。 方案優(yōu)點：開發(fā)周期短，邏輯簡單，串行拉取。 方案缺點：可持續(xù)性差，異?；謴?fù)成本高，對網(wǎng)絡(luò)傳輸?shù)膸捄捅镜卮鎯θ萘恳蟾摺?案例分析：直連平臺每30分鐘主動拉取供應(yīng)商下的全部酒店下全部房型信息以及60天內(nèi)的價格，庫存，售賣取消規(guī)則等信息。

如下圖：

我們使用這個方案在同幾家供應(yīng)商進(jìn)行合作了以后，陸續(xù)發(fā)現(xiàn)存在一些問題： 1. 雙方數(shù)據(jù)存在不一致性的時間跨度超過30分鐘。 2. 30分鐘定時任務(wù)執(zhí)行不完，出現(xiàn)任務(wù)重復(fù)調(diào)起的情況。

獲取信息數(shù)據(jù)量龐大

假設(shè)一家中等規(guī)模的供應(yīng)商有1000家酒店，每個酒店下面有10個房型。 獲取信息數(shù)據(jù)量＝1000（酒店）×10（房型）×60（天數(shù)）＝60W

供應(yīng)商接口速度很慢

供應(yīng)商接口速度很慢?根據(jù)統(tǒng)計，供應(yīng)商接口的平均響應(yīng)時間在兩三秒以上，獲取產(chǎn)品接口由于數(shù)據(jù)量大，可能響應(yīng)時間在幾十秒甚至上百秒。

這時你可能會問：目前定時任務(wù)是每30分鐘調(diào)起一次，縮短定時任務(wù)的調(diào)起時間就可以減少數(shù)據(jù)不一致問題的時間段呢？ 這確實可以解決一部分問題，提前是任務(wù)在短時間就可以執(zhí)行完成。但是對于長時間執(zhí)行無法完成的任務(wù)可能適得其反，過于頻繁的接口調(diào)用，反到把供應(yīng)商的系統(tǒng)壓垮了。 這是我們不愿意看到的，慢總比不能使用來得好些。

第二階段：分而治之

拉取部分產(chǎn)品數(shù)據(jù)

隨著業(yè)務(wù)量的增大，數(shù)據(jù)不斷激增，全量數(shù)據(jù)拉取的缺點將被不斷放大，實效上無法保障業(yè)務(wù)對數(shù)據(jù)一致性的要求。此時，只有主動求變才能有效應(yīng)對，這里我們采取的方案是：分而治之，結(jié)合實際分析拉取部分?jǐn)?shù)據(jù)。

應(yīng)用前提：充分調(diào)研，因地制宜，數(shù)據(jù)可分段獲取。 方案優(yōu)點：同步數(shù)據(jù)體量大幅降低，數(shù)據(jù)準(zhǔn)確度有效提升。 方案缺點：還存在數(shù)據(jù)不一致的時間差。 案例分析：根據(jù)酒店的預(yù)訂特點，調(diào)研了美團用戶的消費習(xí)慣：95%以上的用戶都在預(yù)訂10天內(nèi)的酒店產(chǎn)品。

我們將產(chǎn)品拉取方式調(diào)整了兩種： 固定時間點（例：1點，7點，13點，20點）拉取全量60天的酒店產(chǎn)品數(shù)據(jù)。 每15分鐘拉取10天的酒店產(chǎn)品數(shù)據(jù)（這就好比我們在查詢數(shù)據(jù)庫的時候添加了limit）。 同時調(diào)整拉取規(guī)則，拉取任務(wù)沒有執(zhí)行完成，不再重復(fù)調(diào)起，以減少對供應(yīng)商系統(tǒng)的壓力。

如下圖：

上述方案我們可以簡單的認(rèn)為將拉取的數(shù)據(jù)量和響應(yīng)時間減少了近5/6，同時我們可以根據(jù)供應(yīng)商的服務(wù)能力動態(tài)調(diào)整拉取頻率，例如：2分鐘可以執(zhí)行完的任務(wù)，設(shè)置為每3分鐘拉取一次。 即使因為網(wǎng)絡(luò)抖動等原因引起的任務(wù)時間增加，也不用擔(dān)心任務(wù)重復(fù)調(diào)起壓垮供應(yīng)商系統(tǒng)。

經(jīng)過第二階段，流程演進(jìn)為：

綜上，我們基本實現(xiàn)了不間斷的拉取產(chǎn)品數(shù)據(jù)，同時是用戶高頻進(jìn)行購買的產(chǎn)品，產(chǎn)品數(shù)據(jù)不一致性得大了很大幅度的緩解。

第三階段：精益求精

拉取部分產(chǎn)品數(shù)據(jù)的方案解決了絕大多數(shù)的產(chǎn)品數(shù)據(jù)不一致的問題，但是在2次拉取數(shù)據(jù)的間隔時間差內(nèi)還會存在不一致的問題，會導(dǎo)致用戶在支付之后沒有預(yù)訂到心儀的房型而自動退款，如選擇退回原支付方賬戶，用戶需要等待3～10個工作日，體驗十分不好。

我們迫切需要改進(jìn)該問題，提高用戶體驗。 對于“分而治之”方案的缺憾我們進(jìn)一步思考，尋找到了解決的方案。

為了應(yīng)對間隔時間差的問題，我們的解決的方案是：提前為用戶準(zhǔn)備熱點數(shù)據(jù)。這個主要是靠觸發(fā)式更新（被動）與庫存預(yù)測（主動）來實現(xiàn)。

應(yīng)用前提：摸清定位，準(zhǔn)確匹配，對系統(tǒng)本身有深入的了解，同時對業(yè)務(wù)未來的發(fā)展趨勢有一定的預(yù)測能力。 方案優(yōu)點：數(shù)據(jù)準(zhǔn)確度提高，降低數(shù)據(jù)一致性相關(guān)的資源消耗。 方案缺點：分析成本高，增加了分析數(shù)據(jù)捕獲清洗的系統(tǒng)消耗。 案例分析：基于用戶的訪問行為情況，提前對產(chǎn)品進(jìn)行數(shù)據(jù)更新，為用戶準(zhǔn)備好即將可能要購買的產(chǎn)品。

一、觸發(fā)式更新

1. 基于用戶下單行為更新數(shù)據(jù)

我們從預(yù)訂流程入手，對原有的預(yù)訂流程進(jìn)行分析。 原有流程很簡單，如下：

這其中最主要的問題是：用戶下單時看到的產(chǎn)品是產(chǎn)品緩存，只是依據(jù)產(chǎn)品緩存就讓用戶進(jìn)行了下單購買，這顯然是不可靠的。

需要在用戶下單的時候?qū)Ξa(chǎn)品的正確性進(jìn)行驗證。

針對這個問題，我們對下單流程進(jìn)行優(yōu)化，在用戶進(jìn)行支付前，添加下單前校驗功能，對產(chǎn)品數(shù)據(jù)進(jìn)行校驗（價格，庫存等）。

下單前校驗的底層接口由供應(yīng)商提供，要求實時校驗產(chǎn)品數(shù)據(jù)，不能使用緩存數(shù)據(jù)。

經(jīng)過我們的大力推動與行業(yè)的整體發(fā)展，供應(yīng)商目前都意識到了該問題的重要性，基本都會提供相關(guān)接口以提升用戶體驗。

流程如下，綠色部分為新添加的下單前校驗功能：

同時對于校驗失敗的產(chǎn)品會及時更新產(chǎn)品緩存，避免其他用戶重復(fù)對失效產(chǎn)品進(jìn)行反復(fù)下單。

在完成上述的改造之后，用戶退款單量下降了一個數(shù)量級，由原來每天幾千單下降到了幾百單，用戶體驗大大提升。

那么為什么每天還會有幾百單的退款？

用戶下單前校驗通過后，可能要過一段時間才會支付（支付等待時間，美團App為30分鐘），恰巧在支付的過程中，產(chǎn)品庫存不足或變價都會導(dǎo)致預(yù)訂失敗，在酒店的預(yù)訂旺季問題會更加突出。

針對變價問題，可以優(yōu)化流程告知用戶，用戶可以選擇繼續(xù)購買。

針對庫存不足問題，可以為用戶繼續(xù)推薦其他產(chǎn)品。盡量滿足用戶需求。

以上問題不屬于本文討論范疇，故不再展開討論。

流程演進(jìn)為：

2. 基于用戶瀏覽行為更新數(shù)據(jù)

基于用戶下單行為更新數(shù)據(jù)，解決了“非第一個用戶”重復(fù)下單的問題，但“第一個用戶”被我們犧牲掉了。我們能否為“第一個用戶”做些什么？或者說是如何減少“第一個用戶”的存在？答案是肯定的。 在用戶瀏覽頁面的時候，異步通知直連系統(tǒng)，為用戶提前準(zhǔn)備可能購買產(chǎn)品的相關(guān)數(shù)據(jù)，如下圖：

在這里有個策略問題：直連酒店詳情頁的瀏覽每天有幾千萬次，直連系統(tǒng)提供的異步接口QPS可以達(dá)到幾百，過濾后的訪問量也還是很大，將這些訪問量全部轉(zhuǎn)化成對于供應(yīng)商系統(tǒng)的數(shù)據(jù)拉取，會導(dǎo)致供應(yīng)商系統(tǒng)過載，甚至崩潰。這里我們針對每個不同的供應(yīng)商設(shè)置一個“數(shù)據(jù)最小拉取時長”，小于該時長的訪問，不再重復(fù)進(jìn)行拉取，以減少供應(yīng)商系統(tǒng)的訪問次數(shù)。

例：P供應(yīng)商，設(shè)置數(shù)據(jù)拉取時長為60秒。

A用戶在10:00:00時訪問H酒店的列表頁，異步更新酒店產(chǎn)品數(shù)據(jù)。B用戶在10:00:59訪問H酒店的列表頁，不進(jìn)行更新。C用戶在10:01:01訪問H酒店的列表頁，異步更新酒店產(chǎn)品數(shù)據(jù)。

流程演進(jìn)為：

至此，我們已經(jīng)解決了產(chǎn)品數(shù)據(jù)拉取的絕大多數(shù)問題，基本可以保證用戶的正常購買。

二、庫存預(yù)測

謀求數(shù)據(jù)一致性提升必定帶來系統(tǒng)成本的消耗，如何降低系統(tǒng)運行成本將是未來我們需要思考的方向。

數(shù)據(jù)的有效預(yù)測可以幫助我們很大程度上降低成本消耗。

仍以美團直連平臺為例，觸發(fā)式更新確實解決了“第一個用戶”的問題，雖然我們使用了“數(shù)據(jù)最小拉取時長”的方案，但新增大量訪問對供應(yīng)商系統(tǒng)還是造成一定的壓力。

如：P供應(yīng)商，包含1000家酒店，數(shù)據(jù)最小拉取時長為：120秒。 訪問量：1000（酒店數(shù)量）×30（每小時訪問次數(shù)）×24（每天24小時）=720000

是不是有辦法減少訪問次數(shù)？同時盡量避免減少訪問數(shù)次對用戶的影響？答案也是肯定的。

我們抽象一下問題即為：在數(shù)據(jù)過載的前提下，及時為用戶提供有意愿購買的產(chǎn)品信息。

那么什么是用戶有意愿購買的產(chǎn)品呢？ 可以簡單的根據(jù)二八定律（20%的產(chǎn)品會給我們帶來80%的收益），來維護(hù)這20%的頭部產(chǎn)品數(shù)據(jù)，來達(dá)到我們的目的。

這20%的頭部產(chǎn)品數(shù)據(jù)怎么獲取？單純的已瀏覽量和訂單量，好像都不太正確。 回看一下問題中的關(guān)鍵詞：數(shù)據(jù)過載，有意愿購買，產(chǎn)品信息，這些關(guān)鍵詞都指向了一個明確的實現(xiàn)方案——推薦系統(tǒng)。

推薦系統(tǒng)常規(guī)的使用方式向用戶推薦用戶感興趣的信息和商品。 我們這里對推薦系統(tǒng)進(jìn)行靈活運用，當(dāng)預(yù)測到用戶對某些信息或商品感興趣時，為用戶提前準(zhǔn)備好信息或商品數(shù)據(jù)。

推薦系統(tǒng)架構(gòu)圖：

我們可以根據(jù)購買歷史、價格區(qū)間、重點商圈、熱銷品牌等產(chǎn)品多維度信息，使用基于物品的協(xié)同過濾算法，區(qū)分出高中低頻用戶有意愿購買的產(chǎn)品，實現(xiàn)不同的數(shù)據(jù)拉取頻率，以降低供應(yīng)商接口的訪問次數(shù)。 如果我們面臨的屬性維度極其復(fù)雜，要分析的數(shù)據(jù)量也十分巨大的時候，協(xié)同過濾算法可能就不適用了，這時可以考慮基于深度神經(jīng)網(wǎng)絡(luò)的推薦系統(tǒng)。

關(guān)于推薦系統(tǒng)這里不再展開講述。

流程演進(jìn)為：

目前該方案我們還沒有實現(xiàn)，但這是我們的發(fā)展方向。

第四階段：合作共贏

雖然我們一直致力于完善我方系統(tǒng)提高數(shù)據(jù)一致性，但不可否認(rèn)的是，最有效的手段還是謀求合作雙方的合作，而這往往是個長期、艱苦卓絕、潛移默化的過程。雖然有著共同的目標(biāo)，但由于工作量的增加對方往往并不積極配合，推動合作方系統(tǒng)的改進(jìn)工作通常十分艱難。當(dāng)然，這并不能阻止我們不斷前進(jìn)的步伐，我們在實踐中逐漸摸索出一套方案，那就是：建立有效的溝通渠道＋有力的技術(shù)支持。

合作方數(shù)據(jù)主動推送

應(yīng)用前提：保持良好的溝通渠道，開發(fā)接口具備便利性和標(biāo)準(zhǔn)化。 方案優(yōu)點：降低系統(tǒng)的訪問次數(shù)，維護(hù)成本降低，數(shù)據(jù)準(zhǔn)確度提升。 方案缺點：需要提供接入的標(biāo)準(zhǔn)API，同時溝通成本較高。 案例分析：在我們和供應(yīng)商合作的過程中，經(jīng)過我們的不斷推動，供應(yīng)商也意識到了，當(dāng)數(shù)據(jù)發(fā)生變化時，主動推送數(shù)據(jù)給我們是最好的解決方案。

如圖：

主動推送數(shù)數(shù)據(jù)其優(yōu)勢表現(xiàn)在： - 減少服務(wù)訪問次數(shù)，降低服務(wù)壓力，服務(wù)更加穩(wěn)定。 - 預(yù)訂成功率上升，訂單增多，收益也就增多。

酒店開放平臺在適宜的時候開始提供標(biāo)準(zhǔn)API，部分有技術(shù)能力的供應(yīng)商開始進(jìn)行接入。

接入前為供應(yīng)商提供統(tǒng)一的網(wǎng)站入口，提供接入文檔，在線測試工具，常見問題答疑，在線問題解答等多方面的接入支持。

接入后提供數(shù)據(jù)分析平臺，對接入數(shù)據(jù)實時進(jìn)行統(tǒng)計。

采取以上措施之后，供應(yīng)商對接入更加可控，線上產(chǎn)品運營情況更加透明。這樣一來，供應(yīng)商的接入意愿就有了極大的提升。

演化后的流程為：

通過對獲取產(chǎn)品數(shù)據(jù)功能的持續(xù)改造，使得直連系統(tǒng)為用戶提供了可靠的數(shù)據(jù)來源。

總結(jié)一下上述四個階段使用的數(shù)據(jù)的更新方式，分別為： - 觸發(fā)式 - 被動拉取 - 主動推送

直連數(shù)據(jù)一致性問題改造后，直連數(shù)據(jù)同步的架構(gòu)如下所示：

數(shù)據(jù)一致性的問題是O2O行業(yè)中最常見的問題，掌握一套有效的解決方案對項目建設(shè)，尤其是系統(tǒng)對接類的項目建設(shè)尤為重要。這里為大家介紹的是美團酒店直連平臺應(yīng)對此類問題時的具體實踐。其中，隨著項目規(guī)模變化而采取不同的應(yīng)對方法是我認(rèn)為最值得借鑒的地方。四個階段的論述之前我分別對應(yīng)用前提、方案優(yōu)點、方案缺點加以說明，旨在讓大家更有針對性的比對，結(jié)合自身系統(tǒng)現(xiàn)狀予以應(yīng)用。接著通過美團酒店直連平臺的案例進(jìn)行分析，從而方便大家更直觀的理解。

美團酒店直連平臺的成長是個充滿挑戰(zhàn)的過程，通過鉆研和磨礪，平臺的健壯性和運行效率顯著提升。受篇幅的限制，很多細(xì)節(jié)無法詳盡描述，數(shù)據(jù)一致性問題的解決也絕非一篇博文就能面面俱到，好的方案還需因地制宜才能充分發(fā)揮效用。上述供應(yīng)商技術(shù)能力不足的問題，可以通過對方案靈活組合運用來解決。而對于此類相關(guān)的疑問，歡迎各位留言共同探討。

技術(shù)平臺的建設(shè)和維護(hù)，是個道阻且長的過程，數(shù)據(jù)一致性的問題僅僅是滄海一粟。希望這篇博文在數(shù)據(jù)一致性問題上可以為大家提供一些思路和借鑒。

CSDN博客，《MySQL主從備份及原理分析》，2012.

CSDN博客，《推薦算法之基于物品的協(xié)同過濾算法》，2014.

大數(shù)據(jù)雜談，《推薦系統(tǒng)實踐與優(yōu)化》，2016.

大數(shù)據(jù)雜談，《用一個大家都懂的方式來聊聊YouTube基于深度神經(jīng)網(wǎng)絡(luò)的推薦系統(tǒng)》，2016.

百度百科，推薦系統(tǒng).

總結(jié)

以上是生活随笔為你收集整理的美团酒店直连产品数据一致性演进的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。