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