美团酒店直连产品数据一致性演进
美團酒店直連項目自2013年末開始，通過業務上的不斷完善和技術上的不斷改進，至今已經接入200多家供應商，其中在線酒店3萬以上，在線SPU30萬以上。經過兩年的成長，美團酒店直連平臺終于在2015年末發展為國內最大的酒店直連業務平臺，其接入的業務類型也從最初的經濟連鎖，拓展到高星渠道、小連鎖集團、非標準住宿等，獲得了業界一致好評。
隨著美團的日益壯大，客戶的需求和系統體量的不斷增加，直連平臺的技術架構和數據應用面臨著諸多挑戰。為了保障美團的用戶體驗度，對技術方面會提出更高的要求。 - 如何在合作方接口極不穩定的情況下保持高可用效果？ - 如何在不影響系統穩定性的前提下提升接口響應時間？ - 如何解決龐大數據帶來的一致性問題的同時降低系統運營風險？
這些是直連平臺每天都在思考的問題。技術平臺和數據應用的改進完善并非一蹴而就。考慮到數據是業務運營的核心，這里先以產品數據一致性問題的解決方案作為切入點與大家分享，也希望借此拋磚引玉，歡迎更多的同學一起探討，共同進步。
為了使數據一致性完善方案更直觀易懂，這里引用美團酒店直連項目中直連平臺與供應商酒店產品數據一致性方案作為分析案例，通過面臨問題、總體思路、解決方案和總結思考四個方面進行論述。
酒店直連系統的主要工作是將供應商的酒店產品（房型），通過系統對接的方式，轉化為美大點評平臺可以售賣的產品（房型）。
酒店產品購買是一個可預訂日期跨度比較長的業務。以美團App為例，可以預訂60天內的酒店。
因此我們的系統需要將供應商全部酒店全部房型信息以及60天內的價格、庫存、售賣取消規則等信息，獲取到我方，落地后形成產品數據，一則用在C端給用戶進行展示，二則參與交易環節。
下圖為產品供給流向圖：
問題：直連系統在上單流程中如何保證產品緩存與供應商系統的數據一致性？
上述面臨的情況很像數據庫的主從同步問題，那我們是不是可以借鑒主從同步的方式來解決該問題呢？我們來看一下MySQL主從備份的實現細節：
MySQL使用3個線程來執行復制功能（其中1個在主服務器上，另2個在從服務器上）。當開始同步時，從服務器開始創建一個I/O線程，以連接主服務器，并且讓主服務器發送在其二進制日志中的語句。主服務器創建一個線程將二進制日志中的內容發送到從服務器。 該線程即為主服務器上show processlist輸出中的Binlog Dump線程。從服務器I/O線程讀取主服務器Binlog Dump線程發送的內容，并將該數據復制到從服務器數據目錄中的本地文件（即中繼日志）中。 第3個線程是SQL線程，由從服務器創建，用于讀取中繼日志并執行日志中包含的更新。 在從服務器上，讀取和執行更新語句被分成兩個獨立的任務。當從服務器啟動時，其I/O線程可以很快地從主服務器索取所有二進制日志內容。
如下圖：?
以上的數據同步方案廣泛的運用在數據庫的數據一致性問題上，而這也正是我們長久以來一直尋求的解決之道。
具體對應到我們的系統，美團直連平臺和供應商的關系為：在供應商數據產生變化的時候，將變化的部分推送至直連平臺。
聽上去這是個很不錯的方式，但這只是個美好的目標。諸多擺在我們面前的問題無法忽略：供應商的支持力度低、供應商網絡穩定性差、供應商系統可用性差。
大思路有了，但是還有很多具體問題，接下來我們就來說說是怎么解決的。
直連產品數據一致性的演進大致可以分為四個階段，按照落實的時間順序具體的解決方案是： - 從無到有：沒有數據全量拉取 - 分而治之：數據太多分段拉取 - 精益求精：熱門數據分析拉取 - 合作共贏：數據變化主動推送
第一階段：從無到有
拉取全量產品數據
前期合作的供應商經濟連鎖集團大都有一個特點，他們會提供一套標準的API給有合作意向的OTA進行開發，供應商不會對API進行任何邏輯上的修改。
因此，初期我們選取的產品數據同步方案為：從無到有，定時拉取供應商全量產品數據。
應用前提：數據量級不大，數據傳輸效率高，拉取耗時可控。 方案優點：開發周期短，邏輯簡單，串行拉取。 方案缺點：可持續性差，異常恢復成本高，對網絡傳輸的帶寬和本地存儲容量要求高。 案例分析：直連平臺每30分鐘主動拉取供應商下的全部酒店下全部房型信息以及60天內的價格，庫存，售賣取消規則等信息。
如下圖：
我們使用這個方案在同幾家供應商進行合作了以后，陸續發現存在一些問題： 1. 雙方數據存在不一致性的時間跨度超過30分鐘。 2. 30分鐘定時任務執行不完，出現任務重復調起的情況。
獲取信息數據量龐大
假設一家中等規模的供應商有1000家酒店，每個酒店下面有10個房型。 獲取信息數據量＝1000（酒店）×10（房型）×60（天數）＝60W
供應商接口速度很慢
供應商接口速度很慢?根據統計，供應商接口的平均響應時間在兩三秒以上，獲取產品接口由于數據量大，可能響應時間在幾十秒甚至上百秒。
這時你可能會問：目前定時任務是每30分鐘調起一次，縮短定時任務的調起時間就可以減少數據不一致問題的時間段呢？ 這確實可以解決一部分問題，提前是任務在短時間就可以執行完成。但是對于長時間執行無法完成的任務可能適得其反，過于頻繁的接口調用，反到把供應商的系統壓垮了。 這是我們不愿意看到的，慢總比不能使用來得好些。
第二階段：分而治之
拉取部分產品數據
隨著業務量的增大，數據不斷激增，全量數據拉取的缺點將被不斷放大，實效上無法保障業務對數據一致性的要求。此時，只有主動求變才能有效應對，這里我們采取的方案是：分而治之，結合實際分析拉取部分數據。
應用前提：充分調研，因地制宜，數據可分段獲取。 方案優點：同步數據體量大幅降低，數據準確度有效提升。 方案缺點：還存在數據不一致的時間差。 案例分析：根據酒店的預訂特點，調研了美團用戶的消費習慣：95%以上的用戶都在預訂10天內的酒店產品。
我們將產品拉取方式調整了兩種： 固定時間點（例：1點，7點，13點，20點）拉取全量60天的酒店產品數據。 每15分鐘拉取10天的酒店產品數據（這就好比我們在查詢數據庫的時候添加了limit）。 同時調整拉取規則，拉取任務沒有執行完成，不再重復調起，以減少對供應商系統的壓力。
如下圖：
上述方案我們可以簡單的認為將拉取的數據量和響應時間減少了近5/6，同時我們可以根據供應商的服務能力動態調整拉取頻率，例如：2分鐘可以執行完的任務，設置為每3分鐘拉取一次。 即使因為網絡抖動等原因引起的任務時間增加，也不用擔心任務重復調起壓垮供應商系統。
經過第二階段，流程演進為：
綜上，我們基本實現了不間斷的拉取產品數據，同時是用戶高頻進行購買的產品，產品數據不一致性得大了很大幅度的緩解。
第三階段：精益求精
拉取部分產品數據的方案解決了絕大多數的產品數據不一致的問題，但是在2次拉取數據的間隔時間差內還會存在不一致的問題，會導致用戶在支付之后沒有預訂到心儀的房型而自動退款，如選擇退回原支付方賬戶，用戶需要等待3～10個工作日，體驗十分不好。
我們迫切需要改進該問題，提高用戶體驗。 對于“分而治之”方案的缺憾我們進一步思考，尋找到了解決的方案。
為了應對間隔時間差的問題，我們的解決的方案是：提前為用戶準備熱點數據。這個主要是靠觸發式更新（被動）與庫存預測（主動）來實現。
應用前提：摸清定位，準確匹配，對系統本身有深入的了解，同時對業務未來的發展趨勢有一定的預測能力。 方案優點：數據準確度提高，降低數據一致性相關的資源消耗。 方案缺點：分析成本高，增加了分析數據捕獲清洗的系統消耗。 案例分析：基于用戶的訪問行為情況，提前對產品進行數據更新，為用戶準備好即將可能要購買的產品。
一、觸發式更新
1. 基于用戶下單行為更新數據
我們從預訂流程入手，對原有的預訂流程進行分析。 原有流程很簡單，如下：
這其中最主要的問題是：用戶下單時看到的產品是產品緩存，只是依據產品緩存就讓用戶進行了下單購買，這顯然是不可靠的。
需要在用戶下單的時候對產品的正確性進行驗證。
針對這個問題，我們對下單流程進行優化，在用戶進行支付前，添加下單前校驗功能，對產品數據進行校驗（價格，庫存等）。
下單前校驗的底層接口由供應商提供，要求實時校驗產品數據，不能使用緩存數據。
經過我們的大力推動與行業的整體發展，供應商目前都意識到了該問題的重要性，基本都會提供相關接口以提升用戶體驗。
流程如下，綠色部分為新添加的下單前校驗功能：
同時對于校驗失敗的產品會及時更新產品緩存，避免其他用戶重復對失效產品進行反復下單。
在完成上述的改造之后，用戶退款單量下降了一個數量級，由原來每天幾千單下降到了幾百單，用戶體驗大大提升。
那么為什么每天還會有幾百單的退款？
用戶下單前校驗通過后，可能要過一段時間才會支付（支付等待時間，美團App為30分鐘），恰巧在支付的過程中，產品庫存不足或變價都會導致預訂失敗，在酒店的預訂旺季問題會更加突出。
針對變價問題，可以優化流程告知用戶，用戶可以選擇繼續購買。
針對庫存不足問題，可以為用戶繼續推薦其他產品。盡量滿足用戶需求。
以上問題不屬于本文討論范疇，故不再展開討論。
流程演進為：
2. 基于用戶瀏覽行為更新數據
基于用戶下單行為更新數據，解決了“非第一個用戶”重復下單的問題，但“第一個用戶”被我們犧牲掉了。我們能否為“第一個用戶”做些什么？或者說是如何減少“第一個用戶”的存在？答案是肯定的。 在用戶瀏覽頁面的時候，異步通知直連系統，為用戶提前準備可能購買產品的相關數據，如下圖：
在這里有個策略問題：直連酒店詳情頁的瀏覽每天有幾千萬次，直連系統提供的異步接口QPS可以達到幾百，過濾后的訪問量也還是很大，將這些訪問量全部轉化成對于供應商系統的數據拉取，會導致供應商系統過載，甚至崩潰。這里我們針對每個不同的供應商設置一個“數據最小拉取時長”，小于該時長的訪問，不再重復進行拉取，以減少供應商系統的訪問次數。
例：P供應商，設置數據拉取時長為60秒。
A用戶在10:00:00時訪問H酒店的列表頁，異步更新酒店產品數據。B用戶在10:00:59訪問H酒店的列表頁，不進行更新。C用戶在10:01:01訪問H酒店的列表頁，異步更新酒店產品數據。流程演進為：
至此，我們已經解決了產品數據拉取的絕大多數問題，基本可以保證用戶的正常購買。
二、庫存預測
謀求數據一致性提升必定帶來系統成本的消耗，如何降低系統運行成本將是未來我們需要思考的方向。
數據的有效預測可以幫助我們很大程度上降低成本消耗。
仍以美團直連平臺為例，觸發式更新確實解決了“第一個用戶”的問題，雖然我們使用了“數據最小拉取時長”的方案，但新增大量訪問對供應商系統還是造成一定的壓力。
如：P供應商，包含1000家酒店，數據最小拉取時長為：120秒。 訪問量：1000（酒店數量）×30（每小時訪問次數）×24（每天24小時）=720000
是不是有辦法減少訪問次數？同時盡量避免減少訪問數次對用戶的影響？答案也是肯定的。
我們抽象一下問題即為：在數據過載的前提下，及時為用戶提供有意愿購買的產品信息。
那么什么是用戶有意愿購買的產品呢？ 可以簡單的根據二八定律（20%的產品會給我們帶來80%的收益），來維護這20%的頭部產品數據，來達到我們的目的。
這20%的頭部產品數據怎么獲取？單純的已瀏覽量和訂單量，好像都不太正確。 回看一下問題中的關鍵詞：數據過載，有意愿購買，產品信息，這些關鍵詞都指向了一個明確的實現方案——推薦系統。
推薦系統常規的使用方式向用戶推薦用戶感興趣的信息和商品。 我們這里對推薦系統進行靈活運用，當預測到用戶對某些信息或商品感興趣時，為用戶提前準備好信息或商品數據。
推薦系統架構圖：
我們可以根據購買歷史、價格區間、重點商圈、熱銷品牌等產品多維度信息，使用基于物品的協同過濾算法，區分出高中低頻用戶有意愿購買的產品，實現不同的數據拉取頻率，以降低供應商接口的訪問次數。 如果我們面臨的屬性維度極其復雜，要分析的數據量也十分巨大的時候，協同過濾算法可能就不適用了，這時可以考慮基于深度神經網絡的推薦系統。
關于推薦系統這里不再展開講述。
流程演進為：
目前該方案我們還沒有實現，但這是我們的發展方向。
第四階段：合作共贏
雖然我們一直致力于完善我方系統提高數據一致性，但不可否認的是，最有效的手段還是謀求合作雙方的合作，而這往往是個長期、艱苦卓絕、潛移默化的過程。雖然有著共同的目標，但由于工作量的增加對方往往并不積極配合，推動合作方系統的改進工作通常十分艱難。當然，這并不能阻止我們不斷前進的步伐，我們在實踐中逐漸摸索出一套方案，那就是：建立有效的溝通渠道＋有力的技術支持。
合作方數據主動推送
應用前提：保持良好的溝通渠道，開發接口具備便利性和標準化。 方案優點：降低系統的訪問次數，維護成本降低，數據準確度提升。 方案缺點：需要提供接入的標準API，同時溝通成本較高。 案例分析：在我們和供應商合作的過程中，經過我們的不斷推動，供應商也意識到了，當數據發生變化時，主動推送數據給我們是最好的解決方案。
如圖：
主動推送數數據其優勢表現在： - 減少服務訪問次數，降低服務壓力，服務更加穩定。 - 預訂成功率上升，訂單增多，收益也就增多。
酒店開放平臺在適宜的時候開始提供標準API，部分有技術能力的供應商開始進行接入。
接入前為供應商提供統一的網站入口，提供接入文檔，在線測試工具，常見問題答疑，在線問題解答等多方面的接入支持。
接入后提供數據分析平臺，對接入數據實時進行統計。
采取以上措施之后，供應商對接入更加可控，線上產品運營情況更加透明。這樣一來，供應商的接入意愿就有了極大的提升。
演化后的流程為：
通過對獲取產品數據功能的持續改造，使得直連系統為用戶提供了可靠的數據來源。
總結一下上述四個階段使用的數據的更新方式，分別為： - 觸發式 - 被動拉取 - 主動推送
直連數據一致性問題改造后，直連數據同步的架構如下所示：
數據一致性的問題是O2O行業中最常見的問題，掌握一套有效的解決方案對項目建設，尤其是系統對接類的項目建設尤為重要。這里為大家介紹的是美團酒店直連平臺應對此類問題時的具體實踐。其中，隨著項目規模變化而采取不同的應對方法是我認為最值得借鑒的地方。四個階段的論述之前我分別對應用前提、方案優點、方案缺點加以說明，旨在讓大家更有針對性的比對，結合自身系統現狀予以應用。接著通過美團酒店直連平臺的案例進行分析，從而方便大家更直觀的理解。
美團酒店直連平臺的成長是個充滿挑戰的過程，通過鉆研和磨礪，平臺的健壯性和運行效率顯著提升。受篇幅的限制，很多細節無法詳盡描述，數據一致性問題的解決也絕非一篇博文就能面面俱到，好的方案還需因地制宜才能充分發揮效用。上述供應商技術能力不足的問題，可以通過對方案靈活組合運用來解決。而對于此類相關的疑問，歡迎各位留言共同探討。
技術平臺的建設和維護，是個道阻且長的過程，數據一致性的問題僅僅是滄海一粟。希望這篇博文在數據一致性問題上可以為大家提供一些思路和借鑒。
總結
以上是生活随笔為你收集整理的美团酒店直连产品数据一致性演进的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spring Cloud构建微服务架构：
- 下一篇： 消息中间件系列(五)：MQ消息队列的12