基于實時價格計算的電商檢索系統(tǒng)

1、實時計算價格庫存的酒店電商檢索系統(tǒng)靜態(tài)價電商 vs 動態(tài)價類電商不同點基礎(chǔ)數(shù)據(jù)規(guī)模靜態(tài)類2個數(shù)動態(tài)類180 x 30 x 2促銷形式打標的方式，訂單環(huán)境促銷復雜組合參與最終(立減、返券、紅包） 計算價格第三方維度動態(tài)因素計算預訂渠道、會員級別等預訂窗口、周中周末、上下午等一些數(shù)字 僅庫存價格的數(shù)據(jù)規(guī)模 50w酒店*50產(chǎn)品*180天*30天*2 = 2700億 4byte去存儲這類數(shù)字 = 1054G 業(yè)務邏輯復雜 一百多張數(shù)據(jù)庫表的復雜依賴一些數(shù)字 酒店每日檢索規(guī)模： 128億/日 3.31數(shù)據(jù)： 12790132 * 1000 + 98953965 產(chǎn)品每日計算規(guī)模： 3840億次/日 平

2、均30個產(chǎn)品 一個酒店庫存價格計算在1ms，那么搜索北京1w酒店？注：16年3月底，流量低峰數(shù)據(jù)傳統(tǒng)方案A 思路：DB+Cache 基于數(shù)據(jù)庫處理業(yè)務邏輯 結(jié)果全部cache 瓶頸 冷query非常慢 單機吞吐量低 Cache時效性延遲 擴展性差傳統(tǒng)方案B 思路：業(yè)務內(nèi)存 + “智能”cache DB數(shù)據(jù)盡可能內(nèi)存化 cache盡可能智能 業(yè)務有損折中 瓶頸 資源高消耗（內(nèi)存、cpu） 無法100%準確 事務一致性維護困難elong實踐 架構(gòu)要滿足業(yè)務的痛點 數(shù)據(jù)一致性 時效性，尤其高峰期 服務能力水平擴展 思路 單機能力提升可擴展 單機內(nèi)部、多機之間要做到“一致性” 時效性區(qū)分重要性分別滿足

3、數(shù)據(jù)一致性&時效性 困難 缺乏傳統(tǒng)db的事務支持 過度的性能優(yōu)化依靠cache 多機之間的cache 解決方案 放棄部分性能，回避cache的復雜度 引入數(shù)據(jù)的版本來控制一致性 分粒度（小時、分鐘、秒）保證時效性數(shù)據(jù)一致性&時效性數(shù)據(jù)一致性&時效性同一個消息先后抵達同一個消息同時抵達前后兩個消息逆序到達兒子消息比父消息先到單機能力 內(nèi)存如何瘦身 計算如何更快單機能力 內(nèi)存瘦身方面的困難 數(shù)據(jù)量客觀規(guī)模很大 數(shù)據(jù)引入版本后壓縮效率降低 解決方法 利用信息量低做索引壓縮 分版本壓縮優(yōu)化 Sharding, 按天數(shù)，按酒店分組Sharding和分組單機能力 計算能力方面的困難 某些極限搜索計算量巨大 機器負載低利用率不高 解決方法 利用負載低做并行計算 Sharding, 按酒店 業(yè)務層面無損、有損優(yōu)化實際指標 CPU：單日高峰20%的利用率 內(nèi)存：單實例20G（90天） 時效性： 變價率+滿房率從5%下降到0.5%（實際更低） 列表頁平均響應時間下降一個數(shù)量級總結(jié) cache要純粹, 復