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