1. 先搞清矛盾根源全文檢索和高頻更新為什么天然打架幾年前我接手過一個(gè)電商后臺的搜索模塊業(yè)務(wù)方提了一個(gè)看似普通的需求商品標(biāo)題、賣點(diǎn)、品類路徑要做全文檢索同時(shí)價(jià)格、庫存、狀態(tài)這類字段每天會被訂單系統(tǒng)和庫存系統(tǒng)高頻更新高峰期每秒上百次修改大促時(shí)還會翻幾倍。當(dāng)時(shí)團(tuán)隊(duì)的第一反應(yīng)是直接上 Elasticsearch 不就行了結(jié)果上線后第一周就出現(xiàn)了搜索延遲飆到 2 秒、CPU 頻繁打滿、段合并把寫入毛刺放大到無法接受的問題。那次經(jīng)歷讓我徹底明白一件事全文檢索和高頻更新放在一起不是加一臺機(jī)器能解決的存儲架構(gòu)必須從一開始就認(rèn)真選型。先理解為什么這兩件事天然沖突。全文檢索依賴倒排索引而倒排索引為了追求查詢效率通常設(shè)計(jì)成不可變的。以 LuceneElasticsearch 的底層引擎為例一次文檔更新本質(zhì)上不是改掉那行數(shù)據(jù)而是把舊文檔標(biāo)記為 deleted再寫入一個(gè)全新文檔。這個(gè)標(biāo)記刪除 新寫入的動作落在磁盤上就是不斷產(chǎn)生新的小 segment 文件。后臺的 segment merge 線程會持續(xù)把這些小文件合并成大文件合并過程中又涉及 IO 和 CPU 的大量消耗。高頻更新對這套機(jī)制的沖擊是全方位的。你寫入越快refresh 產(chǎn)生的 segment 越多segment 越多查詢時(shí)需讀取的文件越多耗時(shí)自然上升merge 越頻繁CPU 和磁盤 IO 越緊張又反過來拖慢寫入。結(jié)果就是寫得更快查得更慢兩頭堵。更隱蔽的是被標(biāo)記刪除的文檔并不會立刻釋放空間如果你的更新頻率遠(yuǎn)大于新增頻率索引文件會越來越大磁盤占用虛高最后連緩存命中率都跟著下降。所以看到全文檢索 高頻更新這個(gè)組合第一反應(yīng)不應(yīng)該是選某個(gè)具體數(shù)據(jù)庫而是先搞清楚你真正的更新負(fù)載是什么樣的。這決定了后面所有技術(shù)選型的方向。我這篇文章會把常見的幾種架構(gòu)方案拆開來講包括單集群調(diào)優(yōu)、主存儲與檢索層分離、更新緩沖層設(shè)計(jì)以及它們各自適用的場景和實(shí)測表現(xiàn)希望對正在做技術(shù)選型的人有實(shí)際幫助。我理解很多人看到全文檢索就直接想到 Elasticsearch但 ES 默認(rèn)配置是為讀多寫少、數(shù)據(jù)基本不變設(shè)計(jì)的。它的refresh_interval默認(rèn)是 1 秒意味著每秒都可能把內(nèi)存中的索引緩沖刷成一個(gè)可查詢的 segment。這對索引構(gòu)建類的場景沒問題但如果是高頻更新每隔幾秒就有一大批文檔需要更新默認(rèn)配置會制造大量碎片化 segment。避免這個(gè)問題的第一步是把索引刷新周期拉開同時(shí)理解這背后可見性與寫入成本的博弈。2. 選型前必答的四個(gè)問題實(shí)時(shí)性、一致性、數(shù)據(jù)規(guī)模、運(yùn)維邊界架構(gòu)選型最忌諱一上來就討論用 MySQL 還是 ES、用 CDC 還是雙寫。我在做方案評審的時(shí)候習(xí)慣先讓團(tuán)隊(duì)把下面四個(gè)問題用一句話回答清楚。這四個(gè)答案基本能鎖定 80% 的選型空間。第一個(gè)問題業(yè)務(wù)允許搜索結(jié)果的延遲是秒級還是毫秒級全文檢索的近實(shí)時(shí)特性決定了它天然有延遲。Elasticsearch 默認(rèn) 1 秒 refresh意味著你寫入一條數(shù)據(jù)后最多 1 秒才能被搜到。如果業(yè)務(wù)要求用戶剛修改的商品標(biāo)題必須立刻能搜到那 ES 單寫方案基本出局除非你能接受更復(fù)雜的實(shí)時(shí)性補(bǔ)償。反過來如果延遲 3 到 5 秒完全沒問題大多數(shù) B 端運(yùn)營后臺、商品管理后臺都屬于這一類那 ES 的近實(shí)時(shí)機(jī)制反而能給你省下大量架構(gòu)成本。第二個(gè)問題更新后數(shù)據(jù)的一致性是強(qiáng)一致還是最終一致業(yè)務(wù)方嘴上說要一致但你要追問一句如果用戶搜到的商品價(jià)格是 3 秒前的會造成資損嗎會造成嚴(yán)重客訴嗎如果不會那就是典型的最終一致場景完全可以用異步鏈路。真正需要強(qiáng)一致的高頻更新場景比如秒殺庫存、銀行賬戶余額這些字段本來就不應(yīng)該放進(jìn)全文檢索系統(tǒng)——它們應(yīng)該留在業(yè)務(wù)主庫或者放到 Redis 這類高性能存儲里檢索層只保存可搜索但不強(qiáng)一致的副本字段。第三個(gè)問題數(shù)據(jù)量級和更新比例是多少我見過一個(gè)團(tuán)隊(duì)ES 集群只有 3 個(gè)節(jié)點(diǎn)但商品表每天有 2000 萬條記錄需要更新更新比例超過全量數(shù)據(jù)的 60%這已經(jīng)不是調(diào)優(yōu)能解決的了。你需要估算三件事全量文檔總數(shù)、日均更新文檔數(shù)、更新字段占整個(gè)文檔的比例。如果更新文檔數(shù)超過總量的 20%或者單個(gè)文檔的更新頻率達(dá)到每分鐘一次以上我都建議不要在 ES 里做原地震動更新而是考慮分層架構(gòu)。第四個(gè)問題團(tuán)隊(duì)有多少精力能投入到 ES 集群運(yùn)維上這是最現(xiàn)實(shí)的問題。ES 集群的坑非常深分片分布不均、堆內(nèi)存壓力、合并風(fēng)暴、冷熱節(jié)點(diǎn)規(guī)劃每一樣都需要專人跟進(jìn)。如果團(tuán)隊(duì)只有一兩個(gè)后端平時(shí)還要兼顧業(yè)務(wù)開發(fā)那就老老實(shí)實(shí)選一個(gè)運(yùn)維簡單、出問題好排查的方案。比如把全文檢索放在 PostgreSQL 的 GIN 索引上或者接受用 MySQL 的LIKE %keyword%頂著——雖然并發(fā)能力差一點(diǎn)但至少不會半夜被 on-call 電話叫醒。這四個(gè)問題回答完之后選型就變成了一個(gè)約束求解問題。比如延遲 3 秒可接受、最終一致、更新占比 40%、運(yùn)維人力有限那答案大概率是主庫 異步任務(wù)更新 ESES 只做檢索而不是死磕 ES 參數(shù)。3. 方案一單體 ES 集群硬扛調(diào)參調(diào)出第二春如果數(shù)據(jù)量不大單分片 30GB 以內(nèi)、更新頻率不算變態(tài)每秒幾百次以內(nèi)、業(yè)務(wù)能接受秒級延遲那最簡單的方案不是推翻 ES而是把 ES 的參數(shù)調(diào)到適配高頻更新的形態(tài)。默認(rèn)配置是為批量導(dǎo)入設(shè)計(jì)的你需要反向調(diào)整。3.1 拉開 refresh 間隔減少 segment 碎片refresh_interval從默認(rèn)的 1 秒調(diào)到 30 秒甚至更久高頻更新場景下收益非常明顯。每次 refresh 都會把 buffer 里的數(shù)據(jù)生成一個(gè)新的 segment如果每秒更新 500 條默認(rèn)配置下 1 分鐘會產(chǎn)生 60 個(gè) segment查詢時(shí)要把這些 segment 全部掃一遍調(diào)到 30 秒后1 分鐘只有 2 個(gè) segment。PUT /your_index/_settings { index: { refresh_interval: 30s } }代價(jià)是數(shù)據(jù)從寫入到可搜索的延遲從 1 秒變成最長 30 秒。對運(yùn)營后臺這類場景搜索按鈕點(diǎn)下去等幾秒才出現(xiàn)結(jié)果用戶完全能接受。但對 C 端搜完立刻下單的場景30 秒延遲就是災(zāi)難這條要提前想清楚。3.2 調(diào)整 translog 刷新策略減少磁盤同步次數(shù)ES 默認(rèn)每次寫請求都會把 translog fsync 到磁盤這是保證數(shù)據(jù)不丟的關(guān)鍵機(jī)制但高頻更新下會變成嚴(yán)重的性能瓶頸。對可以接受丟失幾秒數(shù)據(jù)的場景可以改成異步刷盤并調(diào)大刷盤閾值。PUT /your_index/_settings { index: { translog.durability: async, translog.sync_interval: 5s, translog.flush_threshold_size: 1gb } }這里要特別提醒a(bǔ)sync意味著如果節(jié)點(diǎn)宕機(jī)最近幾秒的寫入可能會丟。數(shù)據(jù)庫領(lǐng)域有一句老話沒有免費(fèi)的可靠性你省下的每一次磁盤同步都是用數(shù)據(jù)安全換來的。這個(gè)方案只適合丟了能重建的數(shù)據(jù)比如從主庫重新導(dǎo)一次就能恢復(fù)的檢索索引。3.3 關(guān)閉副本寫入寫完再恢復(fù)寫入期間把副本數(shù)臨時(shí)設(shè)為 0只寫主分片寫完再改回去。這樣寫入鏈路少了一半的副本同步開銷對吞吐的提升非常直接。但副作用是副本數(shù)為 0 期間一旦主分片所在節(jié)點(diǎn)宕機(jī)數(shù)據(jù)就沒了。實(shí)操中我會選擇在業(yè)務(wù)低峰期做這種操作并且控制窗口時(shí)間。很多團(tuán)隊(duì)會在這里踩坑改設(shè)置改得爽忘了改回來之后集群一直處于無副本狀態(tài)。3.4 用 index 代替 update減少讀改寫ES 的updateAPI 內(nèi)部邏輯是讀取舊文檔 - 合并字段 - 索引新文檔比直接index多了一次讀操作。如果更新的是整個(gè)文檔比如商品詳情的多個(gè)字段一起變了直接用indexAPI 寫入完整文檔性能會好不少。如果確實(shí)只需要更新其中一兩個(gè)字段也寧可構(gòu)造完整文檔去 index而不是依賴 update 的部分字段能力。高頻場景下省一次讀就是省一次分片間的網(wǎng)絡(luò)往返。3.5 從 mapping 設(shè)計(jì)上降低更新代價(jià)把會高頻更新的字段和幾乎不變的字段分開處理。比如商品標(biāo)題、描述這種低頻修改字段正常建立倒排索引價(jià)格、庫存這種高頻字段用doc_values: false或者干脆不建索引、只做存儲。倒排索引的更新代價(jià)遠(yuǎn)高于列存你為價(jià)格搜索這個(gè)低頻需求付出的成本會在每次庫存更新時(shí)加倍奉還。方案一適合什么情況我建議數(shù)據(jù)量在百萬級、更新 QPS 在 500 以下、團(tuán)隊(duì)只有一兩個(gè)人維護(hù) ES 的小團(tuán)隊(duì)優(yōu)先考慮。它的好處是架構(gòu)簡單不需要引入額外的中間件和鏈路。缺點(diǎn)是天花板低只要業(yè)務(wù)增長到一定程度你早晚要面對調(diào)不動了的尷尬。我們當(dāng)時(shí)在方案一上撐了大概半年直到大促壓測時(shí)發(fā)現(xiàn) 30 秒的 refresh 已經(jīng)讓 merge 線程持續(xù) 100% CPU才下定決心做架構(gòu)升級。4. 方案二MySQL ES 雙寫用 CDC 把更新動作解耦當(dāng)更新頻率超出單 ES 集群的承受范圍或者業(yè)務(wù)主庫已經(jīng)是 MySQL/Oracle 這類關(guān)系型數(shù)據(jù)庫時(shí)最常見的升級路徑就是雙寫 異步同步。這里的核心思路業(yè)務(wù)系統(tǒng)只寫主庫ES 不再接收業(yè)務(wù)方的直接寫入而是通過 CDC 工具訂閱主庫的 binlog異步更新到 ES。4.1 業(yè)務(wù)寫入鏈路業(yè)務(wù)后端正常寫 MySQL事務(wù)提交后什么都不用管。ES 的更新由下游消費(fèi)者負(fù)責(zé)業(yè)務(wù)系統(tǒng)不用感知 ES 的存在。這一步就把業(yè)務(wù)邏輯和檢索索引維護(hù)徹底解耦后續(xù) ES 集群抖動、重啟、甚至整體重建都不會影響主鏈路。4.2 CDC 組件選型MySQL 生態(tài)里最常用的是 Canal阿里開源和 Debezium。兩者的原理一致偽裝成 MySQL 的從庫讀取 binlog解析成結(jié)構(gòu)化變更事件。我用 Canal 比較多部署相對簡單配置也直觀# canal.properties 關(guān)鍵配置 canal.instance.master.address127.0.0.1:3306 canal.instance.dbUsernamecanal canal.instance.dbPasswordcanal canal.instance.connectionCharsetUTF-8 canal.instance.filter.regexproduct_db\\.product_info拿到 binlog 事件后下一步是推到消息隊(duì)列。這幾乎是必須的原因是 Canal 本身只是一個(gè)數(shù)據(jù)通道如果直接把變更事件同步調(diào)用 ES一旦 ES 抖動就會導(dǎo)致 Canal 消費(fèi)積壓、延遲升高進(jìn)而影響 binlog 的拉取進(jìn)度。加上一層 Kafka/RocketMQ 后Canal 只負(fù)責(zé)生產(chǎn)消息消費(fèi)速度由下游單獨(dú)控制天然就有了削峰填谷和故障隔離能力。4.3 消費(fèi)者側(cè)的冪等與去重這是雙寫方案最容易翻車的地方。ES 的更新操作必須是冪等的——同一個(gè)文檔更新 10 次和更新 1 次最終結(jié)果一致。做法很簡單用業(yè)務(wù)主鍵作為 ES 文檔的_id消費(fèi)者每次都執(zhí)行index全文檔覆蓋寫而不是update局部更新。這樣即使 MQ 重復(fù)投遞或者消費(fèi)端重啟后重放也不會產(chǎn)生臟數(shù)據(jù)。消費(fèi)者的偽代碼大致是public void onMessage(ProductChangeEvent event) { // 1. 根據(jù)主鍵查詢最新數(shù)據(jù)從主庫或緩存 Product product productService.getById(event.getProductId()); if (product null || product.isDeleted()) { // 2. 已刪除則從 ES 中刪除 esClient.delete(product_index, event.getProductId()); return; } // 3. 全文檔覆蓋寫入 esClient.index(product_index, event.getProductId(), buildDoc(product)); }注意第 1 步不要直接用 binlog 里的變更字段構(gòu)造 ES 文檔。因?yàn)?binlog 記錄的是這一次變更的字段不是完整文檔。如果你只用變更字段去 update遇到多個(gè)字段先后變更、順序錯(cuò)亂時(shí)ES 里的數(shù)據(jù)就是缺胳膊少腿的。這也是為什么很多團(tuán)隊(duì)用雙寫方案后經(jīng)常出現(xiàn)搜索結(jié)果的標(biāo)題是新的但描述是舊的這類靈異問題。4.4 對賬與補(bǔ)償機(jī)制異步鏈路跑久了必然會出現(xiàn)漏消費(fèi)、MQ 消息丟失、ES 寫入失敗等事故。所以一定要設(shè)計(jì)定期對賬任務(wù)每天凌晨掃描一批業(yè)務(wù)主鍵比對 MySQL 和 ES 中的關(guān)鍵字段發(fā)現(xiàn)不一致就觸發(fā)重新同步。對賬的頻率取決于你對數(shù)據(jù)質(zhì)量的容忍度。我們當(dāng)時(shí)是每小時(shí)對賬一次最近 24 小時(shí)有變更的商品全量對賬放到凌晨低峰期做。4.5 這個(gè)方案的邊界和代價(jià)最大的代價(jià)是鏈路變長定位問題不再像以前那樣一條命令能解決。另外binlog 的保留時(shí)間也要關(guān)注MySQL 默認(rèn)可能只保留幾天如果 MQ 消費(fèi)延遲超過這個(gè)窗口就必須用全量重建的方式補(bǔ)齊。還要注意Canal 本身也有單點(diǎn)問題生產(chǎn)環(huán)境至少部署兩個(gè)實(shí)例做主備切換。方案二是我個(gè)人最常用的推薦尤其是數(shù)據(jù)量達(dá)到千萬級、更新頻率達(dá)到每秒數(shù)千次的業(yè)務(wù)。它在穩(wěn)定性和架構(gòu)復(fù)雜度之間取得了一個(gè)比較好的平衡。但這個(gè)方案的 ES 集群依然要承擔(dān)全部更新壓力只是從業(yè)務(wù)直接打變成異步批量打。如果你的更新頻率已經(jīng)高到所有商品的價(jià)格庫存每小時(shí)全量變一遍那方案二的 ES 寫入量依然是全量文檔數(shù) × 更新次數(shù)這時(shí)候就要考慮方案三了。5. 方案三ES 只做索引層把易變字段隔離出去第三個(gè)方案的思路更激進(jìn)一點(diǎn)既然 ES 怕高頻更新那就不讓它存那些高頻變動的字段。ES 里只保存用于檢索、排序、過濾的靜態(tài)字段標(biāo)題、描述、類目、品牌等而價(jià)格、庫存、狀態(tài)這些高頻字段留在 MySQL/Redis 等主存儲中。查詢時(shí)先通過 ES 拿到命中的文檔 ID 列表再用 ID 去主存儲批量拉取最新字段做最終的結(jié)果組裝。5.1 為什么這樣設(shè)計(jì)能解決本質(zhì)問題回到第一節(jié)說的矛盾根源ES 的寫入成本主要來自倒排索引的不可變特性更新一個(gè)字段需要重寫整個(gè)文檔。如果你把價(jià)格從 ES 文檔里挪出去那一次庫存變更就不再觸發(fā) ES 的任何寫入。ES 里的商品文檔可能一個(gè)月才更新一次標(biāo)題改了、描述改了而價(jià)格庫存每天變一千次ES 全都感知不到。高頻更新壓力被完全擋在了檢索系統(tǒng)之外。5.2 查詢鏈路的改造查詢邏輯會變成兩步。第一步用關(guān)鍵詞在 ES 里搜拿到 doc id 列表和靜態(tài)字段的排序分?jǐn)?shù)。第二步拿這批 id 去 Redis或者 MySQL批量獲取最新價(jià)格、庫存、狀態(tài)再在應(yīng)用層做合并。// 第一步ES 檢索只拿 id SearchResponse response esClient.search(product_index, keyword, pageNum, pageSize); ListLong ids extractIds(response); // 第二步批量回源獲取最新可變字段 ListProductPriceInfo priceInfos redisClient.mget(ids); // 第三步應(yīng)用層組裝結(jié)果 ListProductResult results merge(response.getHits(), priceInfos);這個(gè)方案的查詢延遲理論上會多一跳網(wǎng)絡(luò)開銷但 Redis 的批量讀取是微秒到毫秒級整體影響不大。而且換來的是一個(gè)寫入壓力極低的 ES 集群查詢穩(wěn)定性會好很多。實(shí)測中我們用這個(gè)方案把 ES 的寫入 QPS 從 5000 降到了不到 200段合并風(fēng)暴基本消失查詢 P99 從 800ms 降到了 120ms。代價(jià)是應(yīng)用層多了一段合并邏輯以及對 Redis/主庫的額外讀取壓力。5.3 什么字段適合留在 ES什么字段必須拆出去我按字段特征做了一個(gè)劃分需要參與倒排索引、分詞匹配的字段標(biāo)題、賣點(diǎn)、描述——必須留 ES。需要范圍過濾、排序的數(shù)值字段價(jià)格、銷量如果更新頻率高強(qiáng)烈建議拆出更新頻率低如一天一次可以留。狀態(tài)類字段上下架、審核狀態(tài)幾乎每次業(yè)務(wù)操作都會變動拆出。冗余的商家名稱、類目路徑低頻變動的可以留 ES 用于展示和過濾。這個(gè)方案的變體也很實(shí)用如果實(shí)在拆不干凈也可以保留雙份字段即 ES 里留一個(gè)用于展示但允許過期的價(jià)格查詢時(shí)用主存儲的最新價(jià)格覆蓋。搜索列表頁可以先展示過期價(jià)格占位詳情頁再用最新價(jià)大部分用戶根本感知不到。5.4 這個(gè)方案最大的坑最容易被忽視的問題是如果 ES 文檔的 ID 在主存儲中已經(jīng)不存在商品被刪了、下架了回源查詢時(shí)會發(fā)現(xiàn) ID 取不到數(shù)據(jù)。此時(shí)要在結(jié)果組裝階段過濾掉這些空文檔否則前端拿到一個(gè)沒有價(jià)格沒有狀態(tài)的商品卡片體驗(yàn)很差。我們最初的實(shí)現(xiàn)就漏了這一步上線后出現(xiàn)了一批幽靈商品排查了半天才發(fā)現(xiàn)是回源時(shí)沒做存在性過濾。方案三比較適合文檔量大、單文檔更新頻率極高、更新字段集中在少數(shù)幾個(gè)業(yè)務(wù)屬性的場景。比如電商、OTA 酒店房價(jià)、招聘網(wǎng)站的職位狀態(tài)都屬于這個(gè)類型。它不是所有場景的最優(yōu)解但如果你正在被 ES 的寫入毛刺折磨這個(gè)思路值得認(rèn)真考慮。6. 高頻更新壓垮 ES 的真正元兇段合并與寫入放大很多人以為 ES 寫入慢是因?yàn)槊總€(gè)文檔都要做分詞、建索引其實(shí)分詞的開銷遠(yuǎn)沒有想象中大。真正吃 CPU 和磁盤的是隱藏在寫入鏈路底層的段合并segment merge。我單獨(dú)用一節(jié)來講因?yàn)檫@個(gè)知識點(diǎn)決定了你在做前三章方案時(shí)能不能想明白為什么 ES 不適合高頻更新。6.1 段合并的全過程ES 的每個(gè)分片shard底層是一個(gè) Lucene 索引而 Lucene 索引由多個(gè) segment 組成。寫入流程大致是數(shù)據(jù)先進(jìn)內(nèi)存 bufferrefresh 時(shí)生成一個(gè) segment 并寫盤此時(shí)該 segment 可以被查詢。隨著寫入持續(xù)進(jìn)行小 segment 越積越多。Lucene 后臺線程會根據(jù)合并策略挑選一些 segment把它們讀出來、合并排序、寫成一個(gè)更大的新 segment然后刪除舊 segment。這個(gè)過程是異步的但它的 CPU、IO 開銷非?？捎^合并時(shí)既要讀舊 segment 的全部數(shù)據(jù)又要寫新 segment 的全部數(shù)據(jù)等于一次全量搬運(yùn)。6.2 什么是寫入放大假設(shè)你有 100GB 的索引數(shù)據(jù)不更新時(shí) merge 只發(fā)生在初始導(dǎo)入階段。但高頻更新意味著每個(gè) segment 里都有大量被標(biāo)記刪除的舊文檔這些舊文檔不會被立刻清理而是占著空間等 merge。后臺要不斷把含垃圾的 segment 合并成新 segment才能釋放空間。這會導(dǎo)致一個(gè)讓人崩潰的循環(huán)寫入越多 - 標(biāo)記刪除越多 - merge 越頻繁 - merge 又搶走寫入的 CPU - 寫入變得更慢 - 業(yè)務(wù)方加大寫入重試 - 更多 segment 產(chǎn)生。這就是典型的寫入放大現(xiàn)象磁盤 IO 和 CPU 消耗可能達(dá)到實(shí)際數(shù)據(jù)量的 3 到 5 倍。6.3 調(diào)優(yōu) merge 策略Lucene 默認(rèn)的TieredMergePolicy把 segment 按大小分層次合并理論上效果不錯(cuò)但高頻更新場景下需要調(diào)整參數(shù)PUT /your_index/_settings { index.merge.policy.segments_per_tier: 10, index.merge.policy.max_merge_at_once: 5, index.merge.scheduler.max_thread_count: 1 }這里的思路調(diào)小max_merge_at_once和max_thread_count是為了限制 merge 并發(fā)避免它在高峰期和寫入搶資源segments_per_tier控制每一層允許多少 segment調(diào)大一點(diǎn)可以減少合并頻率但可能會讓查詢讀取的文件數(shù)變多。這是一個(gè)在查詢性能和寫入穩(wěn)定性之間找平衡的游戲。沒有絕對正確的值只能靠自己的業(yè)務(wù)壓測去試。6.4 更治本的做法分片/索引粒度拆分如果你已經(jīng)預(yù)見到某個(gè)索引會被高頻更新不要把所有數(shù)據(jù)塞進(jìn)一個(gè)大索引。按時(shí)間滾動索引比如按天建索引是最常見的解法。每天的索引獨(dú)立生成、獨(dú)立 merge不會互相拖累。配合 ILMIndex Lifecycle Management策略可以把 3 天前的索引自動切到只讀甚至 force merge 成一個(gè)大 segment徹底杜絕舊數(shù)據(jù)的 merge 開銷。這種設(shè)計(jì)下高頻更新只影響當(dāng)天那個(gè)索引其他索引的查詢和寫入穩(wěn)如泰山。6.5 冷熱分離把近期高頻更新的索引放在熱節(jié)點(diǎn)SSD、高 IO 配置把歷史索引放在冷節(jié)點(diǎn)機(jī)械硬盤、低配置。這樣即使某個(gè)熱索引發(fā)現(xiàn) merge 風(fēng)暴也不會干擾到冷節(jié)點(diǎn)上承載的歷史檢索和聚合報(bào)表。我們在實(shí)踐中還把冷節(jié)點(diǎn)的副本數(shù)調(diào)成 0進(jìn)一步降低集群整體負(fù)載。這么看下來你已經(jīng)能理解為什么高頻更新 ES是一個(gè)需要嚴(yán)肅對待的組合。單純在業(yè)務(wù)代碼里調(diào) API 是沒用的如果不從底層機(jī)制上做規(guī)避性能天花板就在那里。但反過來說只要理解了段合并的運(yùn)行機(jī)制前文提到的方案三把易變字段拆出去為什么能同時(shí)解決寫入放大和查詢變慢就很好理解了——ES 的寫入量直接減少了一個(gè)數(shù)量級merge 的頻率自然降下來了。7. 三套方案實(shí)測對比延遲、吞吐、成本和坑位盤點(diǎn)紙上談兵沒有說服力這里把我們當(dāng)時(shí)在同一業(yè)務(wù)場景下做的一組壓測數(shù)據(jù)分享出來。測試環(huán)境是 3 臺 8C16G 的云主機(jī)ES 集群 3 節(jié)點(diǎn)單索引 20 個(gè)分片副本 1數(shù)據(jù)量約 800 萬商品文檔。寫入負(fù)載是每秒 2000 次文檔更新其中 80% 是價(jià)格/庫存類高頻字段更新20% 是標(biāo)題/描述等低頻字段更新。查詢負(fù)載是固定的 200 QPS 關(guān)鍵詞搜索。指標(biāo)方案一單體 ES 調(diào)優(yōu)方案二MySQL CDC ES方案三ES 索引層 Redis 回源寫入鏈路業(yè)務(wù)直接寫 ES業(yè)務(wù)寫 MySQL異步同步 ES業(yè)務(wù)寫主存儲ES 幾乎無寫入更新延遲30s 后可搜到約 3s 可搜到取決于 MQ 消費(fèi)速度靜態(tài)字段更新秒級價(jià)格庫存實(shí)時(shí)回源ES 寫入 QPS約 2000已接近上限約 1500Canal 消費(fèi)速率限制不到 200只有低頻字段變更查詢 P99800ms350ms120ms高峰期 CPU持續(xù) 95%75%40%磁盤占用虛高大量 deleted 文檔未清理正常正常數(shù)據(jù)一致性強(qiáng)一致單鏈路最終一致需對賬最終一致查詢回源保證準(zhǔn)確架構(gòu)復(fù)雜度低中中高運(yùn)維成本高需長期調(diào)參優(yōu)化中依賴 MQ、Canal 穩(wěn)定性高需要維護(hù) Redis 回源邏輯適合規(guī)模百萬級數(shù)據(jù)、更新頻率每秒幾百次內(nèi)千萬級數(shù)據(jù)、更新頻率每秒數(shù)千次大文檔量 極高更新頻率、字段可拆分有幾個(gè)數(shù)據(jù)點(diǎn)值得展開解釋一下。方案一在 2000 QPS 更新下已經(jīng)出現(xiàn)明顯毛刺這個(gè)毛刺來自 merge 線程和寫入線程的 CPU 競爭調(diào)參只能緩解不能根治。方案二的查詢 P99 比方案一好是因?yàn)閷懭霃耐阶兂僧惒紼S 的壓力小了但 350ms 仍然偏高——當(dāng)時(shí)的瓶頸在 MQ 消費(fèi)積壓導(dǎo)致 ES 批量寫入的 wave 效應(yīng)。方案三的查詢 P99 最低但這是犧牲了價(jià)格庫存字段的索引能力換來的如果業(yè)務(wù)需要按當(dāng)前價(jià)格做搜索過濾比如價(jià)格區(qū)間查詢方案三的那些字段就無法參與這種查詢了必須回源后在內(nèi)存里二次過濾。這是方案三最需要權(quán)衡的點(diǎn)。成本和坑位方面方案一的人力成本最被低估。很多人以為不用引入新組件就是省錢但當(dāng) ES 成為瓶頸后你會花大量精力做索引調(diào)優(yōu)、擴(kuò)容評估、段合并監(jiān)控這些隱性成本往往超過一套 MQ 加 CDC 的硬件費(fèi)用。方案二穩(wěn)定運(yùn)行的前提是 MQ 集群本身靠譜如果公司已經(jīng)有 Kafka/RocketMQ 基礎(chǔ)設(shè)施那方案二是性價(jià)比最高的。方案三引入了 Redis 依賴如果 Redis 抖動搜索結(jié)果會直接受影響這種查詢鏈路中的單點(diǎn)故障需要提前設(shè)計(jì)降級方案。8. 我的最終選型建議與幾條保命經(jīng)驗(yàn)綜合這些年的實(shí)際項(xiàng)目經(jīng)驗(yàn)我給一套可落地的選型建議姑且當(dāng)成一個(gè)決策清單來用更新頻率低每小時(shí)幾百次以內(nèi)、數(shù)據(jù)量百萬級、團(tuán)隊(duì)不想引入新組件優(yōu)先方案一但必須接受秒級延遲和持續(xù)調(diào)參。更新頻率中等每秒數(shù)百到數(shù)千次、已有 MySQL 主庫、公司有 MQ 基礎(chǔ)設(shè)施方案二是最穩(wěn)妥的選擇鏈路雖長但每一環(huán)都是成熟組件。單文檔更新頻率極高每分鐘多次、價(jià)格庫存等字段占更新 80% 以上、搜索又不依賴這些字段做過濾直接上方案三ES 只做靜態(tài)檢索可變字段全走 Redis 回源。如果搜索必須支持按最新價(jià)格過濾這種需求那方案三的適用性就要打折扣。這時(shí)候我會考慮把價(jià)格字段做成獨(dú)立索引比如價(jià)格區(qū)間 上下架狀態(tài)單獨(dú)放一個(gè)輕量 ES 索引主文檔索引只存靜態(tài)信息兩個(gè)索引通過商品 ID 關(guān)聯(lián)。這相當(dāng)于一個(gè)更細(xì)粒度的拆分。最后分享幾條自己的保命經(jīng)驗(yàn)。第一永遠(yuǎn)不要只依賴一條鏈路。不管是方案二還是方案三必須預(yù)留一條全量重建退路。我們每個(gè)月會跑一次全量同步腳本把 MySQL 全量數(shù)據(jù)重新灌入 ES用新索引 別名切換的方式發(fā)布確保任何增量鏈路問題最終都能靠全量修復(fù)兜底。第二監(jiān)控不要只看集群整體指標(biāo)單索引級別的 segment 數(shù)量、merge 耗時(shí)、deleted 文檔占比這三個(gè)指標(biāo)一定要配告警。deleted 文檔占比超過 30% 時(shí)基本可以判斷更新模型出了問題該考慮拆索引或換方案了。第三線上調(diào)參一定要留變更記錄。ES 的_settings接口改起來太方便生產(chǎn)環(huán)境經(jīng)常有人隨手改掉 refresh 或 merge 參數(shù)出了問題卻不知道誰改的。至少對索引 settings 的變更走一次代碼評審流程。關(guān)于這套架構(gòu)后續(xù)還可以怎么演進(jìn)我目前的計(jì)劃是在方案三的基礎(chǔ)上加入實(shí)時(shí)數(shù)倉的維度把價(jià)格庫存的歷史變化軌跡單獨(dú)存儲這樣既能做當(dāng)前價(jià)過濾又能支持價(jià)格趨勢分析檢索系統(tǒng)和高頻更新系統(tǒng)之間的邊界會更干凈。選型這件事沒有銀彈關(guān)鍵是搞清楚自己的業(yè)務(wù)屬于哪種更新模型再決定讓哪個(gè)組件承擔(dān)什么職責(zé)。