Elasticsearch路由機(jī)制介紹

Elasticsearch的路由機(jī)制與其分片機(jī)制有著直接的關(guān)系。Elasticsearch的路由機(jī)制即是通過哈希算法，將具有相同哈希值的文檔放置到同一個主分片中。這個和通過哈希算法來進(jìn)行負(fù)載均衡幾乎是一樣的。

而Elasticsearch也有一個默認(rèn)的路由算法：它會將文檔的ID值作為依據(jù)將其哈希到相應(yīng)的主分片上，這種算法基本上會保持所有數(shù)據(jù)在所有分片上的一個平均分布，而不會產(chǎn)生數(shù)據(jù)熱點(diǎn)。

而我們?yōu)槭裁磿枰远x的Routing模式呢？首先默認(rèn)的Routing模式在很多情況下都是能滿足我們的需求的——平均的數(shù)據(jù)分布、對我們來說是透明的、多數(shù)時候性能也不是問題。但是在我們更深入地理解我們的數(shù)據(jù)的特征之后，使用自定義的Routing模式可能會給我們帶來更好的性能。

假設(shè)你有一個100個分片的索引。當(dāng)一個請求在集群上執(zhí)行時會發(fā)生什么呢？

1. 這個搜索的請求會被發(fā)送到一個節(jié)點(diǎn)

2. 接收到這個請求的節(jié)點(diǎn)，將這個查詢廣播到這個索引的每個分片上（可能是主分片，也可能是復(fù)制分片）

3. 每個分片執(zhí)行這個搜索查詢并返回結(jié)果

4. 結(jié)果在通道節(jié)點(diǎn)上合并、排序并返回給用戶

因為默認(rèn)情況下，Elasticsearch使用文檔的ID（類似于關(guān)系數(shù)據(jù)庫中的自增ID，當(dāng)然，如果不指定ID的話，Elasticsearch使用的是隨機(jī)值）將文檔平均的分布于所有的分片上，這導(dǎo)致了Elasticsearch不能確定文檔的位置，所以它必須將這個請求廣播到所有的100個分片上去執(zhí)行。這同時也解釋了為什么主分片的數(shù)量在索引創(chuàng)建的時候是固定下來的，并且永遠(yuǎn)不能改變。因為如果分片的數(shù)量改變了，所有先前的路由值就會變成非法了，文檔相當(dāng)于丟失了。

而自定義的Routing模式，可以使我們的查詢更具目的性。我們不必盲目地去廣播查詢請求，取而代之的是：我們要告訴Elasticsearch我們的數(shù)據(jù)在哪個分片上。

原來的查詢語句：“請告訴我，USER1的文檔數(shù)量一共有多少”

使用自定義Routing（在USESR　ID上）后的查詢語句：“請告訴我，USER1的文檔數(shù)量一共有多少，它就在第三個分片上，其它的分片就不要去掃描了”

指定個性化路由

所有的文檔API（get，index，delete，update和mget）都能接收一個routing參數(shù)，可以用來形成個性化文檔分片映射。一個個性化的routing值可以確保相關(guān)的文檔存儲到同樣的分片上——比如，所有屬于同一個用戶的文檔。

第一種方法，也是比較直觀的方法就是直接在請求的URL中指定routing參數(shù)：

第二種方法就是直接從文檔中提取到對應(yīng)的路由值：

利用路由機(jī)制的查詢

利用路由機(jī)制的查詢也是非常簡單明了的，只需要在查詢中指定對應(yīng)的路由值即可：

當(dāng)然，也可以同時指定多個路由值，方法也是顯而易見的，只需要在查詢參數(shù)中指定多個路由值即可：

路由機(jī)制的總結(jié)

實際上，如果不明確指明使用路由機(jī)制，實際上路由機(jī)制也是在發(fā)揮作用的，只是默認(rèn)的路由值是文檔的id而已。而個性化路由的需求主要是和業(yè)務(wù)相關(guān)的。默認(rèn)的路由（如果是自動的生成的id）直觀上會把所有的文檔隨機(jī)分配到一個分片上，而個性化的路由值就是和業(yè)務(wù)相關(guān)的了。這也會造成一些潛在的問題，比如user123本身的文檔就非常多，有數(shù)十萬個，而其他大多數(shù)的用戶只有幾個文檔，這樣的話就會導(dǎo)致user123所在的分片較大，出現(xiàn)數(shù)據(jù)偏移的情況，特別是多個這樣的用戶處于同一分片的時候，現(xiàn)象會更明顯。具體的使用還是要結(jié)合實際的應(yīng)用場景來選擇的。