摘要:分布式架構(gòu)原理設(shè)計的理念就是分布式搜索引擎,底層實現(xiàn)還是基于的,核心思想是在多態(tài)機器上啟動多個進程實例,組成一個集群。
es分布式架構(gòu)原理
elasticsearch設(shè)計的理念就是分布式搜索引擎,底層實現(xiàn)還是基于Lucene的,核心思想是在多態(tài)機器上啟動多個es進程實例,組成一個es集群。一下是es的幾個概念:
接近實時
es是一個接近實時的搜索平臺,這就意味著,從索引一個文檔直到文檔能夠被搜索到有一個輕微的延遲
集群(cluster)
一個集群有多個節(jié)點(服務器)組成,通過所有的節(jié)點一起保存你的全部數(shù)據(jù)并且通過聯(lián)合索引和搜索功能的節(jié)點的集合,每一個集群有一個唯一的名稱標識
節(jié)點(node)
一個節(jié)點就是一個單一的服務器,是你的集群的一部分,存儲數(shù)據(jù),并且參與集群和搜索功能,一個節(jié)點可以通過配置特定的名稱來加入特定的集群,在一個集群中,你想啟動多少個節(jié)點就可以啟動多少個節(jié)點。
索引(index)
一個索引就是還有某些共有特性的文檔的集合,一個索引被一個名稱唯一標識,并且這個名稱被用于索引通過文檔去執(zhí)行搜索,更新和刪除操作。
類型(type)
type 在6.0.0已經(jīng)不贊成使用
文檔(document)
一個文檔是一個基本的搜索單元
總結(jié):
es中,存儲數(shù)據(jù)的基本單位就是索引,比如說es中存儲了一些訂單系統(tǒng)的銷售數(shù)據(jù),就因該在es中創(chuàng)建一個索引,order—index,所有的銷售數(shù)據(jù)就會都寫到這個索引里面去,一個索引就像數(shù)據(jù)庫。而type就相當于每一張表,
一個index里面可以有多個type,而mapping就相當于表的結(jié)構(gòu)定義,定義了什么字段類型等,你往index的一個type里添加一行數(shù)據(jù)就叫做一個document,每一個document有多個filed,每一個filed就代表這個document的一個字段的值。
分片(shards)
在一個搜索里存儲的數(shù)據(jù),潛在的情況下可能會超過單個節(jié)點的硬件的存儲限制,為了解決這個問題,elasticsearch便提供了分片的功能,它可以將索引劃分為多個分片,當你創(chuàng)建一個索引的時候,你就可以簡單的定義你想要的分片的數(shù)量,每一個分片本身是一個全功能的完全獨立的索引,可以部署到集群中的任何一個節(jié)點。分片的兩個總要原因:
(1)它允許你水平切分你的內(nèi)容卷
(2)它允許通過分片來分布和并執(zhí)行操作來應對日益增長的執(zhí)行量
復制(replica)
在一個網(wǎng)絡(luò)情況下,故障可能會隨時發(fā)生,有一個故障恢復機制是必須的,為了達到這個目的,ES允許你制作一個或多個拷貝放入一個叫做復制分片或短暫的復制品中。復制對于以下兩個主要原因很重要
(1)高可用。它提供了高可用的以來防止分片或者節(jié)點宕機,為此,一個非常重要的注意點就是絕對不要講一個分片的拷貝放在跟這個分片相同的機器上。
(2)高并發(fā)。它允許你的分片可以提供超出自身吞吐量的搜索服務,搜索行為可以在分片所有的拷貝中并行執(zhí)行。
總之,一個完整的流程就是,ES客戶端將一份數(shù)據(jù)寫入primary shard,它會將分成成對的shard分片,并將數(shù)據(jù)進行復制,ES客戶端取數(shù)據(jù)的時候就會在replica或primary 的shard中去讀。ES集群有多個節(jié)點,會自動選舉一個節(jié)點為master節(jié)點,這個master節(jié)點其實就是干一些管理類的操作,比如維護元數(shù)據(jù),負責切換primary shard 和replica shard的身份之類的,要是master節(jié)點宕機了,那么就會重新選舉下一個節(jié)點為master為節(jié)點。如果時非master宕機了,那么就會有master節(jié)點,讓那個宕機的節(jié)點上的primary shard的身份轉(zhuǎn)移到replica shard上,如果修復了宕機的那臺機器,重啟之后,master節(jié)點就會控制將缺失的replica shard 分配過去,同步后續(xù)的修改工作,讓集群恢復正常。
客戶端選擇一個node發(fā)送請求過去,這個node就是coordinating node (協(xié)調(diào)節(jié)點)
coordinating node,對document進行路由,將請求轉(zhuǎn)發(fā)給對應的node
實際上的node上的primary shard處理請求,然后將數(shù)據(jù)同步到replica node
coordinating node,如果發(fā)現(xiàn)primary node和所有的replica node都搞定之后,就會返回請求到客戶端
es讀數(shù)據(jù)過程查詢,GET某一條的數(shù)據(jù),寫入某個document,這個document會自動給你分配一個全局的唯一ID,同時跟住這個ID進行hash路由到對應的primary shard上面去,當然也可以手動的設(shè)置ID
客戶端發(fā)送任何一個請求到任意一個node,成為coordinate node
coordinate node 對document進行路由,將請求轉(zhuǎn)發(fā)到對應的node,此時會使用round-robin隨機輪訓算法,在primary shard 以及所有的replica中隨機選擇一個,讓讀請求負載均衡,
接受請求的node,返回document給coordinate note
coordinate node返回給客戶端
es搜索數(shù)據(jù)過程客戶端發(fā)送一個請求給coordinate node
協(xié)調(diào)節(jié)點將搜索的請求轉(zhuǎn)發(fā)給所有的shard對應的primary shard 或replica shard
query phase:每一個shard 將自己搜索的結(jié)果(其實也就是一些唯一標識),返回給協(xié)調(diào)節(jié)點,有協(xié)調(diào)節(jié)點進行數(shù)據(jù)的合并,排序,分頁等操作,產(chǎn)出最后的結(jié)果
fetch phase ,接著由協(xié)調(diào)節(jié)點,根據(jù)唯一標識去各個節(jié)點進行拉去數(shù)據(jù),最總返回給客戶端
寫入數(shù)據(jù)的底層原理數(shù)據(jù)先寫入到buffer里面,在buffer里面的數(shù)據(jù)時搜索不到的,同時將數(shù)據(jù)寫入到translog日志文件之中
如果buffer快滿了,或是一段時間之后,就會將buffer數(shù)據(jù)refresh到一個新的OS cache之中,然后每隔1秒,就會將OS cache的數(shù)據(jù)寫入到segment file之中,但是如果每一秒鐘沒有新的數(shù)據(jù)到buffer之中,就會創(chuàng)建一個新的空的segment file,只要buffer中的數(shù)據(jù)被refresh到OS cache之中,就代表這個數(shù)據(jù)可以被搜索到了。當然可以通過restful api 和Java api,手動的執(zhí)行一次refresh操作,就是手動的將buffer中的數(shù)據(jù)刷入到OS cache之中,讓數(shù)據(jù)立馬搜索到,只要數(shù)據(jù)被輸入到OS cache之中,buffer的內(nèi)容就會被清空了。同時進行的是,數(shù)據(jù)到shard之后,就會將數(shù)據(jù)寫入到translog之中,每隔5秒將translog之中的數(shù)據(jù)持久化到磁盤之中
重復以上的操作,每次一條數(shù)據(jù)寫入buffer,同時會寫入一條日志到translog日志文件之中去,這個translog文件會不斷的變大,當達到一定的程度之后,就會觸發(fā)commit操作。
將一個commit point寫入到磁盤文件,里面標識著這個commit point 對應的所有segment file
強行將OS cache 之中的數(shù)據(jù)都fsync到磁盤文件中去。
解釋:translog的作用:在執(zhí)行commit之前,所有的而數(shù)據(jù)都是停留在buffer或OS cache之中,無論buffer或OS cache都是內(nèi)存,一旦這臺機器死了,內(nèi)存的數(shù)據(jù)就會丟失,所以需要將數(shù)據(jù)對應的操作寫入一個專門的日志問價之中,一旦機器出現(xiàn)宕機,再次重啟的時候,es會主動的讀取translog之中的日志文件的數(shù)據(jù),恢復到內(nèi)存buffer和OS cache之中。
將現(xiàn)有的translog文件進行清空,然后在重新啟動一個translog,此時commit就算是成功了,默認的是每隔30分鐘進行一次commit,但是如果translog的文件過大,也會觸發(fā)commit,整個commit過程就叫做一個flush操作,我們也可以通過ES API,手動執(zhí)行flush操作,手動將OS cache 的數(shù)據(jù)fsync到磁盤上面去,記錄一個commit point,清空translog文件
補充:其實translog的數(shù)據(jù)也是先寫入到OS cache之中的,默認每隔5秒之中將數(shù)據(jù)刷新到硬盤中去,也就是說,可能有5秒的數(shù)據(jù)僅僅停留在buffer或者translog文件的OS cache中,如果此時機器掛了,會丟失5秒的數(shù)據(jù),但是這樣的性能比較好,我們也可以將每次的操作都必須是直接fsync到磁盤,但是性能會比較差。
如果時刪除操作,commit的時候會產(chǎn)生一個.del文件,里面講某個doc標記為delete狀態(tài),那么搜索的時候,會根據(jù).del文件的狀態(tài),就知道那個文件被刪除了。
如果時更新操作,就是講原來的doc標識為delete狀態(tài),然后重新寫入一條數(shù)據(jù)即可。
buffer每次更新一次,就會產(chǎn)生一個segment file 文件,所以在默認情況之下,就會產(chǎn)生很多的segment file 文件,將會定期執(zhí)行merge操作
每次merge的時候,就會將多個segment file 文件進行合并為一個,同時將標記為delete的文件進行刪除,然后將新的segment file 文件寫入到磁盤,這里會寫一個commit point,標識所有的新的segment file,然后打開新的segment file供搜索使用。
總之,segment的四個核心概念,refresh,flush,translog、merge
搜索的底層原理查詢過程大體上分為查詢和取回這兩個階段,廣播查詢請求到所有相關(guān)分片,并將它們的響應整合成全局排序后的結(jié)果集合,這個結(jié)果集合會返回給客戶端。
查詢階段
當一個節(jié)點接收到一個搜索請求,這這個節(jié)點就會變成協(xié)調(diào)節(jié)點,第一步就是將廣播請求到搜索的每一個節(jié)點的分片拷貝,查詢請求可以被某一個主分片或某一個副分片處理,協(xié)調(diào)節(jié)點將在之后的請求中輪訓所有的分片拷貝來分攤負載。
每一個分片將會在本地構(gòu)建一個優(yōu)先級隊列,如果客戶端要求返回結(jié)果排序中從from 名開始的數(shù)量為size的結(jié)果集,每一個節(jié)點都會產(chǎn)生一個from+size大小的結(jié)果集,因此優(yōu)先級隊列的大小也就是from+size,分片僅僅是返回一個輕量級的結(jié)果給協(xié)調(diào)節(jié)點,包括結(jié)果級中的每一個文檔的ID和進行排序所需要的信息。
協(xié)調(diào)節(jié)點將會將所有的結(jié)果進行匯總,并進行全局排序,最總得到排序結(jié)果。
取值階段
查詢過程得到的排序結(jié)果,標記處哪些文檔是符合要求的,此時仍然需要獲取這些文檔返回給客戶端
協(xié)調(diào)節(jié)點會確定實際需要的返回的文檔,并向含有該文檔的分片發(fā)送get請求,分片獲取的文檔返回給協(xié)調(diào)節(jié)點,協(xié)調(diào)節(jié)點將結(jié)果返回給客戶端。
倒排索引倒排索引就建立分詞與文檔之間的映射關(guān)系,在倒排索引之中,數(shù)據(jù)時面向分詞的而不是面向文檔的。
在海量數(shù)據(jù)中怎樣提高效率filesystem cache
ES的搜索引擎是嚴重的依賴底層的filesystem cache,如果給filesystem cache更多的內(nèi)存,盡量讓內(nèi)存可以容納所有的index segment file 索引數(shù)據(jù)文件
數(shù)據(jù)預熱
對于那些你覺得比較熱的數(shù)據(jù),經(jīng)常會有人訪問的數(shù)據(jù),最好做一個專門的緩存預熱子系統(tǒng),就是對熱數(shù)據(jù),每隔一段時間,你就提前訪問以下,讓數(shù)據(jù)進入filesystem cache里面去,這樣期待下次訪問的時候,性能會更好一些。
冷熱分離
關(guān)于ES的性能優(yōu)化,數(shù)據(jù)拆分,將大量的搜索不到的字段,拆分到別的存儲中去,這個類似于MySQL的分庫分表的垂直才分。
document的模型設(shè)計
不要在搜索的時候去執(zhí)行各種復雜的操作,盡量在document模型設(shè)計的時候,寫入的時候就完成了,另外對于一些復雜的操作,盡量要避免
分頁性能優(yōu)化
翻頁的時候,翻得越深,每個shard返回的數(shù)據(jù)越多,而且協(xié)調(diào)節(jié)點處理的時間越長,當然是用scroll,scroll會一次性的生成所有數(shù)據(jù)的一個快照,然后每次翻頁都是通過移動游標完成的。 api 只是在一頁一頁的往后翻
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/69738.html
摘要:這里有一份面試題相關(guān)總結(jié),涉及高并發(fā)分布式高可用相關(guān)知識點,在此分享給大家,希望大家能拿到一份理想的知識點會陸續(xù)更新在上,覺得還算湊和的話可以關(guān)注一下噢高并發(fā)架構(gòu)消息隊列為什么使用消息隊列消息隊列有什么優(yōu)點和缺點都有什么優(yōu)點和缺點如何保證消 這里有一份面試題相關(guān)總結(jié),涉及高并發(fā)、分布式、高可用相關(guān)知識點,在此分享給大家,希望大家能拿到一份理想的 Offer! 知識點會陸續(xù)更新在 Git...
本文是公眾號讀者jianfeng投稿的面試經(jīng)驗恭喜該同學成功轉(zhuǎn)型目錄:毅然轉(zhuǎn)型,沒頭蒼蠅制定目標,系統(tǒng)學習面試經(jīng)歷毅然轉(zhuǎn)崗,沒頭蒼蠅首先,介紹一下我的背景。本人坐標廣州,2016年畢業(yè)于一個普通二本大學,曾經(jīng)在某機構(gòu)培訓過Android。2018年初的時候已經(jīng)在兩家小公司工作干了兩年的android開發(fā),然后會一些Tomcat、Servlet之類的技術(shù),當時的年薪大概也就15萬這樣子。由于個人發(fā)展...
摘要:前言不少在傳統(tǒng)行業(yè)摸爬滾打的程序員越來越焦慮了,有些甚至睡不著覺。下面就幾個方面和大家談談傳統(tǒng)行業(yè)的技術(shù)人員如何轉(zhuǎn)型互聯(lián)網(wǎng)。傳統(tǒng)行業(yè)的程序員的晉升周期可能會非常長,年,甚至年時間才能做到高位。 前言 不少在傳統(tǒng)行業(yè)摸爬滾打的程序員越來越焦慮了,有些甚至睡不著覺。為什么?傳統(tǒng)行業(yè)的程序員們每天進行的都是業(yè)務代碼的編寫,接觸不到更新更好的技術(shù);公司的效益并不好,如未達到目標收益,只能進行瘦...
閱讀 2678·2021-10-14 09:42
閱讀 1217·2021-09-22 15:09
閱讀 3632·2021-09-09 09:33
閱讀 3093·2021-09-07 09:59
閱讀 3734·2021-09-03 10:34
閱讀 3683·2021-07-26 22:01
閱讀 2886·2019-08-30 13:06
閱讀 1267·2019-08-30 10:48