一、管理方式

ElasticSearch作為最常用的搜索引擎組件，在系統(tǒng)架構(gòu)中發(fā)揮極其重要的能力，可以極大的提升數(shù)據(jù)的加載和檢索效率；但不可否認(rèn)的是，在長期的應(yīng)用實(shí)踐中，也發(fā)現(xiàn)很多不好處理的流程和場(chǎng)景；

從直觀感覺上說，業(yè)務(wù)中對(duì)索引的使用主要涉及如圖的幾個(gè)流程，其核心也就是索引的結(jié)構(gòu)維護(hù)與數(shù)據(jù)的流動(dòng)管理兩個(gè)模塊；

如果數(shù)據(jù)結(jié)構(gòu)比較簡(jiǎn)單且體量小，那么使用起來可能很順手；如果數(shù)據(jù)主體復(fù)雜且會(huì)動(dòng)態(tài)擴(kuò)展，并且體量偏大，那么就很容易踩中一些比較坑的點(diǎn)；

比如：索引中字段一旦有誤，調(diào)整的流程十分復(fù)雜；數(shù)據(jù)流向索引中的方式，需要根據(jù)場(chǎng)景靈活選擇；以及數(shù)據(jù)查詢時(shí)的深度分頁問題；下面將圍繞這些問題來總結(jié)下應(yīng)對(duì)策略；

順帶補(bǔ)充一句，其實(shí)很多組件在應(yīng)用的時(shí)候都有不太符合預(yù)期的地方，所以在集成時(shí)可以考慮編寫自定義的管理程序，來解決使用時(shí)可能存在的問題；

二、結(jié)構(gòu)維護(hù)

對(duì)于ES索引的結(jié)構(gòu)維護(hù)，數(shù)據(jù)主體如果相對(duì)簡(jiǎn)單的話，可以考慮手動(dòng)管理，但實(shí)際上使用索引時(shí)，通常主體結(jié)構(gòu)都比較復(fù)雜，字段個(gè)數(shù)超過三五十都很常見，所以基于流程化的管理很有必要；

?結(jié)構(gòu)映射：將需要構(gòu)建索引的主體結(jié)構(gòu)，在字段庫中統(tǒng)一維護(hù)，值得注意的是字段名稱和類型，字段可以與關(guān)系型數(shù)據(jù)庫的查詢一致，但是不同組件類型的描述不一樣，尤其對(duì)ES來說，如果字段類型不合理，會(huì)影響搜索的使用；

索引結(jié)構(gòu)：在實(shí)際的業(yè)務(wù)場(chǎng)景中，字段的信息是會(huì)動(dòng)態(tài)變化的，這就會(huì)給索引結(jié)構(gòu)的維護(hù)帶來很多麻煩，字段的增減都好管理，但是如果涉及類型的變動(dòng)，則存在索引重建的過程，會(huì)導(dǎo)致數(shù)據(jù)多次重新調(diào)度，這也是風(fēng)險(xiǎn)較高的操作；

程序維護(hù)：這種結(jié)構(gòu)維護(hù)的機(jī)制，其核心目的是把整個(gè)流程進(jìn)行程序化管理，避免人工進(jìn)行干預(yù)，以此來確保索引結(jié)構(gòu)的穩(wěn)定擴(kuò)展；

不得不提的一個(gè)經(jīng)驗(yàn)教訓(xùn)，曾經(jīng)在管理業(yè)務(wù)日志的索引結(jié)構(gòu)時(shí)，出現(xiàn)過一次誤刪動(dòng)作，好在可以重新構(gòu)建和數(shù)據(jù)備份恢復(fù)，但是依舊給心里留下了幾厘米的陰影，此后也將維護(hù)流程徹底程序化，避免失誤動(dòng)作發(fā)生；

三、數(shù)據(jù)調(diào)度

1、同步方案

數(shù)據(jù)的調(diào)度管理，其本質(zhì)就是將數(shù)據(jù)從一個(gè)容器向另一個(gè)容器搬運(yùn)或者拷貝，其核心操作就是讀和寫兩個(gè)動(dòng)作，但是為了讓流程具備容錯(cuò)和穩(wěn)定性，通常需要做策略和方案的設(shè)計(jì)；

?同步雙寫：對(duì)數(shù)據(jù)的實(shí)時(shí)性要求極高，通常在一個(gè)事務(wù)中完成數(shù)據(jù)的雙寫動(dòng)作，保證數(shù)據(jù)層面的強(qiáng)一致性；

異步解耦：在完成數(shù)據(jù)庫的寫動(dòng)作之后，基于MQ消息解耦索引的寫入，流程存在輕微的延遲，如果消費(fèi)失敗會(huì)導(dǎo)致數(shù)據(jù)缺失；

定時(shí)任務(wù)：通過任務(wù)調(diào)度的方式，以指定的時(shí)間周期執(zhí)行新增數(shù)據(jù)的同步機(jī)制，存在明顯的時(shí)效問題；

組件同步：采用合適的同步組件，比如官方提供的組件或者一些第三方開源的組件，在原理上與任務(wù)同步類似；

數(shù)據(jù)同步的選型方案有多種，如何選擇完全看具體的場(chǎng)景，在過往的使用過程中，對(duì)于核心業(yè)務(wù)會(huì)采用同步雙寫，對(duì)于內(nèi)部的活動(dòng)類業(yè)務(wù)會(huì)采用異步的方式，對(duì)于業(yè)務(wù)日志會(huì)采用任務(wù)調(diào)度，對(duì)于系統(tǒng)的監(jiān)控或執(zhí)行日志則多是依賴同步組件；

2、中斷和恢復(fù)

無論采用何種方式將數(shù)據(jù)同步到索引中，都不得不面對(duì)一個(gè)靈魂問題，如果流程突然異常中斷，恢復(fù)后如何保證索引數(shù)據(jù)不丟失？這個(gè)問題適應(yīng)于很多復(fù)雜的流程；

容錯(cuò)性是衡量一個(gè)復(fù)雜流程的核心指標(biāo)，比如在索引數(shù)據(jù)同步的過程，需要短暫性的暫停，或者流程被迫中斷時(shí)，都應(yīng)該具備恢復(fù)后自動(dòng)修復(fù)索引中數(shù)據(jù)缺失的能力；

ES實(shí)踐中一個(gè)非常經(jīng)典的問題，修改索引的結(jié)構(gòu)時(shí)需要進(jìn)行索引重建，此時(shí)要將當(dāng)前索引遷入臨時(shí)索引中，在完成索引結(jié)構(gòu)調(diào)整之后，需要從臨時(shí)索引中遷回?cái)?shù)據(jù)，在此過程中，可以對(duì)服務(wù)交互的索引名稱動(dòng)態(tài)調(diào)整；

當(dāng)然也可以直接使用臨時(shí)索引作為交互索引，避免一次遷移動(dòng)作，這種動(dòng)態(tài)的識(shí)別需要在服務(wù)中嵌入，在整個(gè)??reindex??過程中要避免手動(dòng)干預(yù)，個(gè)人還是更相信程序的安全性和準(zhǔn)確性；

四、刷新策略

在向ES索引中寫數(shù)據(jù)時(shí)，存在三種不同的數(shù)據(jù)刷新機(jī)制，查看??6.8???版本的設(shè)置中，參數(shù)??refresh_interval??設(shè)置的是1s時(shí)間，即執(zhí)行寫入動(dòng)作1秒后數(shù)據(jù)才可以被搜索到，避免頻繁寫入消耗過多的資源；

NONE：默認(rèn)的刷新策略，請(qǐng)求提交之后不會(huì)等待數(shù)據(jù)刷新，降低資源消耗但數(shù)據(jù)實(shí)時(shí)性低；

IMMEDIATE：請(qǐng)求提交后立即刷新索引，數(shù)據(jù)的實(shí)時(shí)性很高但是資源消耗過大，API文檔中建議測(cè)試使用；

WAIT_UNTIL：請(qǐng)求提交之后會(huì)等待索引刷新完成才會(huì)結(jié)束，相對(duì)來說是一種比較平衡的策略；

刷新機(jī)制對(duì)于索引的數(shù)據(jù)維護(hù)來說，主要在增刪改的動(dòng)作中，對(duì)即時(shí)查詢有直接的影響，至于如何選擇還是要結(jié)合具體的場(chǎng)景，尤其與同步方案關(guān)聯(lián)密切，也可以在索引交互中動(dòng)態(tài)維護(hù)策略，來應(yīng)對(duì)不時(shí)之需；

五、深度分頁

對(duì)于數(shù)據(jù)查詢來說，幾乎都存在分頁的需求，在常見的應(yīng)用中，不斷下拉的功能都是存在最大的極限值；

ES中常用From/Size進(jìn)行分頁查詢，但是存在一個(gè)限制，在索引的設(shè)置中存在??max_result_window???分頁深度的限制，??6.8??版本默認(rèn)值是10000條，即10000之后的數(shù)據(jù)無法使用From/Size翻頁；

先從實(shí)際應(yīng)用場(chǎng)景來分析，大多數(shù)的翻頁需求最多也就前10頁左右，所以從這個(gè)角度考慮，ES的翻頁限制在合理區(qū)間，在實(shí)踐中也存在對(duì)部分索引調(diào)高的情況，暫未出現(xiàn)明顯問題；

再從技術(shù)角度來思考一下，如果翻頁的參數(shù)過大意味著更多的數(shù)據(jù)過濾，那計(jì)算資源的占用也會(huì)升高，ES引擎的強(qiáng)大在于搜索能力，檢索出符合要求的數(shù)據(jù)即可；

不管是ES還是其它類似的分布式存儲(chǔ)組件，甚至是MySQL分庫分表模式，其本質(zhì)都是數(shù)據(jù)分布在不同服務(wù)節(jié)點(diǎn)的不同數(shù)據(jù)片上；常規(guī)的執(zhí)行原理都是給請(qǐng)求分配一個(gè)主節(jié)點(diǎn)，協(xié)調(diào)各個(gè)節(jié)點(diǎn)執(zhí)行相同的查詢，并完成結(jié)果匯總和響應(yīng)，深度分頁時(shí)計(jì)算資源的占用自然非常高；

如果一定需要深度分頁，在??6.8???的版本中提供了??Scroll???或??Search-After??兩種其他的方式，用法參考相關(guān)文檔即可。

六、參考源碼

編程文檔： https://gitee.com/cicadasmile/butte-java-note

應(yīng)用倉庫： https://gitee.com/cicadasmile/butte-flyer-parent