去哪兒酒店實時搜索技術(shù)分享

阿里技術(shù)沙龍 去哪兒酒店搜索分享 關(guān)于去哪兒酒店搜索 定位 垂直搜索平臺 目標(biāo) Smart Your Hotel Reservation 目前規(guī)模 搜索 210家酒店預(yù)訂站點 支持全球 22699個城市 覆蓋 368892家酒店 主要議題 系統(tǒng)的核心功能 酒店信息的搜索 酒店報價和房態(tài)的實時準(zhǔn)確 高可用性 系統(tǒng)設(shè)計上的考慮 圍繞著核心功能目標(biāo)我們做了些什么 整體結(jié)構(gòu)服務(wù)化拆分 實時抓取 系統(tǒng)結(jié)構(gòu)總覽 整體結(jié)構(gòu)服務(wù)化拆分 現(xiàn)有主要服務(wù) 頁面展現(xiàn)功能服務(wù) 關(guān)鍵詞搜索服務(wù) rank計算服務(wù) 報價服務(wù) 報價抓取和調(diào)度服務(wù) 拆分原則 功能模塊相對獨立 功能內(nèi)聚 目的 降低維護成本 提高系統(tǒng)整體可用性 故障隔離 服務(wù)降級 實時抓取 實時抓取的需求 酒店的價格和房態(tài) ， 尤其是房態(tài)變化快 價格和房態(tài)的準(zhǔn)確性是保證用戶的搜索體驗的前提條件 實時抓取的難點 保證用戶請求的響應(yīng)效率 保證用戶看到最新的價格和房態(tài) 降低對目標(biāo)網(wǎng)站的抓取量 實時抓取 實時抓取核心服務(wù)組件 報價服務(wù) 抓取服務(wù) 消息中間件 分布式存儲 實時抓取 當(dāng)前規(guī)模 報價服務(wù)每秒請求量峰值近 1500qps 報價服務(wù)平均請求響應(yīng)時間 2.7ms 報價抓取服務(wù)平均每秒處理完成 2500個抓取請求 報價服務(wù)平均 20分鐘一次 full gc 報價服務(wù)平均 10s一次 young gc 報價服務(wù) 15分鐘負(fù)載峰值 3-3.5，平均 1.2-1.5 實時抓取 我們?nèi)绾巫龅降?服務(wù)拆分 異步化 緩存設(shè)計 降低抓取量 實時抓取 -服務(wù)拆分 服務(wù)拆分 報價服務(wù)和抓取服務(wù)分拆 功能側(cè)重點不同 報價服務(wù) 緩存 +計算系統(tǒng) 對外接口響應(yīng)時間是關(guān)鍵 抓取服務(wù) 定向抓取 整體吞吐量和獲取率是關(guān)鍵 典型的生產(chǎn)者消費者場景 異步通訊 實時抓取 -異步化 異步化 消息中間件 線程池隔離 前端 js動態(tài)請求 實時抓取 -消息中間件 消息中間件 用于報價服務(wù)和抓取服務(wù)之間的通訊 方案選擇 activemq 配置考量 不需要持久化 過期消息可以丟棄 直接丟棄 提高吞吐量 async send & async ack 接收到消息后異步處理 需要 failover client端連接串配置成 failover協(xié)議 實時抓取 -消息中間件 實時抓取 -線程池隔離 線程池隔離 目的 獨立任務(wù)串行執(zhí)行轉(zhuǎn)并行執(zhí)行，提高性能 最大限度降低外部資源依賴失效的影響 使得整體吞吐量和響應(yīng)時間可控 避免資源爭用 關(guān)注點 線程池容量合理設(shè)置 任務(wù)超時設(shè)置 利用監(jiān)控，持續(xù)運維 實時抓取 -線程池隔離 應(yīng)用場景一 背景 用戶提交一個酒店搜索，搜索列表頁在得到符合條件的酒店列表后，需要遠(yuǎn)程調(diào)用報價服務(wù)的接口獲取酒店報價 報價服務(wù)的任何問題都不能影響到搜索結(jié)果列表頁的展示 如果結(jié)果列表酒店數(shù)量太多，報價服務(wù)串行獲取報價效率較低，調(diào)用方等待時間較長 實時抓取 -線程池隔離 應(yīng)用場景一 解決方案 單獨創(chuàng)建一個線程池來處理對報價服務(wù)的調(diào)用 對于超過一定閾值的酒店數(shù)的報價查詢請求，拆成多個任務(wù)執(zhí)行 設(shè)計考量 線程池參數(shù)選擇 任務(wù)超時設(shè)置 經(jīng)驗值，我們一般是選擇被調(diào)用方響應(yīng)時間 *10 超時后處理 任務(wù)需要能夠響應(yīng)中斷 超時后要回收資源 超時后需要將調(diào)用條件記錄到日志中，供線下分析 實時抓取 -線程池隔離 應(yīng)用場景一 設(shè)計考量 線程池參數(shù)選擇 corePoolSize 該請求 qps歷史峰值 *增長系數(shù) *調(diào)用外部接口任務(wù)超時時間（ s） queue LinkedBlockingQueue，無界隊列，資源不可控，不考慮 ArrayBlockingQueue，線下任務(wù)，只考慮吞吐量而不關(guān)注響應(yīng)時間時使用 SynchronousQueue， Direct handoff，有任務(wù)立即嘗試開線程執(zhí)行，在關(guān)注響應(yīng)時間時選擇 maxPoolSize max(該請求 qps歷史峰值 *增長系數(shù) , corePoolSize) rejection policy 直接丟棄 記錄監(jiān)控 實時抓取 -線程池隔離 應(yīng)用場景二 背景 報價抓取服務(wù)從消息隊列中接收到消息執(zhí)行抓取 各個目標(biāo)網(wǎng)站的響應(yīng)時間，所能承受的抓取量以及并發(fā)度不一 實時抓取 -線程池隔離 應(yīng)用場景二 解決方案 異步處理消息，提高消息接收速度，提高消息隊列吞吐量 各個目標(biāo)網(wǎng)站的抓取走各自獨立的線程池，防止對某一個網(wǎng)站的抓取出現(xiàn)問題影響到對別的網(wǎng)站的抓取請求 設(shè)計考量 線程池的容量設(shè)置 對方網(wǎng)站所能承受的并發(fā)量 單次抓取請求的響應(yīng)時間 吞吐量優(yōu)先，使用有界隊列來盡量避免請求丟棄 實時調(diào)整線程池容量設(shè)置 對每一個目標(biāo)網(wǎng)站的抓取任務(wù)線程池做監(jiān)控 實時抓取 -前端 js動態(tài)請求 目的 將最新報價及時展現(xiàn)給用戶 設(shè)計考量 前端 javascript在有限的時間范圍內(nèi)按照一定時間間隔 poll報價服務(wù)接口 poll的間隔根據(jù)以下因素動態(tài)改變 發(fā)送的報價抓取請求回數(shù)比例 隨時間衰減 報價服務(wù)接口連續(xù)返回相同結(jié)果集的次數(shù) 實施抓取 -緩存設(shè)計 目的 提高整體性能 減少外部資源依賴，提高可用性 緩存分類 基礎(chǔ)信息緩存 緩存所有常用信息字段 全量緩存 系統(tǒng)啟動時加載 lazy initialization is evil here 增量更新 報價緩存 進程內(nèi)緩存 LRU 減小并發(fā)鎖顆粒度 分布式緩存 memcached 實施抓取 -緩存設(shè)計 幾點體會 內(nèi)存緩存 關(guān)注單個緩存對象的大小 要正確的使用數(shù)據(jù)類型 值域固定的字符串對象常量化 Sern() 自定義 String Pool 要監(jiān)控緩存命中率 要估算總的內(nèi)存開銷 緩存池要有容量上限 對于 LRU緩存，不同業(yè)務(wù)數(shù)據(jù)盡量不要共用同一 LRU隊列 memcached 需要關(guān)注 memcached的內(nèi)存分配機制 memcached的操作也是外部資源訪問，要有超時設(shè)置 關(guān)鍵業(yè)務(wù)數(shù)據(jù)最好獨占一組 memcached，防止類似大小的不同業(yè)務(wù)數(shù)據(jù)緩存爭用同一 slab，導(dǎo)致 eviction 監(jiān)控 實時抓取 -降低抓取量 目的 降低目標(biāo)網(wǎng)站的負(fù)載 手段 為每個目標(biāo)網(wǎng)站設(shè)置 cachetime 依據(jù)當(dāng)前抓取量監(jiān)控 依據(jù)目標(biāo)網(wǎng)站房態(tài)房價變化頻率監(jiān)控 人工配置 +動態(tài)調(diào)整 定時線下全量抓取配合線上用戶觸發(fā)抓取 與合作客戶配合進行變價推送 運維和監(jiān)控 “ Life is like a box of chocolate, and you will never know what you are gonna get” -THIS SHOULD NOT HAPPEN TO ONLINE SYSTEM 運維和監(jiān)控 意義 好的系統(tǒng)是運維出來的 及時發(fā)現(xiàn)問題 掌握系統(tǒng)運行狀況 找出系統(tǒng)優(yōu)化方向 掌握業(yè)務(wù)數(shù)據(jù) 為技術(shù)決策提供依據(jù) 分類 實時監(jiān)控和運維腳本 監(jiān)控系