架構(gòu)：計算存儲分離解決集群擴縮容難題)
手頭有個搜索和日志分析的場景數(shù)據(jù)量說大不大說小不小但業(yè)務(wù)波動特別明顯——白天高峰和夜間低谷能差幾十倍。用傳統(tǒng) Elasticsearch 集群扛這種流量要么常年空轉(zhuǎn)浪費資源要么擴容速度跟不上突發(fā)流量。后來我把項目遷到了 Elasticsearch Serverless 架構(gòu)上核心思路就是無狀態(tài)化計算節(jié)點不保存任何持久數(shù)據(jù)所有數(shù)據(jù)都落到遠(yuǎn)程共享存儲這才算徹底解決了我的痛點。這篇文章不聊PPT式的架構(gòu)演進就從我實際遷移和運維的視角把 Elasticsearch Serverless 到底怎么做到無狀態(tài)、數(shù)據(jù)怎么流動、部署時要注意什么、遇到問題怎么排查一條線講清楚。無論你是剛開始接觸 ES 的新手還是在為集群擴縮容發(fā)愁的老手這篇應(yīng)該都能給你一些可以直接落地的參考。1. 傳統(tǒng)集群的痛點以及無狀態(tài)架構(gòu)的解題思路1.1 傳統(tǒng) Elasticsearch 集群為什么難伺候先說結(jié)論傳統(tǒng) ES 集群的痛點幾乎全來自狀態(tài)這兩個字。所謂狀態(tài)就是節(jié)點本地保存了數(shù)據(jù)、分片、副本、集群元數(shù)據(jù)。每個數(shù)據(jù)節(jié)點都要維護自己的分片副本又要把分片狀態(tài)和集群狀態(tài)保持一致這讓節(jié)點變得非常重。我舉個例子一個 3 節(jié)點的集群每新增一個節(jié)點新節(jié)點要先把分片數(shù)據(jù)拷貝過去集群要做數(shù)據(jù)再平衡rebalance這個過程對磁盤 IO 和網(wǎng)絡(luò)帶寬的消耗都很大。而且節(jié)點掛了之后其它節(jié)點要重新分配副本稍有疏忽就容易出現(xiàn) yellow 或 red 狀態(tài)。另一個繞不開的問題是擴縮容。業(yè)務(wù)流量漲了你想把集群從 5 個節(jié)點擴到 20 個節(jié)點正常情況下必須等待分片遷移完成這個等待時間往往以小時計。反過來流量降下來想縮容還得小心翼翼地把某個節(jié)點上的分片先移走否則又會出現(xiàn)數(shù)據(jù)丟失風(fēng)險。這種操作非常依賴運維經(jīng)驗不敢輕易自動化。還有單分片容量、副本數(shù)、磁盤空間、內(nèi)存分配這些規(guī)劃問題。我印象很深的一回集群里一個索引的分片計劃定得太粗結(jié)果半年后單分片撐到了接近 40GB查詢速度明顯下降但那時候再改分片數(shù)就得重建索引相當(dāng)痛苦。這些運維負(fù)擔(dān)說到底是等價的你選擇了有狀態(tài)的數(shù)據(jù)持久化方式就要接受帶狀態(tài)的管理成本。1.2 無狀態(tài)架構(gòu)無掉的是數(shù)據(jù)節(jié)點里的持久數(shù)據(jù)Elasticsearch Serverless 的核心設(shè)計思路不是把 Elasticsearch 功能砍掉而是把數(shù)據(jù)存儲從計算節(jié)點上徹底剝離出來。傳統(tǒng)架構(gòu)里一個數(shù)據(jù)節(jié)點的本地磁盤就承擔(dān)著分片數(shù)據(jù)的持久化任務(wù)。無狀態(tài)架構(gòu)則完全不同數(shù)據(jù)節(jié)點本質(zhì)上只是一臺計算資源它本地不保存任何必須長期保留的數(shù)據(jù)所有分片數(shù)據(jù)都以 segment 文件的形式寫入遠(yuǎn)程共享存儲比如對象存儲或者共享文件系統(tǒng)。節(jié)點本地的磁盤只用來放緩存和臨時文件隨時可以被清空、被替換。這就像把一間小賣部改成了中央倉庫加臨時攤位。攤位只負(fù)責(zé)把商品擺出來賣商品本身都鎖在倉庫里。攤位燒了、搬了換一個攤位繼續(xù)賣就行不用一箱箱把貨搬走。落到 Elasticsearch 的實現(xiàn)上數(shù)據(jù)節(jié)點啟動時不需要從其它數(shù)據(jù)節(jié)點復(fù)制數(shù)據(jù)只需要從遠(yuǎn)程存儲讀取分片元數(shù)據(jù)和 segment 文件。所以新節(jié)點加入集群幾乎秒級完成。節(jié)點異常退出也沒有影響——它本身沒有必須搶救的數(shù)據(jù)頂多是本地緩存丟失重新從遠(yuǎn)程存儲拉一遍就好。1.3 什么場景適合無狀態(tài)什么場景不建議我自己的判斷標(biāo)準(zhǔn)很簡單如果你的業(yè)務(wù)有明顯的流量波峰波谷或者你想讓一套搜索/日志系統(tǒng)能按需伸縮那 Serverless 無狀態(tài)架構(gòu)非常合適因為它把資源成本和數(shù)據(jù)副本解耦了。反過來說如果你的數(shù)據(jù)量很小、流量常年平穩(wěn)、團隊對傳統(tǒng) ES 運維已經(jīng)很熟練那就沒必要引入這套復(fù)雜度。加一個遠(yuǎn)程存儲引入新的網(wǎng)絡(luò)開銷和配置項帶來的收益并不明顯。小集群上傳統(tǒng)架構(gòu)完全夠用硬上一個無狀態(tài)架構(gòu)反而增加故障點。另外要注意無狀態(tài)架構(gòu)對網(wǎng)絡(luò)帶寬和遠(yuǎn)程存儲的讀寫性能要求很高。如果你所在機房到對象存儲的延遲超過幾十毫秒查詢和寫入都會明顯變慢。這一點在規(guī)劃階段就得想清楚。2. 核心設(shè)計拆解計算存儲分離背后的三層角色2.1 三層角色分裂協(xié)調(diào)、數(shù)據(jù)與存儲Elasticsearch Serverless 的邏輯架構(gòu)我習(xí)慣分成三層來看。第一層是協(xié)調(diào)層Coordinator。它負(fù)責(zé)接收客戶端請求解析查詢做權(quán)限校驗把請求路由到合適的數(shù)據(jù)節(jié)點然后匯總結(jié)果返回。協(xié)調(diào)層本身不存數(shù)據(jù)也不做數(shù)據(jù)持久化所以它可以非常輕量地做水平擴展。第二層是數(shù)據(jù)節(jié)點層Data Node。這是干活的角色負(fù)責(zé)執(zhí)行寫入、查詢、聚合。每個數(shù)據(jù)節(jié)點在收到請求后會操作本地的緩存數(shù)據(jù)如果緩存未命中就去遠(yuǎn)程存儲拉取相應(yīng)的 segment。數(shù)據(jù)節(jié)點沒有任何持久化存儲的義務(wù)它可以隨時銷毀重建。第三層是存儲層Storage。也就是遠(yuǎn)程共享存儲保存了所有索引的 segment 文件、translog 以及分片元數(shù)據(jù)。這一層才是整個集群唯一的狀態(tài)持有者。存儲層通常由對象存儲承擔(dān)它天然具備高可用性、高持久性以及無限擴展能力。傳統(tǒng) ES 的分片有主備副本概念在無狀態(tài)架構(gòu)里發(fā)生了變化。副本不再是完整的數(shù)據(jù)拷貝而是同一份 segment 文件在遠(yuǎn)程共享存儲上的不同引用方式。數(shù)據(jù)節(jié)點不需要各自持有一份完整副本避免了很多一致性問題。2.2 數(shù)據(jù)到底怎么進入倉庫要理解數(shù)據(jù)寫入流程我們先說 Elasticsearch 中的一個核心概念segment段。ES 中每個分片的數(shù)據(jù)實際是由若干不可變的 segment 文件組成的新寫入的數(shù)據(jù)先進入內(nèi)存 buffer等到滿足刷新條件默認(rèn) 1 秒后生成一個新 segment再經(jīng)過合并merge把多個小 segment 合并成一個大 segment。在有狀態(tài)的傳統(tǒng)架構(gòu)里這些 segment 直接寫進節(jié)點本地磁盤。在無狀態(tài)架構(gòu)里segment 生成之后會被上傳到遠(yuǎn)程共享存儲節(jié)點本地只保留最近一小部分熱數(shù)據(jù)的緩存。至于 translog事務(wù)日志為了保證寫入不丟同樣會同步到遠(yuǎn)程存儲。所以數(shù)據(jù)寫入的鏈路大概是這樣客戶端請求到達(dá)協(xié)調(diào)層協(xié)調(diào)層路由給某個數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點寫 translog 并寫入內(nèi)存 bufferperiodic flush 后生成 segment再把 segment 和 translog 上傳遠(yuǎn)程存儲最后返回客戶端寫入成功。這里實際上做了一個很重要的取舍用一次遠(yuǎn)程網(wǎng)絡(luò)寫入來換取數(shù)據(jù)節(jié)點的完全無狀態(tài)。如果你的業(yè)務(wù)寫入量特別大、對 p99 延遲要求又非?？量踢@種設(shè)計相對傳統(tǒng)本地寫入確實多了網(wǎng)絡(luò)開銷這也是為什么無狀態(tài)架構(gòu)更適合流量可彈性伸縮 對延遲不是極度敏感的場景。2.3 為什么必須要一個遠(yuǎn)程共享存儲很多剛接觸無狀態(tài)架構(gòu)的同事會問我能不能用數(shù)據(jù)節(jié)點之間的復(fù)制來替代遠(yuǎn)程存儲答案是否定的。無狀態(tài)的前提是節(jié)點隨時可以被替換。如果數(shù)據(jù)還是放在某個節(jié)點的本地磁盤那節(jié)點掛了數(shù)據(jù)就持有狀態(tài)的那部分就丟了。遠(yuǎn)程共享存儲之所以必要是因為它是集群全體節(jié)點都能訪問、且不依賴于某一個具體節(jié)點存活的公共底座。數(shù)據(jù)只要進了遠(yuǎn)程存儲業(yè)務(wù)計算節(jié)點再怎么增減數(shù)據(jù)都在。從實現(xiàn)層面看遠(yuǎn)程共享存儲可以理解為一個大得多的分布式文件系統(tǒng)但它和本地文件系統(tǒng)有一個明顯的不同它不保證低延遲的隨機寫。所以 Elasticsearch 在無狀態(tài)架構(gòu)里會把寫操作盡量合并成較大的 segment 文件再上傳減少小文件頻繁上傳的開銷。這也是為什么無狀態(tài) ES 通常會調(diào)整合并策略和刷新頻率讓 segment 足夠大、數(shù)量足夠少。3. 無狀態(tài)架構(gòu)與傳統(tǒng)架構(gòu)的對比與選型判斷3.1 一張表看懂兩者的關(guān)鍵差異對比項傳統(tǒng) ES 架構(gòu)Serverless 無狀態(tài)架構(gòu)數(shù)據(jù)持久化位置節(jié)點本地磁盤遠(yuǎn)程共享存儲對象存儲等節(jié)點故障影響需要重新分配分片集群可能變紅節(jié)點被替換數(shù)據(jù)從遠(yuǎn)程恢復(fù)擴容速度依賴分片遷移分鐘到小時級秒級拉起新節(jié)點縮容復(fù)雜度需遷移分片并規(guī)避數(shù)據(jù)丟失風(fēng)險直接銷毀節(jié)點即可存儲彈性受限于節(jié)點磁盤配額獨立擴展幾乎無限計算/存儲耦合高度耦合規(guī)劃困難完全解耦按需分配成本模型按節(jié)點固定成本付費按實際計算資源和存儲用量付費運維深度需要專業(yè) ES 運維經(jīng)驗平臺托管為主運維成本低延遲敏感度適合對延遲極度苛刻的場景多一層網(wǎng)絡(luò)開銷延遲略高3.2 從幾個核心指標(biāo)看架構(gòu)變化我最直觀的感受在三個方面第一擴容時間從小時級變成分鐘級。以前加節(jié)點分片遷移要等磁盤 IO 一點點搬現(xiàn)在新節(jié)點啟動后直接從遠(yuǎn)程存儲加載元數(shù)據(jù)只要計算資源到位基本上兩三分鐘就能接入集群服務(wù)查詢。第二CPU 和磁盤不再綁定。傳統(tǒng)架構(gòu)里磁盤滿了往往 CPU 還很閑想加計算能力就不得不擴大磁盤造成浪費。無狀態(tài)架構(gòu)下存儲獨立擴展計算資源按需增減成本模型更精確。第三故障恢復(fù)的心態(tài)變了。以前晚上收到節(jié)點宕機告警第一反應(yīng)是分片有沒有損壞、副本能不能頂上?，F(xiàn)在節(jié)點宕機對我而言只是少了一臺計算資源遠(yuǎn)程存儲里的數(shù)據(jù)還在我完全不慌。這種心態(tài)上的轉(zhuǎn)變實際上就是架構(gòu)穩(wěn)定性提升的體現(xiàn)。3.3 選型判斷什么情況下可以遷移我建議你按這三步來做判斷第一步評估流量特征。如果一天的流量波動超過 3 倍或者未來有比較明顯的增長預(yù)期無狀態(tài)架構(gòu)的價值就很大。第二步評估延遲需求。你的業(yè)務(wù)查詢響應(yīng)要求是幾百毫秒級別還是秒級如果要求極端的低延遲且數(shù)據(jù)量不大傳統(tǒng)架構(gòu)反而更穩(wěn)。第三步評估團隊能力。你們有沒有專門的 ES 運維人力如果沒有選擇托管式的 Serverless 服務(wù)能節(jié)省很多精力如果有那也可以基于開源組件自建無狀態(tài)集群但那個復(fù)雜度和運維成本就不低了。4. 實操記錄本地啟動與服務(wù)部署的完整過程4.1 Windows 本地啟動 Elasticsearch 的注意點說實話網(wǎng)上說Windows 啟動 Elasticsearch的教程很多但踩坑的細(xì)節(jié)沒幾個人講清楚。第一步是準(zhǔn)備 JDK。Elasticsearch 7.17 之后的版本內(nèi)置了捆綁的 JDK但建議你還是單獨安裝一個 JDK 并配置好環(huán)境變量方便后續(xù)操作和排查。這里有個我踩過幾次的坑如果你機器上裝過其它軟件環(huán)境變量里的 PATH 順序可能導(dǎo)致 ES 用了錯誤版本的 Java建議在命令行里先執(zhí)行java -version確認(rèn)版本。第二步是下載對應(yīng)版本的安裝包。盡量在官方渠道下載不要用不明來源的整合包。下載 zip 包后解壓注意路徑不要包含中文和空格否則后續(xù)腳本執(zhí)行容易出問題。第三步是修改配置。在config/elasticsearch.yml里本地單機測試至少要把discovery.type設(shè)置為single-node否則默認(rèn)的zen發(fā)現(xiàn)機制會嘗試找其它節(jié)點一直在 bootstrap 階段卡住。內(nèi)存設(shè)置方面在config/jvm.options里把-Xms和-Xmx設(shè)為一樣大小避免運行時堆擴容的停頓建議設(shè)為本機物理內(nèi)存的一半左右比如 8GB 內(nèi)存的機器就設(shè) 4GB。第四步是啟動。Windows 下直接運行bin/elasticsearch.bat然后訪問http://localhost:9200能得到一個 JSON 響應(yīng)就說明啟動成功了。這里我可以給一段最小啟動步驟清單下載 zip 包并解壓配置JAVA_HOME環(huán)境變量修改config/elasticsearch.yml設(shè)置cluster.name和discovery.type: single-node設(shè)置jvm.options里的堆內(nèi)存執(zhí)行bin\elasticsearch.bat啟動訪問http://localhost:9200驗證4.2 Serverless 部署的配置與驗證流程當(dāng)你準(zhǔn)備部署到 Serverless 環(huán)境事情就從裝一個單機進程變成了管理一套自動伸縮的計算集群。我用過的 Serverless 部署方式主要面向云廠商托管服務(wù)或者基于容器平臺自建。先說托管方式。通常你只需要創(chuàng)建一個 Serverless 項目填入要支持的地域、數(shù)據(jù)歸屬和網(wǎng)絡(luò)配置剩下的數(shù)據(jù)節(jié)點數(shù)量、分片分配都由平臺自動搞定。部署完可以直接拿到一個專用的接入地址體驗非常清爽。如果是自建我會建議把數(shù)據(jù)節(jié)點做成容器化工作負(fù)載讓它跑在支持橫向擴容的容器平臺上。部署的關(guān)鍵點有三處第一處節(jié)點配置里要指定遠(yuǎn)程存儲的地址和認(rèn)證信息。比如在elasticsearch.yml里配置對象存儲的 endpoint、bucket 和密鑰這些是數(shù)據(jù)節(jié)點連接遠(yuǎn)程存儲的橋梁。第二處必須保證所有配置的不變性。節(jié)點鏡像一旦構(gòu)建好運行參數(shù)不再修改要變就重新構(gòu)建鏡像。這樣節(jié)點掛了被替換時新起的節(jié)點就和舊的完全一樣這是無狀態(tài)部署的基礎(chǔ)。第三處要配置數(shù)據(jù)節(jié)點的存活探針。平臺應(yīng)該能夠定期檢查節(jié)點健康狀態(tài)一旦發(fā)現(xiàn)節(jié)點異常立刻拉一個新的節(jié)點替換而不需要人工介入。部署完成后的驗證我建議做三步檢查第一步確認(rèn)所有節(jié)點都能從遠(yuǎn)程存儲讀取分片元數(shù)據(jù)可以在數(shù)據(jù)節(jié)點的啟動日志里看到recovered相關(guān)記錄。第二步隨機殺掉一個節(jié)點確認(rèn)平臺自動恢復(fù)后查詢服務(wù)沒有出現(xiàn)長時間中斷。第三步人為打入少量索引數(shù)據(jù)然后刪除一個節(jié)點再看數(shù)據(jù)是否能正常檢索以確認(rèn)數(shù)據(jù)確實持久化在遠(yuǎn)程存儲上。4.3 與 Spring Boot 集成時需要注意的幾個參數(shù)服務(wù)端部署好之后實際業(yè)務(wù)應(yīng)用接入時最常見的就是 Spring Boot 項目。我通常用spring-data-elasticsearch配合 REST High Level Client 或者新版的ElasticsearchClient。集成時我最推薦直接使用官方的 transport 客戶端或 REST 客戶端因為它對 Spring Boot 生態(tài)兼容性好參數(shù)調(diào)整也方便。比較重要的配置項有這么幾個spring.elasticsearch.uris接入地址使用 Serverless 接入點時直接填為返回的 HTTPS URL。spring.elasticsearch.username/spring.elasticsearch.password認(rèn)證信息。spring.elasticsearch.connection-timeout和socket-timeout如果集群處在不同的地域網(wǎng)絡(luò)延遲偏高務(wù)必調(diào)大超時時間否則業(yè)務(wù)端很容易報ConnectionTimeOutException。集成時還要注意一個細(xì)節(jié)Serverless 環(huán)境通常會限制索引的自定義 mapping 不能隨意變更推薦把 mapping 和 setting 的模板提前定義好。如果直接在業(yè)務(wù)代碼里通過IndexRequest動態(tài)建索引可能會出現(xiàn)字段類型和模板不一致的報錯。我一般會在項目里放一份索引映射的初始化腳本部署新環(huán)境時先執(zhí)行一次避免奇奇怪怪的字段類型問題。5. 無狀態(tài)架構(gòu)下的讀寫流程與故障恢復(fù)邏輯5.1 寫入流程從協(xié)調(diào)層到遠(yuǎn)程存儲無狀態(tài)架構(gòu)下一次典型的寫入請求經(jīng)過的鏈路如下客戶端把寫入請求發(fā)到協(xié)調(diào)節(jié)點。協(xié)調(diào)節(jié)點對請求做解析、鑒權(quán)和路由找到合適的索引主分片所在的數(shù)據(jù)節(jié)點。數(shù)據(jù)節(jié)點接收請求后先寫 translog再寫入內(nèi)存 buffer。當(dāng) buffer 達(dá)到一定大小或時間達(dá)到刷新閾值觸發(fā) flush生成一個新的 segment。這個 segment 緊接著被上傳到遠(yuǎn)程共享存儲。等遠(yuǎn)程存儲確認(rèn)接收成功寫入請求才會返回成功。這段鏈路里我最在意的是 translog 和 segment 的安全。translog 如果丟了內(nèi)存 buffer 里的數(shù)據(jù)就丟了segment 如果沒傳到遠(yuǎn)程存儲這個分片就等于沒有持久化成功。因此無狀態(tài)架構(gòu)對這兩個操作的同步要求比較嚴(yán)格通常會等遠(yuǎn)程存儲返回 ACK 之后再給客戶端發(fā)成功響應(yīng)。5.2 查詢流程緩存與遠(yuǎn)程存儲的取舍查詢請求的路徑和寫入略有不同。客戶端請求到協(xié)調(diào)節(jié)點后協(xié)調(diào)節(jié)點把查詢廣播到所有相關(guān)分片的數(shù)據(jù)節(jié)點。每個數(shù)據(jù)節(jié)點先在本地緩存里查找相關(guān) segment本地沒有的再去遠(yuǎn)程存儲拉取。這里有一個取舍要注意如果本地緩存總是未命中幾次查詢之后緩存會逐漸暖起來后續(xù)延遲會下降但如果查詢范圍跨越大量 segment遠(yuǎn)程存儲的隨機讀會被放大。所以我在配置無狀態(tài)集群時會優(yōu)先保證頻繁查詢的索引足夠小并且設(shè)置合理的 segment 合并策略減少落到遠(yuǎn)程讀的次數(shù)。5.3 故障恢復(fù)演示從節(jié)點消失到業(yè)務(wù)無感這是我覺得無狀態(tài)架構(gòu)最優(yōu)秀的地方。假設(shè)某個數(shù)據(jù)節(jié)點因為硬件故障突然宕機傳統(tǒng)架構(gòu)此時要經(jīng)歷主分片重選舉、副本重分配、數(shù)據(jù)重新復(fù)制無狀態(tài)架構(gòu)里協(xié)調(diào)層會把這個節(jié)點標(biāo)記為異常平臺自動啟動一臺新數(shù)據(jù)節(jié)點。新節(jié)點啟動時不需要從其它節(jié)點復(fù)制數(shù)據(jù)而是先從遠(yuǎn)程存儲獲取這個分片的元信息再用遠(yuǎn)程讀取的方式直接對外提供服務(wù)。整個過程客戶端感知到的可能就是個別請求的響應(yīng)時間略微變長但不會出現(xiàn)整個索引不可查詢的情況。我開始做遷移實驗時做過一次破壞性測試在一個正常運行的無狀態(tài)集群里直接殺掉所有數(shù)據(jù)節(jié)點結(jié)果因為消費端有連接重試機制節(jié)點恢復(fù)后數(shù)據(jù)依舊可查。這正是計算無狀態(tài)、存儲有狀態(tài)的價值所在。6. 常見問題與排查技巧實錄6.1 啟動失敗heap 設(shè)置和端口占用我碰到最多的啟動失敗場景本地調(diào)試時八成是 heap 設(shè)置得不合理或者端口被占用。如果你看到native thread creation failed之類的錯誤通常是線程數(shù)或內(nèi)存超了。換個測試環(huán)境時先把jvm.options里的堆內(nèi)存調(diào)小一點比如 512MB等啟動成功再慢慢往上加。端口占用也很常見9200 和 9300 被占用時啟動日志會直接報Address already in use。Windows 下用netstat -ano | findstr 9200找出占用進程手動處理掉就行。還有一點容易忽略ES 默認(rèn)不允許以 root 身份在 Linux 下運行如果你正在容器里跑記得用非 root 用戶運行。Windows 下沒有這個限制但配置文件的權(quán)限要開放否則可能啟動時報access denied。6.2 數(shù)據(jù)節(jié)點無法連接遠(yuǎn)程存儲無狀態(tài)架構(gòu)里的一個高發(fā)問題數(shù)據(jù)節(jié)點配置了遠(yuǎn)程存儲但啟動后大量刷報錯檢查發(fā)現(xiàn)節(jié)點根本無法訪問對象存儲的 endpoint。排查思路我總結(jié)成一個順序確認(rèn)遠(yuǎn)程存儲 endpoint 可以被數(shù)據(jù)節(jié)點的網(wǎng)絡(luò)解析并且可以連通。在容器環(huán)境里做ping或curl測試。確認(rèn)訪問憑證配置正確。密鑰信息如果放在環(huán)境變量里要檢查數(shù)據(jù)節(jié)點的環(huán)境變量是否真的注入進去了。確認(rèn)訪問策略允許數(shù)據(jù)節(jié)點所在網(wǎng)絡(luò)的讀寫操作。很多云環(huán)境要通過 VPC 或安全組規(guī)則放行相應(yīng)端口和 IP。如果以上都沒問題但節(jié)點還是報錯檢查一下本地時鐘和遠(yuǎn)程服務(wù)器時鐘的偏差時間偏差超過 5 分鐘往往會導(dǎo)致請求簽名校驗失敗。6.3 查詢結(jié)果不全segment 與緩存機制有同事遇到過一個困惑數(shù)據(jù)寫入幾秒后查詢偶爾會漏掉一部分新數(shù)據(jù)。我第一反應(yīng)是查詢默認(rèn)的_refresh間隔。ES 默認(rèn) 1 秒刷新剛寫入的數(shù)據(jù)不會立刻對查詢可見這是正?，F(xiàn)象。如果你需要更強的實時性可以在寫入后強制refreshtrue但代價是頻繁刷新會生成大量小 segment影響后續(xù)查詢性能不建議在批量寫入場景使用。另一個點比較容易忽略無狀態(tài)架構(gòu)的本地緩存替換機制。當(dāng)本地緩存打滿節(jié)點會按策略淘汰部分 segment。如果查詢落在被淘汰的 segment 上節(jié)點需要重新從遠(yuǎn)程存儲加載這會表現(xiàn)為偶發(fā)的慢查詢。所以查詢耗時的曲線不應(yīng)該只看平均值一定要觀察 p99 分位值出現(xiàn)明顯抖動時優(yōu)先排查緩存命中率。6.4 我的排查工具與日常體檢清單很多剛?cè)胄械呐笥严矚g遇到問題就上論壇搜索我的習(xí)慣是先自己盯一套指標(biāo)集群健康狀態(tài)GET _cluster/health看status是不是 green。節(jié)點熱點GET _nodes/hot_threads看數(shù)據(jù)節(jié)點的 CPU 熱點。分片分配GET _cat/shards看有沒有分片長時間處于 UNASSIGNED。緩存命中GET _nodes/stats重點看query_cache和request_cache的命中率。存儲寫入延遲針對遠(yuǎn)程存儲做一次讀寫壓測確認(rèn)延遲是否在合理范圍內(nèi)。日常我是按周做一次體檢查一遍集群健康、看看數(shù)據(jù)增長和分片數(shù)量、檢查有沒有頻繁刷新的索引。這套習(xí)慣看起來簡單但能幫我提前攔住不少問題。最后說點個人體會從傳統(tǒng)集群遷到無狀態(tài)架構(gòu)我最大的收獲不是省了多少運維時間而是想清楚了一個問題在分布式系統(tǒng)里狀態(tài)放對位置比什么都重要。把數(shù)據(jù)狀態(tài)集中到遠(yuǎn)程共享存儲計算節(jié)點才能真正變成可丟棄的廉價資源。這個思路不只適用于 Elasticsearch很多大數(shù)據(jù)組件都在往這個方向走。如果你正準(zhǔn)備上手我個人建議先從一個小規(guī)模的非核心業(yè)務(wù)開始。先在本地按單節(jié)點模式跑通再部署到 Serverless 環(huán)境然后逐步加數(shù)據(jù)量、加查詢壓力。不要一上來就把核心業(yè)務(wù)遷過去無狀態(tài)架構(gòu)雖然穩(wěn)定但多了一層網(wǎng)絡(luò)依賴你得先摸清自己業(yè)務(wù)對延遲和成本的邊界在哪里。Windows 上啟動 Elasticsearch 的坑、Serverless 部署的配置、Spring Boot 集成的注意點這些具體操作我在前面已經(jīng)寫得很細(xì)了。你照著走一遍大概率能順利跑通。真碰到奇怪的問題再回頭看看第 6 部分的排查清單基本能定位個八九不離十。 Elasticsearch Serverless無狀態(tài)架構(gòu)：計算存儲分離解決集群擴縮容難題
手頭有個搜索和日志分析的場景數(shù)據(jù)量說大不大說小不小但業(yè)務(wù)波動特別明顯——白天高峰和夜間低谷能差幾十倍。用傳統(tǒng) Elasticsearch 集群扛這種流量要么常年空轉(zhuǎn)浪費資源要么擴容速度跟不上突發(fā)流量。后來我把項目遷到了 Elasticsearch Serverless 架構(gòu)上核心思路就是無狀態(tài)化計算節(jié)點不保存任何持久數(shù)據(jù)所有數(shù)據(jù)都落到遠(yuǎn)程共享存儲這才算徹底解決了我的痛點。這篇文章不聊PPT式的架構(gòu)演進就從我實際遷移和運維的視角把 Elasticsearch Serverless 到底怎么做到無狀態(tài)、數(shù)據(jù)怎么流動、部署時要注意什么、遇到問題怎么排查一條線講清楚。無論你是剛開始接觸 ES 的新手還是在為集群擴縮容發(fā)愁的老手這篇應(yīng)該都能給你一些可以直接落地的參考。1. 傳統(tǒng)集群的痛點以及無狀態(tài)架構(gòu)的解題思路1.1 傳統(tǒng) Elasticsearch 集群為什么難伺候先說結(jié)論傳統(tǒng) ES 集群的痛點幾乎全來自狀態(tài)這兩個字。所謂狀態(tài)就是節(jié)點本地保存了數(shù)據(jù)、分片、副本、集群元數(shù)據(jù)。每個數(shù)據(jù)節(jié)點都要維護自己的分片副本又要把分片狀態(tài)和集群狀態(tài)保持一致這讓節(jié)點變得非常重。我舉個例子一個 3 節(jié)點的集群每新增一個節(jié)點新節(jié)點要先把分片數(shù)據(jù)拷貝過去集群要做數(shù)據(jù)再平衡rebalance這個過程對磁盤 IO 和網(wǎng)絡(luò)帶寬的消耗都很大。而且節(jié)點掛了之后其它節(jié)點要重新分配副本稍有疏忽就容易出現(xiàn) yellow 或 red 狀態(tài)。另一個繞不開的問題是擴縮容。業(yè)務(wù)流量漲了你想把集群從 5 個節(jié)點擴到 20 個節(jié)點正常情況下必須等待分片遷移完成這個等待時間往往以小時計。反過來流量降下來想縮容還得小心翼翼地把某個節(jié)點上的分片先移走否則又會出現(xiàn)數(shù)據(jù)丟失風(fēng)險。這種操作非常依賴運維經(jīng)驗不敢輕易自動化。還有單分片容量、副本數(shù)、磁盤空間、內(nèi)存分配這些規(guī)劃問題。我印象很深的一回集群里一個索引的分片計劃定得太粗結(jié)果半年后單分片撐到了接近 40GB查詢速度明顯下降但那時候再改分片數(shù)就得重建索引相當(dāng)痛苦。這些運維負(fù)擔(dān)說到底是等價的你選擇了有狀態(tài)的數(shù)據(jù)持久化方式就要接受帶狀態(tài)的管理成本。1.2 無狀態(tài)架構(gòu)無掉的是數(shù)據(jù)節(jié)點里的持久數(shù)據(jù)Elasticsearch Serverless 的核心設(shè)計思路不是把 Elasticsearch 功能砍掉而是把數(shù)據(jù)存儲從計算節(jié)點上徹底剝離出來。傳統(tǒng)架構(gòu)里一個數(shù)據(jù)節(jié)點的本地磁盤就承擔(dān)著分片數(shù)據(jù)的持久化任務(wù)。無狀態(tài)架構(gòu)則完全不同數(shù)據(jù)節(jié)點本質(zhì)上只是一臺計算資源它本地不保存任何必須長期保留的數(shù)據(jù)所有分片數(shù)據(jù)都以 segment 文件的形式寫入遠(yuǎn)程共享存儲比如對象存儲或者共享文件系統(tǒng)。節(jié)點本地的磁盤只用來放緩存和臨時文件隨時可以被清空、被替換。這就像把一間小賣部改成了中央倉庫加臨時攤位。攤位只負(fù)責(zé)把商品擺出來賣商品本身都鎖在倉庫里。攤位燒了、搬了換一個攤位繼續(xù)賣就行不用一箱箱把貨搬走。落到 Elasticsearch 的實現(xiàn)上數(shù)據(jù)節(jié)點啟動時不需要從其它數(shù)據(jù)節(jié)點復(fù)制數(shù)據(jù)只需要從遠(yuǎn)程存儲讀取分片元數(shù)據(jù)和 segment 文件。所以新節(jié)點加入集群幾乎秒級完成。節(jié)點異常退出也沒有影響——它本身沒有必須搶救的數(shù)據(jù)頂多是本地緩存丟失重新從遠(yuǎn)程存儲拉一遍就好。1.3 什么場景適合無狀態(tài)什么場景不建議我自己的判斷標(biāo)準(zhǔn)很簡單如果你的業(yè)務(wù)有明顯的流量波峰波谷或者你想讓一套搜索/日志系統(tǒng)能按需伸縮那 Serverless 無狀態(tài)架構(gòu)非常合適因為它把資源成本和數(shù)據(jù)副本解耦了。反過來說如果你的數(shù)據(jù)量很小、流量常年平穩(wěn)、團隊對傳統(tǒng) ES 運維已經(jīng)很熟練那就沒必要引入這套復(fù)雜度。加一個遠(yuǎn)程存儲引入新的網(wǎng)絡(luò)開銷和配置項帶來的收益并不明顯。小集群上傳統(tǒng)架構(gòu)完全夠用硬上一個無狀態(tài)架構(gòu)反而增加故障點。另外要注意無狀態(tài)架構(gòu)對網(wǎng)絡(luò)帶寬和遠(yuǎn)程存儲的讀寫性能要求很高。如果你所在機房到對象存儲的延遲超過幾十毫秒查詢和寫入都會明顯變慢。這一點在規(guī)劃階段就得想清楚。2. 核心設(shè)計拆解計算存儲分離背后的三層角色2.1 三層角色分裂協(xié)調(diào)、數(shù)據(jù)與存儲Elasticsearch Serverless 的邏輯架構(gòu)我習(xí)慣分成三層來看。第一層是協(xié)調(diào)層Coordinator。它負(fù)責(zé)接收客戶端請求解析查詢做權(quán)限校驗把請求路由到合適的數(shù)據(jù)節(jié)點然后匯總結(jié)果返回。協(xié)調(diào)層本身不存數(shù)據(jù)也不做數(shù)據(jù)持久化所以它可以非常輕量地做水平擴展。第二層是數(shù)據(jù)節(jié)點層Data Node。這是干活的角色負(fù)責(zé)執(zhí)行寫入、查詢、聚合。每個數(shù)據(jù)節(jié)點在收到請求后會操作本地的緩存數(shù)據(jù)如果緩存未命中就去遠(yuǎn)程存儲拉取相應(yīng)的 segment。數(shù)據(jù)節(jié)點沒有任何持久化存儲的義務(wù)它可以隨時銷毀重建。第三層是存儲層Storage。也就是遠(yuǎn)程共享存儲保存了所有索引的 segment 文件、translog 以及分片元數(shù)據(jù)。這一層才是整個集群唯一的狀態(tài)持有者。存儲層通常由對象存儲承擔(dān)它天然具備高可用性、高持久性以及無限擴展能力。傳統(tǒng) ES 的分片有主備副本概念在無狀態(tài)架構(gòu)里發(fā)生了變化。副本不再是完整的數(shù)據(jù)拷貝而是同一份 segment 文件在遠(yuǎn)程共享存儲上的不同引用方式。數(shù)據(jù)節(jié)點不需要各自持有一份完整副本避免了很多一致性問題。2.2 數(shù)據(jù)到底怎么進入倉庫要理解數(shù)據(jù)寫入流程我們先說 Elasticsearch 中的一個核心概念segment段。ES 中每個分片的數(shù)據(jù)實際是由若干不可變的 segment 文件組成的新寫入的數(shù)據(jù)先進入內(nèi)存 buffer等到滿足刷新條件默認(rèn) 1 秒后生成一個新 segment再經(jīng)過合并merge把多個小 segment 合并成一個大 segment。在有狀態(tài)的傳統(tǒng)架構(gòu)里這些 segment 直接寫進節(jié)點本地磁盤。在無狀態(tài)架構(gòu)里segment 生成之后會被上傳到遠(yuǎn)程共享存儲節(jié)點本地只保留最近一小部分熱數(shù)據(jù)的緩存。至于 translog事務(wù)日志為了保證寫入不丟同樣會同步到遠(yuǎn)程存儲。所以數(shù)據(jù)寫入的鏈路大概是這樣客戶端請求到達(dá)協(xié)調(diào)層協(xié)調(diào)層路由給某個數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點寫 translog 并寫入內(nèi)存 bufferperiodic flush 后生成 segment再把 segment 和 translog 上傳遠(yuǎn)程存儲最后返回客戶端寫入成功。這里實際上做了一個很重要的取舍用一次遠(yuǎn)程網(wǎng)絡(luò)寫入來換取數(shù)據(jù)節(jié)點的完全無狀態(tài)。如果你的業(yè)務(wù)寫入量特別大、對 p99 延遲要求又非?？量踢@種設(shè)計相對傳統(tǒng)本地寫入確實多了網(wǎng)絡(luò)開銷這也是為什么無狀態(tài)架構(gòu)更適合流量可彈性伸縮 對延遲不是極度敏感的場景。2.3 為什么必須要一個遠(yuǎn)程共享存儲很多剛接觸無狀態(tài)架構(gòu)的同事會問我能不能用數(shù)據(jù)節(jié)點之間的復(fù)制來替代遠(yuǎn)程存儲答案是否定的。無狀態(tài)的前提是節(jié)點隨時可以被替換。如果數(shù)據(jù)還是放在某個節(jié)點的本地磁盤那節(jié)點掛了數(shù)據(jù)就持有狀態(tài)的那部分就丟了。遠(yuǎn)程共享存儲之所以必要是因為它是集群全體節(jié)點都能訪問、且不依賴于某一個具體節(jié)點存活的公共底座。數(shù)據(jù)只要進了遠(yuǎn)程存儲業(yè)務(wù)計算節(jié)點再怎么增減數(shù)據(jù)都在。從實現(xiàn)層面看遠(yuǎn)程共享存儲可以理解為一個大得多的分布式文件系統(tǒng)但它和本地文件系統(tǒng)有一個明顯的不同它不保證低延遲的隨機寫。所以 Elasticsearch 在無狀態(tài)架構(gòu)里會把寫操作盡量合并成較大的 segment 文件再上傳減少小文件頻繁上傳的開銷。這也是為什么無狀態(tài) ES 通常會調(diào)整合并策略和刷新頻率讓 segment 足夠大、數(shù)量足夠少。3. 無狀態(tài)架構(gòu)與傳統(tǒng)架構(gòu)的對比與選型判斷3.1 一張表看懂兩者的關(guān)鍵差異對比項傳統(tǒng) ES 架構(gòu)Serverless 無狀態(tài)架構(gòu)數(shù)據(jù)持久化位置節(jié)點本地磁盤遠(yuǎn)程共享存儲對象存儲等節(jié)點故障影響需要重新分配分片集群可能變紅節(jié)點被替換數(shù)據(jù)從遠(yuǎn)程恢復(fù)擴容速度依賴分片遷移分鐘到小時級秒級拉起新節(jié)點縮容復(fù)雜度需遷移分片并規(guī)避數(shù)據(jù)丟失風(fēng)險直接銷毀節(jié)點即可存儲彈性受限于節(jié)點磁盤配額獨立擴展幾乎無限計算/存儲耦合高度耦合規(guī)劃困難完全解耦按需分配成本模型按節(jié)點固定成本付費按實際計算資源和存儲用量付費運維深度需要專業(yè) ES 運維經(jīng)驗平臺托管為主運維成本低延遲敏感度適合對延遲極度苛刻的場景多一層網(wǎng)絡(luò)開銷延遲略高3.2 從幾個核心指標(biāo)看架構(gòu)變化我最直觀的感受在三個方面第一擴容時間從小時級變成分鐘級。以前加節(jié)點分片遷移要等磁盤 IO 一點點搬現(xiàn)在新節(jié)點啟動后直接從遠(yuǎn)程存儲加載元數(shù)據(jù)只要計算資源到位基本上兩三分鐘就能接入集群服務(wù)查詢。第二CPU 和磁盤不再綁定。傳統(tǒng)架構(gòu)里磁盤滿了往往 CPU 還很閑想加計算能力就不得不擴大磁盤造成浪費。無狀態(tài)架構(gòu)下存儲獨立擴展計算資源按需增減成本模型更精確。第三故障恢復(fù)的心態(tài)變了。以前晚上收到節(jié)點宕機告警第一反應(yīng)是分片有沒有損壞、副本能不能頂上?，F(xiàn)在節(jié)點宕機對我而言只是少了一臺計算資源遠(yuǎn)程存儲里的數(shù)據(jù)還在我完全不慌。這種心態(tài)上的轉(zhuǎn)變實際上就是架構(gòu)穩(wěn)定性提升的體現(xiàn)。3.3 選型判斷什么情況下可以遷移我建議你按這三步來做判斷第一步評估流量特征。如果一天的流量波動超過 3 倍或者未來有比較明顯的增長預(yù)期無狀態(tài)架構(gòu)的價值就很大。第二步評估延遲需求。你的業(yè)務(wù)查詢響應(yīng)要求是幾百毫秒級別還是秒級如果要求極端的低延遲且數(shù)據(jù)量不大傳統(tǒng)架構(gòu)反而更穩(wěn)。第三步評估團隊能力。你們有沒有專門的 ES 運維人力如果沒有選擇托管式的 Serverless 服務(wù)能節(jié)省很多精力如果有那也可以基于開源組件自建無狀態(tài)集群但那個復(fù)雜度和運維成本就不低了。4. 實操記錄本地啟動與服務(wù)部署的完整過程4.1 Windows 本地啟動 Elasticsearch 的注意點說實話網(wǎng)上說Windows 啟動 Elasticsearch的教程很多但踩坑的細(xì)節(jié)沒幾個人講清楚。第一步是準(zhǔn)備 JDK。Elasticsearch 7.17 之后的版本內(nèi)置了捆綁的 JDK但建議你還是單獨安裝一個 JDK 并配置好環(huán)境變量方便后續(xù)操作和排查。這里有個我踩過幾次的坑如果你機器上裝過其它軟件環(huán)境變量里的 PATH 順序可能導(dǎo)致 ES 用了錯誤版本的 Java建議在命令行里先執(zhí)行java -version確認(rèn)版本。第二步是下載對應(yīng)版本的安裝包。盡量在官方渠道下載不要用不明來源的整合包。下載 zip 包后解壓注意路徑不要包含中文和空格否則后續(xù)腳本執(zhí)行容易出問題。第三步是修改配置。在config/elasticsearch.yml里本地單機測試至少要把discovery.type設(shè)置為single-node否則默認(rèn)的zen發(fā)現(xiàn)機制會嘗試找其它節(jié)點一直在 bootstrap 階段卡住。內(nèi)存設(shè)置方面在config/jvm.options里把-Xms和-Xmx設(shè)為一樣大小避免運行時堆擴容的停頓建議設(shè)為本機物理內(nèi)存的一半左右比如 8GB 內(nèi)存的機器就設(shè) 4GB。第四步是啟動。Windows 下直接運行bin/elasticsearch.bat然后訪問http://localhost:9200能得到一個 JSON 響應(yīng)就說明啟動成功了。這里我可以給一段最小啟動步驟清單下載 zip 包并解壓配置JAVA_HOME環(huán)境變量修改config/elasticsearch.yml設(shè)置cluster.name和discovery.type: single-node設(shè)置jvm.options里的堆內(nèi)存執(zhí)行bin\elasticsearch.bat啟動訪問http://localhost:9200驗證4.2 Serverless 部署的配置與驗證流程當(dāng)你準(zhǔn)備部署到 Serverless 環(huán)境事情就從裝一個單機進程變成了管理一套自動伸縮的計算集群。我用過的 Serverless 部署方式主要面向云廠商托管服務(wù)或者基于容器平臺自建。先說托管方式。通常你只需要創(chuàng)建一個 Serverless 項目填入要支持的地域、數(shù)據(jù)歸屬和網(wǎng)絡(luò)配置剩下的數(shù)據(jù)節(jié)點數(shù)量、分片分配都由平臺自動搞定。部署完可以直接拿到一個專用的接入地址體驗非常清爽。如果是自建我會建議把數(shù)據(jù)節(jié)點做成容器化工作負(fù)載讓它跑在支持橫向擴容的容器平臺上。部署的關(guān)鍵點有三處第一處節(jié)點配置里要指定遠(yuǎn)程存儲的地址和認(rèn)證信息。比如在elasticsearch.yml里配置對象存儲的 endpoint、bucket 和密鑰這些是數(shù)據(jù)節(jié)點連接遠(yuǎn)程存儲的橋梁。第二處必須保證所有配置的不變性。節(jié)點鏡像一旦構(gòu)建好運行參數(shù)不再修改要變就重新構(gòu)建鏡像。這樣節(jié)點掛了被替換時新起的節(jié)點就和舊的完全一樣這是無狀態(tài)部署的基礎(chǔ)。第三處要配置數(shù)據(jù)節(jié)點的存活探針。平臺應(yīng)該能夠定期檢查節(jié)點健康狀態(tài)一旦發(fā)現(xiàn)節(jié)點異常立刻拉一個新的節(jié)點替換而不需要人工介入。部署完成后的驗證我建議做三步檢查第一步確認(rèn)所有節(jié)點都能從遠(yuǎn)程存儲讀取分片元數(shù)據(jù)可以在數(shù)據(jù)節(jié)點的啟動日志里看到recovered相關(guān)記錄。第二步隨機殺掉一個節(jié)點確認(rèn)平臺自動恢復(fù)后查詢服務(wù)沒有出現(xiàn)長時間中斷。第三步人為打入少量索引數(shù)據(jù)然后刪除一個節(jié)點再看數(shù)據(jù)是否能正常檢索以確認(rèn)數(shù)據(jù)確實持久化在遠(yuǎn)程存儲上。4.3 與 Spring Boot 集成時需要注意的幾個參數(shù)服務(wù)端部署好之后實際業(yè)務(wù)應(yīng)用接入時最常見的就是 Spring Boot 項目。我通常用spring-data-elasticsearch配合 REST High Level Client 或者新版的ElasticsearchClient。集成時我最推薦直接使用官方的 transport 客戶端或 REST 客戶端因為它對 Spring Boot 生態(tài)兼容性好參數(shù)調(diào)整也方便。比較重要的配置項有這么幾個spring.elasticsearch.uris接入地址使用 Serverless 接入點時直接填為返回的 HTTPS URL。spring.elasticsearch.username/spring.elasticsearch.password認(rèn)證信息。spring.elasticsearch.connection-timeout和socket-timeout如果集群處在不同的地域網(wǎng)絡(luò)延遲偏高務(wù)必調(diào)大超時時間否則業(yè)務(wù)端很容易報ConnectionTimeOutException。集成時還要注意一個細(xì)節(jié)Serverless 環(huán)境通常會限制索引的自定義 mapping 不能隨意變更推薦把 mapping 和 setting 的模板提前定義好。如果直接在業(yè)務(wù)代碼里通過IndexRequest動態(tài)建索引可能會出現(xiàn)字段類型和模板不一致的報錯。我一般會在項目里放一份索引映射的初始化腳本部署新環(huán)境時先執(zhí)行一次避免奇奇怪怪的字段類型問題。5. 無狀態(tài)架構(gòu)下的讀寫流程與故障恢復(fù)邏輯5.1 寫入流程從協(xié)調(diào)層到遠(yuǎn)程存儲無狀態(tài)架構(gòu)下一次典型的寫入請求經(jīng)過的鏈路如下客戶端把寫入請求發(fā)到協(xié)調(diào)節(jié)點。協(xié)調(diào)節(jié)點對請求做解析、鑒權(quán)和路由找到合適的索引主分片所在的數(shù)據(jù)節(jié)點。數(shù)據(jù)節(jié)點接收請求后先寫 translog再寫入內(nèi)存 buffer。當(dāng) buffer 達(dá)到一定大小或時間達(dá)到刷新閾值觸發(fā) flush生成一個新的 segment。這個 segment 緊接著被上傳到遠(yuǎn)程共享存儲。等遠(yuǎn)程存儲確認(rèn)接收成功寫入請求才會返回成功。這段鏈路里我最在意的是 translog 和 segment 的安全。translog 如果丟了內(nèi)存 buffer 里的數(shù)據(jù)就丟了segment 如果沒傳到遠(yuǎn)程存儲這個分片就等于沒有持久化成功。因此無狀態(tài)架構(gòu)對這兩個操作的同步要求比較嚴(yán)格通常會等遠(yuǎn)程存儲返回 ACK 之后再給客戶端發(fā)成功響應(yīng)。5.2 查詢流程緩存與遠(yuǎn)程存儲的取舍查詢請求的路徑和寫入略有不同。客戶端請求到協(xié)調(diào)節(jié)點后協(xié)調(diào)節(jié)點把查詢廣播到所有相關(guān)分片的數(shù)據(jù)節(jié)點。每個數(shù)據(jù)節(jié)點先在本地緩存里查找相關(guān) segment本地沒有的再去遠(yuǎn)程存儲拉取。這里有一個取舍要注意如果本地緩存總是未命中幾次查詢之后緩存會逐漸暖起來后續(xù)延遲會下降但如果查詢范圍跨越大量 segment遠(yuǎn)程存儲的隨機讀會被放大。所以我在配置無狀態(tài)集群時會優(yōu)先保證頻繁查詢的索引足夠小并且設(shè)置合理的 segment 合并策略減少落到遠(yuǎn)程讀的次數(shù)。5.3 故障恢復(fù)演示從節(jié)點消失到業(yè)務(wù)無感這是我覺得無狀態(tài)架構(gòu)最優(yōu)秀的地方。假設(shè)某個數(shù)據(jù)節(jié)點因為硬件故障突然宕機傳統(tǒng)架構(gòu)此時要經(jīng)歷主分片重選舉、副本重分配、數(shù)據(jù)重新復(fù)制無狀態(tài)架構(gòu)里協(xié)調(diào)層會把這個節(jié)點標(biāo)記為異常平臺自動啟動一臺新數(shù)據(jù)節(jié)點。新節(jié)點啟動時不需要從其它節(jié)點復(fù)制數(shù)據(jù)而是先從遠(yuǎn)程存儲獲取這個分片的元信息再用遠(yuǎn)程讀取的方式直接對外提供服務(wù)。整個過程客戶端感知到的可能就是個別請求的響應(yīng)時間略微變長但不會出現(xiàn)整個索引不可查詢的情況。我開始做遷移實驗時做過一次破壞性測試在一個正常運行的無狀態(tài)集群里直接殺掉所有數(shù)據(jù)節(jié)點結(jié)果因為消費端有連接重試機制節(jié)點恢復(fù)后數(shù)據(jù)依舊可查。這正是計算無狀態(tài)、存儲有狀態(tài)的價值所在。6. 常見問題與排查技巧實錄6.1 啟動失敗heap 設(shè)置和端口占用我碰到最多的啟動失敗場景本地調(diào)試時八成是 heap 設(shè)置得不合理或者端口被占用。如果你看到native thread creation failed之類的錯誤通常是線程數(shù)或內(nèi)存超了。換個測試環(huán)境時先把jvm.options里的堆內(nèi)存調(diào)小一點比如 512MB等啟動成功再慢慢往上加。端口占用也很常見9200 和 9300 被占用時啟動日志會直接報Address already in use。Windows 下用netstat -ano | findstr 9200找出占用進程手動處理掉就行。還有一點容易忽略ES 默認(rèn)不允許以 root 身份在 Linux 下運行如果你正在容器里跑記得用非 root 用戶運行。Windows 下沒有這個限制但配置文件的權(quán)限要開放否則可能啟動時報access denied。6.2 數(shù)據(jù)節(jié)點無法連接遠(yuǎn)程存儲無狀態(tài)架構(gòu)里的一個高發(fā)問題數(shù)據(jù)節(jié)點配置了遠(yuǎn)程存儲但啟動后大量刷報錯檢查發(fā)現(xiàn)節(jié)點根本無法訪問對象存儲的 endpoint。排查思路我總結(jié)成一個順序確認(rèn)遠(yuǎn)程存儲 endpoint 可以被數(shù)據(jù)節(jié)點的網(wǎng)絡(luò)解析并且可以連通。在容器環(huán)境里做ping或curl測試。確認(rèn)訪問憑證配置正確。密鑰信息如果放在環(huán)境變量里要檢查數(shù)據(jù)節(jié)點的環(huán)境變量是否真的注入進去了。確認(rèn)訪問策略允許數(shù)據(jù)節(jié)點所在網(wǎng)絡(luò)的讀寫操作。很多云環(huán)境要通過 VPC 或安全組規(guī)則放行相應(yīng)端口和 IP。如果以上都沒問題但節(jié)點還是報錯檢查一下本地時鐘和遠(yuǎn)程服務(wù)器時鐘的偏差時間偏差超過 5 分鐘往往會導(dǎo)致請求簽名校驗失敗。6.3 查詢結(jié)果不全segment 與緩存機制有同事遇到過一個困惑數(shù)據(jù)寫入幾秒后查詢偶爾會漏掉一部分新數(shù)據(jù)。我第一反應(yīng)是查詢默認(rèn)的_refresh間隔。ES 默認(rèn) 1 秒刷新剛寫入的數(shù)據(jù)不會立刻對查詢可見這是正?，F(xiàn)象。如果你需要更強的實時性可以在寫入后強制refreshtrue但代價是頻繁刷新會生成大量小 segment影響后續(xù)查詢性能不建議在批量寫入場景使用。另一個點比較容易忽略無狀態(tài)架構(gòu)的本地緩存替換機制。當(dāng)本地緩存打滿節(jié)點會按策略淘汰部分 segment。如果查詢落在被淘汰的 segment 上節(jié)點需要重新從遠(yuǎn)程存儲加載這會表現(xiàn)為偶發(fā)的慢查詢。所以查詢耗時的曲線不應(yīng)該只看平均值一定要觀察 p99 分位值出現(xiàn)明顯抖動時優(yōu)先排查緩存命中率。6.4 我的排查工具與日常體檢清單很多剛?cè)胄械呐笥严矚g遇到問題就上論壇搜索我的習(xí)慣是先自己盯一套指標(biāo)集群健康狀態(tài)GET _cluster/health看status是不是 green。節(jié)點熱點GET _nodes/hot_threads看數(shù)據(jù)節(jié)點的 CPU 熱點。分片分配GET _cat/shards看有沒有分片長時間處于 UNASSIGNED。緩存命中GET _nodes/stats重點看query_cache和request_cache的命中率。存儲寫入延遲針對遠(yuǎn)程存儲做一次讀寫壓測確認(rèn)延遲是否在合理范圍內(nèi)。日常我是按周做一次體檢查一遍集群健康、看看數(shù)據(jù)增長和分片數(shù)量、檢查有沒有頻繁刷新的索引。這套習(xí)慣看起來簡單但能幫我提前攔住不少問題。最后說點個人體會從傳統(tǒng)集群遷到無狀態(tài)架構(gòu)我最大的收獲不是省了多少運維時間而是想清楚了一個問題在分布式系統(tǒng)里狀態(tài)放對位置比什么都重要。把數(shù)據(jù)狀態(tài)集中到遠(yuǎn)程共享存儲計算節(jié)點才能真正變成可丟棄的廉價資源。這個思路不只適用于 Elasticsearch很多大數(shù)據(jù)組件都在往這個方向走。如果你正準(zhǔn)備上手我個人建議先從一個小規(guī)模的非核心業(yè)務(wù)開始。先在本地按單節(jié)點模式跑通再部署到 Serverless 環(huán)境然后逐步加數(shù)據(jù)量、加查詢壓力。不要一上來就把核心業(yè)務(wù)遷過去無狀態(tài)架構(gòu)雖然穩(wěn)定但多了一層網(wǎng)絡(luò)依賴你得先摸清自己業(yè)務(wù)對延遲和成本的邊界在哪里。Windows 上啟動 Elasticsearch 的坑、Serverless 部署的配置、Spring Boot 集成的注意點這些具體操作我在前面已經(jīng)寫得很細(xì)了。你照著走一遍大概率能順利跑通。真碰到奇怪的問題再回頭看看第 6 部分的排查清單基本能定位個八九不離十。