周末大促那幾天優(yōu)惠券APP的用戶突然涌入首頁搜一下“某品牌券”服務(wù)端平均延遲直接飆到2.3秒第5頁之后翻頁基本超時。這大概是所有做優(yōu)惠券聚合類APP都會撞上的墻不是單個查詢慢而是多維度組合篩選下的全文檢索慢。我當(dāng)時接手這個性能優(yōu)化第一步就想給MySQL加索引、上緩存搞了一圈發(fā)現(xiàn)只是治標(biāo)。真正把方案落到Elasticsearch以下簡稱ES和Canal的搭配上搭了一條MySQL→binlog→Canal→Kafka→ES的增量同步管道再對查詢層做了filter緩存、聚合預(yù)計算和深分頁改造單次搜索穩(wěn)定壓在20ms上下。這篇文章就把這條鏈路從頭講一遍適合正在做商品/優(yōu)惠券/本地生活檢索的同學(xué)參考也適合剛接觸ES和同步組件的后端工程師抄作業(yè)。1. 優(yōu)惠券搜索場景到底難在哪里不只是“查得快”這么簡單1.1 多條件疊加一次搜索背后藏著多少約束先還原一下優(yōu)惠券APP里的真實查詢形態(tài)。用戶搜“火鍋”的時候系統(tǒng)要同時滿足類目是“生活服務(wù)-美食-火鍋”價格區(qū)間在20到200之間折扣力度必須是滿100減50或5折券商家評分不低于4.5還需要按“最多人領(lǐng)券”排序。這還沒算地理位置用戶可能在杭州想把附近3公里內(nèi)的可用券也篩出來。把這些條件拆開后你會發(fā)現(xiàn)任何單一條件都不難難在組合。MySQL應(yīng)對這種查詢時最常用的是建聯(lián)合索引。(類目, 價格, 折扣力度)這組索引可能可以覆蓋部分場景但只要條件里加上評分、距離或者領(lǐng)券人數(shù)排序索引就開始失效優(yōu)化器要么走某個條件后回表要么干脆全表掃。加上優(yōu)惠券商品表的行數(shù)往往上千萬甚至上億聚合后的結(jié)果集又大分頁深度超過100頁時索引的作用基本為零。合作方那邊偶爾還要求模糊搜索比如輸“海底撈”結(jié)果匹配“海底撈火鍋”輸“公斤”要能搜到“kg”。這種同義詞、拼音、錯別字糾錯的需求MySQL的LIKE %關(guān)鍵字% 根本接不住。這不是加個索引能解決的問題而是索引模型和查詢模型都不是為這個場景設(shè)計的。1.2 MySQL的B樹索引與ES倒排索引的先天差異要想理解為什么最后選了ES而不是繼續(xù)堆MySQL得先把兩種數(shù)據(jù)結(jié)構(gòu)的差異講透。MySQL的B樹索引就像一本書的目錄告訴你某個詞在哪些頁碼但如果你要查找“第3章第2節(jié)里包含‘圖例’且頁數(shù)少于20頁”的內(nèi)容目錄只能分頭查到相關(guān)頁碼范圍然后你去取交集這個交集可能大得嚇人因為目錄只有頁級粒度沒有段落級粒度。優(yōu)惠券查詢里的“類目、價格、折扣、評分”就相當(dāng)于不同的頁碼條件組合起來后回表讀取所有候選商品行再做內(nèi)存過濾和排序自然慢。ES的倒排索引則是一張詞條到文檔ID列表的映射表。比如“火鍋”這個詞由分詞器提前拆出來它對應(yīng)一份包含“火鍋”的所有商品ID列表。多個查詢條件就是多個倒排列表ES用高效的集合運算把結(jié)果算出來全程都是位圖、跳表這類批量操作不需要逐行掃描。更關(guān)鍵的是ES天然支持相關(guān)性打分、短語匹配、同義詞擴展、拼音前綴等能力這些都是MySQL需要寫大量代碼才能模擬出來的。我并不是說ES能完全替代MySQL它的角色是搜索加速層MySQL繼續(xù)扮演事實數(shù)據(jù)源和事務(wù)系統(tǒng)。ES只存搜索需要的字段不存大字段、不存復(fù)雜關(guān)系單條文檔干脆利落這才能保證毫秒級返回。2. 數(shù)據(jù)從MySQL流向ElasticsearchCanal鏈路全解析2.1 binlog監(jiān)聽原理與Canal的定位數(shù)據(jù)同步方案很多為什么選Canal這類binlog監(jiān)聽方案而不是雙寫或者定時任務(wù)雙寫的問題在于業(yè)務(wù)代碼侵入性太強每次商品變更都要同時改MySQL和ES任何一處漏寫就會造成數(shù)據(jù)不一致。定時任務(wù)的問題更明顯要么延遲高要么效率低全量掃描一次幾千萬行對數(shù)據(jù)庫壓力很大在夜里跑還會拖累其他業(yè)務(wù)。Canal做的事情本質(zhì)上就是偽裝成MySQL的一個slave節(jié)點申請binlog日志然后按MySQL主從復(fù)制協(xié)議把更新流接過來。MySQL只要能配置主從復(fù)制Canal就能工作業(yè)務(wù)側(cè)完全無感。這一步最關(guān)鍵的是binlog格式必須是ROW模式只有ROW模式才記錄每行變更前后的完整數(shù)據(jù)Canal才能還原出“哪個ID更新成什么值”這種結(jié)構(gòu)化事件。為了消費穩(wěn)定典型拓?fù)涫荂anal把解析出來的變更事件投遞到Kafka再用獨立的消費服務(wù)批量寫入ES。這樣的好處是Kafka做緩沖即使ES短暫抖動消費端也不會把消息丟掉同時消費速率可以自己控制寫入ES時能攢一批走bulk批量接口比單條寫高效得多。2.2 實際部署配置從binlog開啟到消費端寫入先確保MySQL服務(wù)端開啟了log_bin同時設(shè)置server_id為一個不會與現(xiàn)有主從機器沖突的唯一值不能改成和庫內(nèi)其他實例一樣的數(shù)字。開啟后需要專門給Canal建一個賬號權(quán)限建議控制在SELECT、REPLICATION SLAVE、REPLICATION CLIENT這三項別直接給全局所有權(quán)限生產(chǎn)環(huán)境安全還是要守住的。創(chuàng)建賬號的SQL大致是這樣CREATE USER canal% IDENTIFIED BY your_password; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO canal%; FLUSH PRIVILEGES;接下來在Canal的instance.properties里配置數(shù)據(jù)源和監(jiān)聽規(guī)則canal.instance.master.address127.0.0.1:3306 canal.instance.dbUsernamecanal canal.instance.dbPasswordyour_password canal.instance.connectionCharsetUTF-8 canal.instance.filter.regexproduct_db\\.coupon_productfilter.regex這里我建議精確匹配到業(yè)務(wù)表而不是監(jiān)聽整個庫否則所有表的變化都會涌進來白白消耗解析與傳輸資源。需要監(jiān)聽多張表時用逗號分開比如product_db\\.coupon_product,product_db\\.merchant。Canal拿到變更后如果選擇推給Kafka在canal.properties里配置adapter或者直接使用客戶端模式都可以。更常見的是用Canal的Tcp模式開發(fā)一個簡單的客戶端這個客戶端收到的是序列化的消息對象里面包含tableName、eventTypeINSERT/UPDATE/DELETE、以及before和after的數(shù)據(jù)Map。消費端的核心邏輯很直接大致是解析事件類型如果是INSERT或者UPDATE就構(gòu)造ES的upsert請求用主鍵ID作為文檔ID如果是DELETE就調(diào)用ES的delete接口。每次攢夠一定數(shù)量或到時間閾值就執(zhí)行一次bulk提交我這里用的是每批2000條或每500ms刷一次線上跑下來寫入速率很穩(wěn)定。2.3 數(shù)據(jù)一致性版本號與冪等更新同步鏈路最容易出問題的不是千篇一律的插入而是更新順序。比如一個商品在很短時間內(nèi)被改了三次三條變更事件幾乎同時到達Kafka消費端并發(fā)去寫同一份ES文檔如果先寫后寫的順序亂了ES里最終存的可能是舊數(shù)據(jù)。解決這個問題的關(guān)鍵是每一張業(yè)務(wù)表都要有單調(diào)遞增的update_time或者版本號。ES文檔里把這個字段存成long類型消費端在寫之前做一次“版本校驗”如果ES里已有文檔的版本號大于等于當(dāng)前變更事件的版本號就跳過這次更新否則才用當(dāng)前數(shù)據(jù)覆蓋。具體實現(xiàn)可以在ES文檔里加入_meta.version字段{ id: 10001, name: 海底撈100元券, category_id: 120, price: 88.00, update_time: 1678543200 }在upsert腳本里如果當(dāng)前ctx._source.update_time params.update_time就執(zhí)行更新否則返回noop這樣即使消費并發(fā)也不會出現(xiàn)舊寫新覆蓋的情況。3. 商品索引建模把“毫秒級查詢”做出來的核心3.1 Mapping設(shè)計一個追求檢索速度的多字段組合索引模型定得好不好直接決定了查詢是幾個毫秒還是幾百毫秒。優(yōu)惠券商品搜索需要支撐文本搜索、精確篩選、范圍篩選、地理位置篩選和排序我的做法是采用經(jīng)典的“寬表設(shè)計”把每個檢索維度都獨立成一個字段而不是塞在一個大JSON里。核心Mapping長這樣{ mappings: { properties: { id: { type: keyword }, name: { type: text, analyzer: ik_max_word, fields: { keyword: { type: keyword } } }, brand_name: { type: keyword }, category_id: { type: keyword }, price: { type: scaled_float, scaling_factor: 100 }, discount_rate: { type: keyword }, merchant_score_level: { type: keyword }, coupon_type: { type: keyword }, sales_total: { type: long }, location: { type: geo_point }, update_time: { type: long } } } }name字段采用中文分詞器這里用ik_max_word是想盡可能多切出詞配合match查詢召回全而name.keyword字段用于精確匹配或排序比如“按名稱排序”的罕見需求?？赡苡型瑢W(xué)會問為什么不把類目設(shè)為long或者把價格設(shè)為double在ES里數(shù)值類型的倒排索引和范圍查詢性能其實不差但keyword類型在filter上下文中走的是位圖配合緩存效果更好。尤其像discount_rate這種可枚舉的離散值用keyword天然適合做聚合和過濾。3.2 空間換時間預(yù)計算維度與字段降級剛開始做的時候我一度想把所有條件都在查詢時實時計算比如“折扣力度大于7折”用range查詢“商家評分大于4分”用range查詢。后來壓測發(fā)現(xiàn)這種自由range雖然靈活但會讓filter緩存復(fù)用率很低因為用戶的評分閾值可能變化很大很難命中緩存。于是我們改用預(yù)計算字段上線前在數(shù)據(jù)加工階段把商品按價格切成price_bucket比如low(0-50)、mid(50-200)、high(200-1000)把商家評分切成score_high、score_mid等幾個檔位。查詢時直接對price_bucket做term過濾而不是對price做range過濾。這樣改動之后效果非常明顯因為term過濾的位圖計算幾乎可以忽略不計。誠然多一個字段就多一份存儲但換來的是更穩(wěn)定的查詢時延。結(jié)合優(yōu)惠券場景用戶對價格區(qū)間本來也是大致看的真正需要精確價格范圍的場景非常少損失一點精確性換取性能性價比很高。地理位置字段我用了geo_point類型配合geo_distance查詢過濾周圍3公里。由于地理距離計算相對較重我們在ES里也預(yù)存了city_id字段先按城市粗篩再用真正的距離精篩這樣大部分請求在城市維度就打住了距離計算只發(fā)生在同一個城市內(nèi)的少量候選集上。4. 查詢優(yōu)化三板斧真正把檢索速度壓下去4.1 用filter替代query讓緩存和位集做主力很多剛接觸ES的同學(xué)寫查詢時喜歡把所有條件都用query上下文包起來例如{ query: { bool: { must: [ { match: { name: 火鍋 } }, { range: { price: { gte: 20, lte: 200 } } } ] } } }這里面其實有一個大坑range在query上下文會被當(dāng)成詞項參與相關(guān)性打分還要單獨算一個norm效率并不理想。更麻煩的是ES的query cache和filter cache是兩套緩存query上下文里的條件普遍很少被緩存復(fù)用。正確做法是把結(jié)構(gòu)化條件全部放進filter上下文{ query: { bool: { must: [ { match: { name: 火鍋 } } ], filter: [ { term: { category_id: 120 } }, { term: { price_bucket: mid } }, { term: { merchant_score_level: high } }, { term: { city_id: hangzhou } }, { geo_distance: { distance: 3km, location: { lat: 30.27, lon: 120.15 } } } ] } } }filter上下文內(nèi)的每個子查詢都會被ES緩存成一個獨立的位集下次遇到完全相同的條件直接用位集取交集不再重復(fù)計算。在我們的場景里city_id和coupon_type是復(fù)用率最高的條件第二個請求開始基本就是內(nèi)存位運算P99能再壓好幾毫秒。4.2 商品維度聚合用terms和composite替代實時掃描除了查詢結(jié)果APP首頁往往還要展示每個類目下的券數(shù)量、滿減檔位的分布。直接在ES里對全量商品做一次agg返回結(jié)果當(dāng)然沒問題但每次請求都觸發(fā)一次聚合掃描開銷不小。我們的做法是分兩級第一級在查詢主索引用terms聚合拿幾個常用的key比如類目、折扣檔位因為ES的terms聚合可以直接讀取正排doc_values速度已經(jīng)很快只要別在高基數(shù)字段上做深聚合就行比如“按商品ID聚合”這種千萬級不同值的必須堅決避免。第二級對于首頁全局頻道的那種大通欄我們會用一個單獨的小索引或者Redis緩存提前算好“每個城市每天發(fā)券數(shù)量Top10”每10分鐘刷新一次。這樣首頁頻道打開時連ES都不用查直接走Redis幾乎零耗時。結(jié)論是聚合能避開就避開不能避開的盡量用低梯度聚合再往上層用緩存擋住高流量。4.3 深分頁改造search_after才是真實選項很快你就會發(fā)現(xiàn)ES的fromsize一旦超過1萬會直接報錯即使不報錯翻頁越深代價也越大因為每次都要計算全局排序后丟掉前from個結(jié)果。優(yōu)惠券APP的場景里用戶基本上不會翻超過10頁但我們依然要防住尾部流量和爬蟲。我的改造方案是第一頁仍用普通的fromsize可以接受但從第二頁開始前端傳回上一頁最后一條商品的排序字段值集合后端使用search_after來續(xù)接。例如上一頁最后一條商品按銷量排序的值是4650查詢下一頁就帶上{ query: { ... }, sort: [ { sales_total: desc }, { _id: desc } ], search_after: [4650, 10001], size: 20 }注意search_after必須依賴穩(wěn)定的排序主鍵我習(xí)慣在sales_total后面追加_id作為二級排序防止兩個商品銷量相同導(dǎo)致翻頁錯亂。另外還有一個隱藏的好處search_after查詢不會像深分頁那樣在協(xié)調(diào)節(jié)點消耗大量內(nèi)存它天然只需要維護一個小窗口。5. 性能壓測與實戰(zhàn)調(diào)優(yōu)從200ms到20ms的路徑5.1 壓測場景設(shè)計與核心指標(biāo)優(yōu)化有沒有效不能只看平均延遲必須用P90、P95、P99和TPS來驗收。我們壓測時模擬了200個并發(fā)用戶查詢條件分布刻意做得比較真實50%的請求是“關(guān)鍵詞類目價格區(qū)間”的組合30%是純關(guān)鍵詞搜索剩下的20%是只按類目或城市篩選。這樣能和線上用戶行為基本對上不然只跑一個最簡單查詢壓出來的數(shù)據(jù)沒有任何參考價值。最初階段的結(jié)果非常有代表性MySQL老接口的P95是1400msTPS只有400左右換成ES之后第一版還沒做三維打法的P95是80msTPS到了2000做完filter上下文和預(yù)計算字段后P95直接掉到25msTPS穩(wěn)定在5000以上。這個對比不是為了證明MySQL差而是想說明架構(gòu)層優(yōu)化比SQL層優(yōu)化帶來的數(shù)量級提升更顯著。5.2 慢查詢拆解profile API告訴我們瓶頸都在哪壓測過程中出現(xiàn)過幾次波動明明只有20ms左右的查詢偶爾會突然飆到200ms。這時候我打開了ES的profileAPI一條慢請求的詳細(xì)耗時段立刻暴露出來。有段時間慢主要卡在build_scorer階段原因是某個篩選字段是高基數(shù)的keyword比如merchant_id直接拿來過濾雖然能過濾掉大部分?jǐn)?shù)據(jù)但構(gòu)建位集的成本很高。后來改成對merchant_id做“范圍歸一化”預(yù)計算生產(chǎn)一個merchant_size_level字段把商家按商品數(shù)量分成大中小幾檔過濾這個字段后就快非常多。還有一次是中文分詞器在單次查詢中被觸發(fā)了太多詞項。原因是我用了match_phrase來搜索商品名用戶輸入“麻辣小龍蝦”時倒排表合并的詞項非常多導(dǎo)致fetch階段從磁盤取原始文檔的時間變高。最后我改成同時保留match召回寬結(jié)果和match_phrase做精排——先用match拿到候選集再對候選集按短語匹配重算分?jǐn)?shù)而不是把所有詞項放在一個查詢里硬扛。5.3 集群參數(shù)與寫入優(yōu)化Refresh、堆內(nèi)存與批量很多優(yōu)化是發(fā)生在查詢之前寫入側(cè)的參數(shù)直接決定查詢時的數(shù)據(jù)布局。ES默認(rèn)refresh_interval是1s這個對近實時搜索足夠但大批量同步時每1秒就會生成一個分段分段多了之后查詢要在多個分段上取結(jié)果反而變慢。我把商品索引的refresh_interval在增量峰值時段調(diào)成30s配合bulk批量寫入分段數(shù)量大大減少。用戶對新增券時效性的容忍度一般在分鐘級30s這個值完全夠用。JVM堆內(nèi)存我給了32GB單機物理內(nèi)存64GB這個比例正好能把es的filter cache、segment cache的都裝進內(nèi)存。如果給小了頻繁GC對耗時的沖擊非常明顯如果給太大又會讓OS層的文件緩存被嚴(yán)重擠壓反而得不償失。另外indices.queries.cache.size我設(shè)置為堆的10%并觀察filter cache命中率命中率低于50%時優(yōu)先檢查是不是條件寫法不統(tǒng)一而不是簡單加大緩存。6. 同步鏈路里那些防不勝防的坑6.1 binlog格式設(shè)置與主從沖突有一次我們把一個新商品表接入監(jiān)聽結(jié)果Canal一直報Table xxx doesnt exist排查了半天才發(fā)現(xiàn)MySQL里binlog_format仍然是STATEMENT而不是ROW。STATEMENT格式只記錄SQL語句Canal沒法解析出變更行數(shù)據(jù)自然什么都拿不到。切換binlog格式不能隨意執(zhí)行SET GLOBAL必須修改配置文件并重啟MySQL否則只對之后的新會話生效存量數(shù)據(jù)同步依然拿不到。還有一個小坑是Canal的slaveId片不能和MySQL現(xiàn)有從庫的server_id重復(fù)重復(fù)會導(dǎo)致MySQL報錯并終止復(fù)制鏈路這是最容易被忽略的也是新加實例最常踩的坑。6.2 延遲放大與消費壓力告警同步鏈路里的延遲問題分為兩種Canal到Kafka的延遲Kafka到ES消費端的延遲。前者如果長期在高位一般說明Canal解析速度跟不上可以適當(dāng)調(diào)大Canal的批大小后者如果積壓嚴(yán)重先別急著加消費者線程看看ES的bulk寫入有沒有報rejected_execution。我們的告警策略是在每條事件里帶上MySQL的update_time消費端記錄當(dāng)前時間并算出差值如果落后超過2分鐘觸發(fā)P2告警。超過10分鐘就觸發(fā)P1因為這已經(jīng)說明增量鏈路斷了用戶看到的搜索結(jié)果是舊數(shù)據(jù)。剛開始上線時這種告警救了我好幾次有一次Kafka的某個分區(qū)因為磁盤滿被限流延遲悄悄拉高到5分鐘搜索引擎還在照常響應(yīng)而這個告警幫我兜住了底。6.3 全量增量的雙通道恢復(fù)方案不管Canal鏈路設(shè)計得多嚴(yán)謹(jǐn)總有全量重建索引的時候比如突然發(fā)現(xiàn)一段時間內(nèi)線上數(shù)據(jù)有遺漏或者索引Mapping需要大改。我們習(xí)慣的做法是保留一條全量同步通道平時不用但隨時可以拉起。具體流程是先從MySQL導(dǎo)出一份全量數(shù)據(jù)快照用離線任務(wù)寫入到ES的臨時索引寫完臨時索引后再把當(dāng)天開始累積的增量事件按版本號合并過去最后通過別名切換把線上流量從舊索引切到新索引。切換別名的操作可以在ES里用原子接口完成{ actions: [ { remove: { index: old_index, alias: product_search } }, { add: { index: new_index, alias: product_search } } ] }這套雙通道方案的好處是重建期間舊索引繼續(xù)服務(wù)不會出現(xiàn)搜索中斷。整個切換過程有5秒左右的流量緩沖配合消費端繼續(xù)消費增量事件保證切換時間點前后的數(shù)據(jù)一致。我建議任何做CanalES同步的團隊都要提前演練一次全量切換這比出故障時再臨場設(shè)計靠譜得多。最后再提醒一句性能優(yōu)化沒有銀彈ES和Canal只是我所在場景下的解法。如果你的數(shù)據(jù)量、查詢模型或者更新頻率和優(yōu)惠券APP不一樣完全可以參考這里的思路換用其他框架但幾件事是通用的——先搞清楚查詢約束再做索引和查詢適配然后讓數(shù)據(jù)同步鏈路做到可觀測、可恢復(fù)。只有這樣所謂毫秒級響應(yīng)才不是一個演示Demo而是真能扛住大促流量的生產(chǎn)事實。