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

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

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

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

　　縱向擴展是升級服務器的硬

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

　　現(xiàn)在有個問題了，這600個數(shù)據(jù)如何路由到對應的機器。需要考慮如果均衡分配，假設我們600個數(shù)據(jù)都是統(tǒng)一的自增id數(shù)據(jù)，從1~600，分成3 堆可以采用 id mod 3的方式。其實在真實環(huán)境可能不是這種id是字符串。需要把字符串轉變?yōu)閔ashcode再進行取模。

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

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

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

　　一致性hash就是在這種應用背景提出來的，現(xiàn)在被廣泛應用于分布式緩存，比如memcached。下面簡單介紹下一致性hash的基本原理。最早的版本 http://dl.acm.org/citation.cfm?id=258660。國內網(wǎng)上有很多文章都寫的比較好。如： http://blog.csdn.