Solr是一個獨立的企業級搜索應用服務器，它對外提供類似于Web-service的API接口。用戶可以通過http請求，向搜索引擎服務器提交一定格式的XML文件，生成索引. 互聯網創業中大部分人都是草根創業，這個時候沒有強勁的服務器，也沒有錢去買很昂貴的海量數據庫。

　　Solr是一個獨立的企業級搜索應用服務器，它對外提供類似于Web-service的API接口。用戶可以通過http請求，向搜索引擎服務器提交一定格式的XML文件，生成索引.

　　互聯網創業中大部分人都是草根創業，這個時候沒有強勁的服務器，也沒有錢去買很昂貴的海量數據庫。在這樣嚴峻的條件下，一批又一批的創業者從創業中獲得成功，這個和當前的開源技術、海量數據架構有著必不可分的關系。比如我們使用mysql、nginx等開源軟件，通過架構和低成本服務器也可以搭建千萬級用戶訪問量的系統。新浪微博、淘寶網、騰訊等大型互聯網公司都使用了很多開源免費系統搭建了他們的平臺。所以，用什么沒關系，只要能夠在合理的情況下采用合理的解決方案。

　　那怎么搭建一個好的系統架構呢?這個話題太大，這里主要說一下數據分流的方式。比如我們的數據庫服務器只能存儲200個數據，突然要搞一個活動預估達到600個數據。

　　可以采用兩種方式：橫向擴展或者縱向擴展。

　　縱向擴展是升級服務器的硬件資源。但是隨著機器的性能配置越高，價格越高，這個代價對于一般的小公司是承擔不起的。

　　橫向擴展是采用多個廉價的機器提供服務。這樣一個機器只能處理200個數據、3個機器就可以處理600個數據了，如果以后業務量增加還可以快速配置增加。在大多數情況都選擇橫向擴展的方式。如下圖：

　　現在有個問題了，這600個數據如何路由到對應的機器。需要考慮如果均衡分配，假設我們600個數據都是統一的自增id數據，從1~600，分成3 堆可以采用 id mod 3的方式。其實在真實環境可能不是這種id是字符串。需要把字符串轉變為hashcode再進行取模。

　　目前看起來是不是解決我們的問題了，所有數據都很好的分發并且沒有達到系統的負載。但如果我們的數據需要存儲、需要讀取就沒有這么容易了。業務增多怎么辦，大家按照上面的橫向擴展知道需要增加一臺服務器。但是就是因為增加這一臺服務器帶來了一些問題。看下面這個例子，一共9個數，需要放到2臺機器(1、2)上。各個機器存放為：1號機器存放1、3、5、7、9 ，2號機器存放 2、4、6、8。如果擴展一臺機器3如何，數據就要發生大遷移，1號機器存放1、4、7, 2號機器存放2、5、8, 3號機器存放3、6、9。如圖：

　　從圖中可以看出 1號機器的3、5、9遷移出去了、2好機器的4、6遷移出去了，按照新的秩序再重新分配了一遍。數據量小的話重新分配一遍代價并不大，但如果我們擁有上億、上T級的數據這個操作成本是相當的高，少則幾個小時多則數天。并且遷移的時候原數據庫機器負載比較高，那大家就有疑問了，是不是這種水平擴展的架構方式不太合理?

　　—————————–華麗分割線—————————————

　　一致性hash就是在這種應用背景提出來的，現在被廣泛應用于分布式緩存，比如memcached。下面簡單介紹下一致性hash的基本原理。最早的版本 ?id=258660。國內網上有很多文章都寫的比較好。如：

　　下面簡單舉個例子來說明一致性hash。

　　準備：1、2、3 三臺機器

　　還有待分配的9個數 1、2、3、4、5、6、7、8、9

　　一致性hash算法架構

　　步驟

　　一、構造出來 2的32次方 個虛擬節點出來，因為計算機里面是01的世界，進行劃分時采用2的次方數據容易分配均衡。另 2的32次方是42億，我們就算有超大量的服務器也不可能超過42億臺吧，擴展和均衡性都保證了。

　　二、將三臺機器分別取IP進行hashcode計算(這里也可以取hostname，只要能夠唯一區別各個機器就可以了)，然后映射到2的32次方上去。比如1號機器算出來的hashcode并且mod (2^32)為 123(這個是虛構的)，2號機器算出來的值為 2300420，3號機器算出來為 90203920。這樣三臺機器就映射到了這個虛擬的42億環形結構的節點上了。

　　三、將數據(1-9)也用同樣的方法算出hashcode并對42億取模將其配置到環形節點上。假設這幾個節點算出來的值為 1：10，2：23564，3：57，4：6984，5：5689632，6：86546845，7：122，8：3300689，9：135468。可以看出 1、3、7小于123， 2、4、9 小于 2300420 大于 123， 5、6、8 大于 2300420 小于90203920。從數據映射到的位置開始順時針查找，將數據保存到找到的第一個Cache節點上。如果超過2^32仍然找不到Cache節點，就會保存到第一個Cache節點上。也就是1、3、7將分配到1號機器，2、4、9將分配到2號機器，5、6、8將分配到3號機器。

　　這個時候大家可能會問，我到現在沒有看見一致性hash帶來任何好處，比傳統的取模還增加了復雜度。現在馬上來做一些關鍵性的處理，比如我們增加一臺機器。按照原來我們需要把所有的數據重新分配到四臺機器。一致性hash怎么做呢?現在4號機器加進來，他的hash值算出來取模后是12302012。 5、8 大于2300420 小于12302012 ，6 大于 12302012 小于90203920 。這樣調整的只是把5、8從3號機器刪除，4號機器中加入 5、8。

　　同理，刪除機器怎么做呢，假設2號機器掛掉，受影響的也只是2號機器上的數據被遷移到離它節點，上圖為4號機器。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com