Lucene + Hadoop 分佈式搜索運行框架 Nut 1.0a9轉自http://www.linuxidc.com/Linux/2012-02/53113.htm

一、概述
 無論程序性能有多高，機器處理能力有多強，都會有其極限。可以快速方便的橫向與縱向擴展是Nut設計最重要的原則，以此原則造成以分佈式並行計算爲核心的架構設計。以分佈式並行計算爲核心的架構設計是Nut區別於Solr、Katta的地方。

Nut是一個Lucene+Hadoop分佈式並行計算搜索框架，能對千G以上索引提供7*24小時搜索服務。在服務器資源足夠的狀況下能達到每秒處理100萬次的搜索請求。
 
Nut開發環境：jdk1.6.0.23+lucene3.0.3+eclipse3.6.1+hadoop0.20.2+zookeeper3.3.2+hbase0.20.6+memcached+mongodb+linux

二、特新
 a、熱插拔
 b、可擴展
 c、高負載
 d、易使用,與現有項目無縫集成
e、支持排序
f、7*24服務
g、失敗轉移

三、搜索流程
Nut由Index、Search、Client、Cache和DB五部分構成。(Cache實現了對memcached的支持,DB實現了對hbase,mongodb的支持)
Client 處理用戶請求和對搜索結果排序。Search對請求進行搜索，Search上只放索引，數據存儲在DB中，Nut將索引和存儲分離。Cache緩存的是搜 索條件和結果文檔id。DB存儲着數據，Client根據搜索排序結果,取出當前頁中的文檔id從DB上讀取數據。

用戶發起搜索請求給由Nut Client構成的集羣，由某個Nut Client根據搜索條件查詢Cache服務器是否有該緩存，若是有緩存根據緩存的文檔id直接從DB讀取數據，若是沒有緩存將隨機選擇一組搜索服務器組 (Search Group i),將查詢條件同時發給該組搜索服務器組裏的n臺搜索服務器，搜索服務器將搜索結果返回給Nut Client由其排序，取出當前頁文檔id，將搜索條件和當前文檔id緩存，同時從DB讀取數據。

 

 四、索引流程
Hadoop Mapper/Reducer 創建索引。再將索引從HDFS分發到各個索引服務器。
對索引的更新分爲兩種：刪除和添加（更新分解爲刪除和添加）。
a、刪除
在HDFS上刪除索引，將生成的*.del文件分發到全部的索引服務器上去或者對HDFS索引目錄刪除索引再分發到對應的索引服務器上去。
b、添加
新添加的數據用另外一臺服務器來生成。
刪除和添加步驟可按不一樣定時策略來實現。

五、Nut分佈式並行計算特色
Nut分佈式並行計算雖然也是基於M/R模型，可是與Hadoop M/R模型是不一樣的。在Hadoop M/R模型中 Mapper和Reducer是一個完整的流程，Reducer依賴於Mapper。數據源經過Mapper分發自己就會消耗大量的I/O，而且是消耗I /O最大的部分。因此Hadoop M/R 併發是有限的。
Nut M/R模型是將Mapper和Reducer分離，各自獨立存在。在Nut中 索引以及索引管理 構成M,搜索以及搜索服務器組 構成 R。
以 一個分類統計來講明Nut分佈式並行計算的流程。假設有10個分類，對任意關鍵詞搜索要求統計出該關鍵詞在這10個分類中的總數。同時假設有10組搜索服 務器。索引以及索引管理進行索引數據的Mapper，這塊是後臺獨自運行管理的。Nut Client將這10個分類統計分發到10組搜索服務器上，每組搜索服務器對其中一個分類進行Reducer，而且每組搜索服務器可進行多級 Reducer。最後將最終結果返回給Nut Client。

 

 六、設計圖

 

 

   
七、Zookeeper服務器狀態管理策略

  

  

在架構設計上經過使用多組搜索服務器能夠支持每秒處理100萬個搜索請求。
每組搜索服務器能處理的搜索請求數在1萬—1萬5千之間。若是使用100組搜索服務器，理論上每秒可處理100萬個搜索請求。

假如每組搜索服務器有100份索引放在100臺正在運行中搜索服務器(run)上，那麼將索引按照以下的方式放在備用中搜索服務器 (bak)上：index 1,index 2,index 3,index 4,index 5,index 6,index 7,index 8,index 9,index 10放在B 1 上，index 6,index 7,index 8,index 9,index 10,index 11,index 12,index 13,index 14,index 15放在B 2上。。。。。。index 96,index 97,index 98,index 99,index 100,index 5,index 4,index 3,index 2,index 1放在最後一臺備用搜索服務器上。那麼每份索引會存在3臺機器中（1份正在運行中，2份備份中）。
儘管這樣設計每份索引會存在3臺機器中，仍然不是絕對安全的。假如運行中的index 1,index 2,index 3同時宕機的話，那麼就會有一份索引搜索服務沒法正確啓用。這樣設計，做者認爲是在安全性和機器資源二者之間一個比較適合的方案。

備用中的搜索服務器會定時檢查運行中搜索服務器的狀態。一旦發現與本身索引對應的服務器宕機就會向lock申請分佈式鎖，獲得分佈式鎖的服務器就將本身加入到運行中搜索服務器組，同時從備用搜索服務器組中刪除本身，並中止運行中搜索服務器檢查服務。

爲可以更快速的獲得搜索結果，設計上將搜索服務器分優先等級。一般是將最新的數據放在一臺或幾臺內存搜索服務器上。一般狀況下前幾頁數據能在這幾臺搜索服務器裏搜索到。若是在這幾臺搜索服務器上沒有數據時再向其餘舊數據搜索服務器上搜索。優先搜索等級的邏輯是這樣的：9最大爲搜索所有服務器而且9不能做爲level標識。當搜索等級level爲1，搜索優先級爲1的服務器，當level爲2時搜索優先級爲1和2的服務器，依此類推。