1. 背景介紹
數據量：數千萬商戶數據
索引數據【檢索系統用】大小（15G/大概值）
存儲數據【存儲系統】大小（50G/大概值）【不包括圖片數據，這裏的圖片僅是圖片id，有專門的圖片服務存儲圖片】
訪問量：百萬PV
機器：32位機器，這個背景很重要，因此每個服務只能用3g內存，否則所有數據放到緩存中就好了
所有的數據都存儲在本地文件中，每個服務部署在一臺機器，對應一份數據
2. 架構圖 
如圖所示：最核心的兩個系統，一個是檢索系統【左邊部分】，一個是存儲系統【右邊部分】。。
那就先說說這兩個系統分別是幹什麼用的。
檢索系統：根據傳遞參數【例如：地址，類別，檢索詞等返回檢索結果列表】，這個列表每條數據包含的信息當然不是每條商戶的全部信息，用來【檢索用的屬性】肯定也不是商戶的全部信息，因此檢索系統的所使用的數據肯定是從全部數據中導出的有用的數據【提高效率，節省內存】。
存儲系統：存儲系統存儲着全部的商戶數據信息，包括圖片，點評，商戶信息等。當然這些數據的存儲有一定的邏輯，方便數據查詢和保存。
再說說這兩部分的交互吧：定期的將存儲系統中的數據導出，爲檢索系統建需要的索引，供檢索系統使用。但是有一個問題，大量的數據，想要建索引，需要的時間很長，因此索引只能定期的更新。而數據是會隨時更改的，這部分數據需要實時的被檢索到，因此檢索系統和存儲系統的交互就是爲了完成這兩個方面。一個是定期的將存儲系統的數據導出，建靜態索引給檢索系統使用，另外一個是將實時改變的數據分發給動態索引服務，建動態索引，保證實時更新的數據能夠被檢索到。
好吧，到現在該具體介紹下各個系統的各個服務是幹什麼的啦。
先說說檢索系統：index用於靜態數據檢索，主要的檢索邏輯在這裏。dindx用於動態數據的檢索和加載。sui檢索服務的初期處理和後期處理由其來完成【query分析，歸併各個檢索結果，重查等邏輯】。
再說說存儲系統：bds 數據的灌入【增刪改】bbts【存儲商戶信息】bps【點評信息】bui【查詢商戶信息】
dispatch【數據分發服務】
3. 分佈式和同步策略
分佈式策略：檢索系統：
1. 根據按城市搜索的特性，將數據分割【大城市數據，小城市數據】。
2. 每個內部apache可與若干sui服務通信，每個sui服務可與若干組檢索服務通信
(實際情況8組內部apache，4組sui，6組index/dindex，其中兩組sui三組index/dindex只檢索大城市數據，另外的只檢索小城市數據)
存儲系統：
1. Bbts/bps兩個服務一組，分爲若干組，bui服務也分爲若干組，每個bui可連接若干組bbts/bps(實際情況3組bbts/bps服務，兩組bui服務，其中一組bbts/bps不提供查詢服務)
1. dispatch和bds服務分別記錄同步日誌，dispatch服務和bbts和bps服務分別記錄同步點和同步日誌。Bbts和bps每次重啓後都會根據bds同步日誌和自己同步點同步數據。
2. 每次數據導出時，會停掉不提供查詢服務的(bbts/bps),會同時生成同步點數據文件，那麼，在數據導出重建索引後，dindex和index會重啓重新加載新的數據索引和相關數據，那麼dindex通過dispatch和同步點同步新的數據。
4.服務級別 通用服務結構：
監控進程主要工作：監控工作進程狀態，控制工作進程重啓
工作進程：真正提供服務的進程。
監控策略：
判斷消息隊列中待處理數目，若小於一個值，則認爲工作進程正常。
根據工作線程數開闢一塊共享內存，工作線程會更新對應狀態，若消息隊列中，待處理數大於某個值，且有線程上次狀態更新時間和當前時間小於某個值，則認爲工作進程正常。
否則的話發送信號，控制工作進程狀態。
服務間通信：
ACE
統一的package格式，key：value
加速：
Sui緩存
Index爲二級索引做了緩存
存儲系統數據和同步日誌存儲的結構和
索引結構
sui TaskBoard設計
圖片存儲結構