本發(fā)明屬于海量數(shù)據(jù)搜索技術(shù)領域，具體涉及一種針對多搜索集群對外提供搜索服務的管理方法及系統(tǒng)。

背景技術(shù)：

搜索系統(tǒng)從海量數(shù)據(jù)中檢索相匹配的目標數(shù)據(jù)提供給用戶瀏覽，是目前主流電子商務平臺(B2B，B2C等)的主要應用場景。在數(shù)據(jù)日趨龐大，搜索匹配規(guī)則日趨復雜的今天，單靠一個搜索應用的集群對外服務，在追求高可用服務的今天，已經(jīng)不能滿足用戶的需求。構(gòu)建搜索系統(tǒng)集群服務，能夠解決國內(nèi)目前實際上網(wǎng)絡分為電信，網(wǎng)通兩個不同網(wǎng)絡下的訪問速度，尤其針對多數(shù)據(jù)中心(簡稱DC)部署的業(yè)務系統(tǒng)，搜索系統(tǒng)天然就面臨一個跨DC部署應用的現(xiàn)實環(huán)境。

物理DC的區(qū)分如果還能夠人工進行搜索系統(tǒng)集群服務管理的話，那么由于邏輯功能上的區(qū)分集群的需求，則不可能單單依靠根據(jù)網(wǎng)絡硬件條件所劃分的幾個固定集群即可滿足。例如搜索業(yè)務是隨著用戶需求可能隨時需要調(diào)整搜索的匹配規(guī)則，包括不同的匹配規(guī)則可能需要在線上進行并行的用戶實際應用試驗，根據(jù)搜索結(jié)果和用戶行為的反饋，再動態(tài)進行搜索規(guī)則和參數(shù)的調(diào)整。再例如搜索除了用戶實際使用外，各大搜索引擎的爬蟲也會自動進行爬蟲抓取網(wǎng)站內(nèi)容，而當這種抓取量對搜索服務器造成極大負荷的時候，我們想要人為的區(qū)分爬蟲觸發(fā)的搜索請求和真實用戶訪問的搜索請求，將兩種請求進行不同的服務對待的時候。這都需要我們能夠靈活的通過配置不同的搜索系統(tǒng)集群服務來滿足這種管理要求。而本發(fā)明就是為了針對這種現(xiàn)實的技術(shù)應用場景，通過路由表技術(shù)的方式，將搜索集群對外服務的路由進行管理，達到集群服務調(diào)度的目的。目前一般的搜索系統(tǒng)，都是通過將搜索服務對外服務的地址，配置在固化的搜索客戶端中，一般會配置多個對外服務地址，作為提高可用性的保證。但如果這些地址都不可用時，搜索客戶端會直接報錯。另外一般的搜索系統(tǒng)，在對外服務中是不允許同時存在兩個同名的搜索服務，會出現(xiàn)同名錯誤。而本發(fā)明支持對外服務中的可以存在任意多個重名的搜索業(yè)務，且可以通過配置不同的訪問策略，支持多個同名搜索業(yè)務的不同集群按照不同的業(yè)務邏輯對外提供搜索服務，并且本發(fā)明通過客戶端緩存路由表信息的方式，即使客戶端配置的服務地址全部出錯，仍然能夠與可用服務器建立連接，檢索得到正常的搜索結(jié)果。

技術(shù)實現(xiàn)要素：

為了解決搜索客戶端配置的搜索地址出錯和滿足搜索需要同名搜索服務同時存在的問題，本發(fā)明目的在于，提供一種基于路由表的搜索系統(tǒng)集群服務管理的方法及系統(tǒng)，旨在提高搜索系統(tǒng)集群服務的可用性，即使客戶端配置的搜索集群的服務節(jié)點出現(xiàn)故障，客戶端仍然能夠通過路由表找到其他可用的搜索集群服務節(jié)點；同時通過路由表存放不同集群的服務信息，使搜索系統(tǒng)可以根據(jù)不同訪問策略調(diào)用若干集群下的同名搜索服務。同時本發(fā)明也能改良后應用與其他分布式應用系統(tǒng)的集群服務管理。

本發(fā)明技術(shù)方案如下：一種基于路由表的搜索系統(tǒng)集群服務管理的方法，通過對搜索服務器進行邏輯集群劃分，將劃分所得的集群信息存在路由表模塊中，并構(gòu)建多個對外提供集群服務的搜索應用請求轉(zhuǎn)發(fā)器，這些請求轉(zhuǎn)發(fā)器能統(tǒng)一從路由表信息中獲取集群服務的分布，并面向搜索客戶端提供服務結(jié)果應答和搜索請求轉(zhuǎn)發(fā)；搜索客戶端client提出的搜索服務的索引數(shù)據(jù)被復制多份，分配在不同的搜索服務應用中；通過搜索路由表系統(tǒng)記錄搜索服務在搜索服務應用的分配情況，同時記錄所有搜索服務應用和由他們組合而成的搜索集群；搜索請求分發(fā)系統(tǒng)接收客戶端發(fā)出的搜索服務請求，根據(jù)請求內(nèi)容查詢路由表系統(tǒng)router中關(guān)于本次搜索服務的路由信息，將搜索請求轉(zhuǎn)發(fā)給相應的搜索服務應用replica-search server，得到結(jié)果后再把結(jié)果回發(fā)給搜索客戶端，具體步驟包括：

步驟1：在搜索服務器上構(gòu)建多個能備份搜索服務信息的搜索服務應用(replica-searh Server)，并將實際的搜索服務(collection)分配在這些搜索服務器(replica-Searh Server)上；

步驟2：若干個搜索服務應用(replica-Searh Server)集合，組成一個搜索系統(tǒng)集群(cluster)；

步驟3：在路由表系統(tǒng)(router)中注冊、記錄及管理所有搜索系統(tǒng)集群內(nèi)的搜索服務分布的信息；

步驟4：配置與搜索客戶端(client)指定連接的搜索請求分發(fā)系統(tǒng)，當客戶端發(fā)出搜索請求時，能直接與搜索請求分發(fā)系統(tǒng)Dispatcher通信；當客戶端與該指定連接的搜索請求分發(fā)系統(tǒng)成功建立通信后，客戶端同時從路由表系統(tǒng)中自動獲取其他可用的搜索請求分發(fā)系統(tǒng)的地址信息；

所述搜索服務信息會復制多個備份，并被分配到不同的搜索服務應用replica-search server中；所述搜索路由表系統(tǒng)router包含搜索服務應用replica-search server和其內(nèi)搜索服務的屬性信息及分布信息；所述搜索請求轉(zhuǎn)發(fā)系統(tǒng)dispatcher接收客戶端發(fā)出的搜索服務請求，并根據(jù)請求中的信息，通過根據(jù)在router查詢所需搜索服務的地址信息，將搜索服務請求轉(zhuǎn)發(fā)至相應的搜索服務集群及其內(nèi)的搜索服務應用，獲取到結(jié)果后經(jīng)由搜索請求轉(zhuǎn)發(fā)系統(tǒng)dispatcher返回給客戶端；

步驟5：搜索請求分發(fā)系統(tǒng)(dispatcher)收到來自搜索客戶端Client的搜索服務請求后，檢索路由表系統(tǒng)(router)內(nèi)有關(guān)該搜索服務的搜索集群配置信息；

所述搜索服務請求中包含cookie信息、指定的搜索集群、搜索服務名稱，在沒有啟用搜索流量集群分發(fā)策略時，dispatcher將根據(jù)搜索服務請求中的信息決定搜索服務請求轉(zhuǎn)發(fā)至哪一個搜索集群內(nèi)；

步驟6：根據(jù)本次搜索請求中搜索服務在router內(nèi)的集群配置信息，包括搜索服務對應的集群名稱、搜索服務名稱、是否啟用搜索流量集群分發(fā)策略、集群內(nèi)的搜索服務器名稱及地址信息，進而確定dispatcher將client的搜索服務請求轉(zhuǎn)發(fā)具體至哪一個集群和集群內(nèi)的搜索服務應用replica-search server進行搜索服務；

步驟7：搜索服務應用(replica-search server)根據(jù)收到的搜索請求，得到搜索服務結(jié)果，并將該結(jié)果返回給client端。

步驟5搜索客戶端client通過初始化配置可用的搜索請求分發(fā)dispatcher訪問信息，初始化連接第一個可用的搜索請求分發(fā)系統(tǒng)dispatcher后，進入步驟5-1；

步驟5-1：搜索客戶端client成功連接dispatcher后，獲取與該dispatcher相連的Router內(nèi)其他所有dispatcher的信息，并持久化存儲在客戶端本地，作為與dispatcher連接的備用信息；

步驟5-2：client發(fā)送搜索請求給已建立連接的dispatcher，搜索請求中包含用戶的cookie信息、是否指定搜索集群cluster、所請求的搜索服務名稱。搜索請求中的信息被作為dispatcher執(zhí)行路由檢索的參考信息；

步驟5-3：dispatcher收到來自客戶端client的請求信息，并根據(jù)請求信息檢查router內(nèi)是否有請求中的搜索服務的地址信息和已指定的搜索集群，如果上述兩個信息都沒有被找到，拋出異常，通知客戶端client搜索失敗；如果查詢到相關(guān)信息，轉(zhuǎn)步驟4；

步驟5-4：搜索請求分發(fā)系統(tǒng)dispatcher在Router中已查詢到客戶端請求的搜索服務，但若客戶端請求指定的集群信息為空或找不到對應的集群，且發(fā)現(xiàn)同名的搜索服務分布在其他多個集群中，搜索請求分發(fā)系統(tǒng)dispatcher則任意挑選一個集群作為目標集群，將搜索請求發(fā)送至該集群內(nèi)包含該搜索服務的搜索服務應用replica-search server，搜索服務應用成功返回結(jié)果，由搜索請求分發(fā)系統(tǒng)傳給客戶端；

步驟5-5：若在步驟5-4中，由搜索請求分發(fā)系統(tǒng)dispatcher發(fā)送至搜索服務應用replica-search server的搜索請求出錯或者無響應時，dispatcher將繼續(xù)在Router中查找下一個可用的搜索服務應用replica-search server；若繼續(xù)出錯，進而導致嘗試次數(shù)達到設置的最大限制或者超過服務端超時時間設置，則搜索請求分發(fā)系統(tǒng)dispatcher直接拋出搜索異常信息給客戶端client；

步驟5-6：當客戶端收到步驟5-5中拋出的異常時，客戶端client自動在已持久化本地的搜索請求分發(fā)系統(tǒng)dispatcher信息列表中獲取另一個可用dispatcher，并連接；重復步驟2-步驟6，直至dispatcher信息列表中記錄的dispatcher都被嘗試與客戶端連接，若dispatcher還拋出搜索異?；蛘叱^客戶端超時時間設置，則客戶端拋出異常，本次搜索請求失敗；

步驟5-7：若在步驟5-2中，客戶端請求的搜索服務在路由表系統(tǒng)router中被標識為啟用“搜索流量集群分配”策略，dispatcher根據(jù)搜索請求中的用戶cookie信息，經(jīng)計算后，與路由表系統(tǒng)router中已設置的各個集群的權(quán)重值比照，經(jīng)比照一致的搜索集群將被選擇為搜索請求的發(fā)送方，該搜索集群內(nèi)包含該搜索服務的搜索服務應用replica-search server將作為接收本次搜索請求的目標搜索服務應用，搜索服務應用成功返回搜索結(jié)果，由搜索請求分發(fā)系統(tǒng)傳給客戶端；

所述步驟4中還包括客戶端對dispatcher的緩存，具體步驟有：

步驟4-1：客戶端client首次成功連接指定的dispatcher后，將自動從路由表系統(tǒng)(Router)中遠程獲取當前所有可用的dispatcher列表信息，并通過文件存儲Dispatcher信息實現(xiàn)在本地持久化緩存；

步驟4-2：客戶端client擁有Dispatcher列表信息后，當配置的Dispatcher地址不可用，客戶端調(diào)用本地緩存的且已在router中注冊的dispatcher列表，并自動從列表中依次選擇其他dispatcher進行連接，直至連接成功；

步驟4-3：當本地緩存中所有記錄的dispatcher都嘗試連接后，若仍存在連接異常，則搜索客戶端拋出異常，本次搜索請求失??；

步驟6中啟用所述的搜索流量集群分發(fā)策略，具體步驟包括：

步驟6-1：在router存放的路由表信息中會通過一個字段來記錄是否啟用搜索集群流量分發(fā)；步驟6-2：當標示為啟用搜索流量集群分發(fā)時，Dispatcher調(diào)用本次搜索業(yè)務請求，并按照用戶特性進行流量切分；

其中，搜索業(yè)務對應的多個集群的流量占比由人為設定，存儲在路由表系統(tǒng)Router中，所有集群的流量占比總和為100％；

步驟6-3：執(zhí)行搜索流量集群分發(fā)時，依據(jù)client端所發(fā)搜索請求中的用戶特征信息，利用一致性哈希算法計算一個權(quán)重值；

步驟6-4：根據(jù)步驟6-3得到的權(quán)重值，通過對照router中該搜索業(yè)務對應的所有集群的權(quán)重值，確認搜索請求轉(zhuǎn)發(fā)的目的集群cluster；

一種基于路由表的搜索系統(tǒng)集群服務管理的系統(tǒng)，其特征在于，系統(tǒng)包括搜索請求客戶端client、搜索請求分發(fā)系統(tǒng)dispatcher、搜索路由表系統(tǒng)router、搜索服務應用replica-search server；所述四個部分之間都通過網(wǎng)絡進行通信，各自有不同的服務端口，按照一定的規(guī)則匹配一起完成搜索服務；

搜索路由表系統(tǒng)router負責所有搜索服務應用replica-search server的登記注冊及管理，并負責記錄所有搜索服務應用replica-search server的屬性信息及所有搜索服務在各搜索服務應用replica-search server內(nèi)的分布情況；

搜索請求分發(fā)系統(tǒng)dispatcher在搜索客戶端client和搜索服務應用replica-search server之間承擔代理和轉(zhuǎn)發(fā)角色，負責接收搜索請求客戶端client的搜索請求，并根據(jù)搜索路由表系統(tǒng)router中的搜索服務路由信息、以及搜索服務和搜索集群的配置信息，對搜索請求進行不同策略的轉(zhuǎn)發(fā)；

所有搜素服務應用劃分為不同的搜索集群cluster，關(guān)于“每個搜索集群內(nèi)的搜索服務應用的分布”、“每個搜索服務應用包含的搜索服務”等涉及到搜索集群cluster、搜索服務應用及搜索服務三者的對應關(guān)系，均被記錄在搜索路由表系統(tǒng)router中；

所述搜索集群Cluster，是包含若干個replica-search server的集合；

所述搜索服務，是指通過客戶端向搜索服務器發(fā)出針對某個搜索業(yè)務索引的搜索請求，并得到搜索結(jié)果的服務模型。

所述搜索請求客戶端client，是搜索服務調(diào)用請求的發(fā)起人，是搜索服務的直接使用人；客戶端的初始dispatcher的連接地址由手工配置，當搜索客戶端client成功與初始搜索請求分發(fā)系統(tǒng)dispatcher建立通訊關(guān)系，搜索客戶端client將獲取到其他有用的dispatcher地址信息；

客戶端從搜索路由表系統(tǒng)router內(nèi)獲取其他可用的搜索請求分發(fā)系統(tǒng)dispatcher地址信息，并不緩存關(guān)于搜索服務的詳細完整的路由信息；客戶端不需要知道服務端具體的搜索服務節(jié)點的分布情況，只需要知道當前所有可用的搜索服務轉(zhuǎn)發(fā)代理dispatcher；

所述搜索請求分發(fā)系統(tǒng)dispatcher，是路由信息的實際執(zhí)行者，能根據(jù)搜索路由表系統(tǒng)router內(nèi)記錄的集群分布信息及分布策略，執(zhí)行搜索服務請求的轉(zhuǎn)發(fā)和調(diào)度；

所述搜索服務應用replica-search server，是具備自我注冊能力的搜索服務端，它包含搜索服務的索引數(shù)據(jù)，負責完成搜索服務的索引查詢匹配；多個搜索服務應用構(gòu)成搜索集群cluster，搜索服務應用replica-search server的集群通過自注冊加入的方式成立，當?shù)谝粋€replica-search server啟動時，它需要在router內(nèi)配置地址，同時在router中增加一個初始配置信息，并在router配置信息中加入一個唯一標識id號，這個唯一標識id號會被當作一個新的搜索集群id號記錄在搜索路由表系統(tǒng)router中；如果再有其他的搜索服務應用replica-search server想要加入已存在的搜索集群中，以現(xiàn)有的搜索集群id號配置在該搜索服務應用在搜索路由表系統(tǒng)router中；

任意一個replica-search server只能從屬于一個cluster，而任何一個cluster中，都不允許出現(xiàn)同名的replica-search server的集合collection。

所述搜索客戶端client：負責發(fā)送搜索請求，搜索請求中包含搜索客戶端的用戶特征信息，以及本次搜索服務對應的搜索服務信息(collection)；

所述搜索請求分發(fā)系統(tǒng)dispatcher：即搜索路由信息的執(zhí)行者，與搜索客戶端直接通訊；同時負責從搜索路由表模塊router中獲取本次搜索業(yè)務在搜索服務應用內(nèi)分布情況；

所述搜索路由表系統(tǒng)router：用于管理所有處于啟動狀態(tài)的搜索服務應用，記錄各個搜索服務應用的屬性信息，以及每個搜索服務在搜索服務應用內(nèi)的實際分布；同時用于將不同搜索服務應用集成為不同的集群，記錄所有集群的屬性信息及集群內(nèi)的搜索服務應用分布情況；當有新的搜索服務應用啟動時，需要及時在搜索搜索路由表系統(tǒng)router內(nèi)注冊和更新搜索業(yè)務分布信息；

所述搜索服務應用replica-search server:搜索服務應用存放實際的搜索服務的索引信息，若干個搜索服務應用可以組成一個搜索系統(tǒng)集群cluster，每一個搜索服務應用只能從屬于一個集群cluster；

關(guān)于“每個搜索集群內(nèi)的搜索服務應用的分布”、“每個搜索服務應用包含的搜索服務”等涉及到搜索集群cluster、搜索服務應用及搜索服務三者的對應關(guān)系，均被記錄在搜索路由表系統(tǒng)router中；

所述搜索請求分發(fā)系統(tǒng)dispatcher并不具備搜索服務的能力，也不需要大量的計算和存儲能力；本發(fā)明中的搜索請求分發(fā)系統(tǒng)dispatcher能支持高并發(fā)的大量的用戶訪問，能通過增加搜索服務應用replica-search server實現(xiàn)擴展整個搜索系統(tǒng)的服務能力時，而不是增加太多的dispatcher模塊；

所述搜索服務應用集合而成的集群采用自注冊方式組合，當?shù)谝粋€搜索服務應用啟動時，在搜索路由表系統(tǒng)router配置地址信息，同時標識唯一的集群標識ID；當其他搜索服務應用欲加入已有的搜索集群中，以現(xiàn)有的集群標識ID作為該搜索服務應用在router中的地址信息。

本方明與現(xiàn)有技術(shù)相比，其有益效果：

(1)本發(fā)明中的客戶端除了配置的固定dispatcher地址外，還加入客戶端持久化文件，可以自動定期更新服務端的所有的可用搜索服務請求轉(zhuǎn)發(fā)應用(簡稱dispatcher)信息，這樣大大的提高了搜索集群服務系統(tǒng)的可用性，一個或少數(shù)dispatcher的不可用，或是client初始化連接的dispatcher不可用，都不會導致client無法連接搜索服務。

(2)本發(fā)明在client和dispatcher，searcher-server之間加入多級故障重試機制。若dispatcher無法服務，client會依次將所有緩存在client本地可用的多個dispatcher服務依次故障重試。如果searcher-server出現(xiàn)故障，dispatcher會按照router信息，將包含該collection的所有replica-searcher server依次故障重試。這種兩級故障重試機制，確保了在發(fā)生服務器軟硬件故障的條件下，只要有一絲可能，搜索服務就能正常對外使用，提高了用戶的滿意度和平臺整體可靠觀感。

(3)本發(fā)明在router應用中的路由表信息內(nèi)加入collection,replica集群的訪問的策略控制，無需客戶端進行任何修改，即可按照不同的collection，結(jié)合業(yè)務實際需求進行類似AB測試，及流量切分的搜索系統(tǒng)集群服務的管理。尤其對于搜索系統(tǒng)來說，不同搜索規(guī)則在線上并行發(fā)布使用，但對應的是同名的搜索collection的業(yè)務場景，是非常具有使用價值的；當發(fā)生服務器機房升級換代，搜索服務器的硬件維修替換時，能將線上的搜索流量切分到備用的搜索集群上，當原集群完成升級換代及硬件維護后，能立即平滑地完成兩個集群的切換。

(4)本發(fā)明結(jié)合router的路由表，能將原來并不能同時對外一起提供服務的replica-search server組織起來，構(gòu)建成一個虛擬的搜索集群，同時還能支持搜索系統(tǒng)服務管理的數(shù)據(jù)權(quán)限分權(quán)要求，實現(xiàn)在測試版上的搜索服務管理集群和正式應用的集群能進行權(quán)限隔離，大大方便了搜索平臺的日常管理。

附圖說明

圖1為本發(fā)明實施例的系統(tǒng)架構(gòu)圖；

圖2為本發(fā)明實施例的路由表系統(tǒng)結(jié)構(gòu)圖；

圖3為本發(fā)明實施例的基于路由表的搜索系統(tǒng)請求集群服務方法的流程圖；

圖4為本發(fā)明實施例的搜索流量集群分發(fā)方法的流程圖。

具體實施方式

為了使本發(fā)明的目的，技術(shù)方案和優(yōu)點更加清楚，下面結(jié)合附圖和具體實施例對本發(fā)明繼續(xù)詳細描述。

如圖1所示，為本發(fā)明實施例的系統(tǒng)結(jié)構(gòu)。為了描述方便，我們假設整個搜索系統(tǒng)只包含了兩個搜索索引，分別為Collection_1 107,Collection_2,這兩個搜索索引即為搜索系統(tǒng)對外提供的搜索服務，這兩個搜索所分別分布在三個Cluster 105中，每個Cluster中包含了2個Replica-Server 106。搜索Client端的Dispatcher_Route_List 102中存放了服務端3個Dispatcher 103的列表信息。每個Cluster中的的所有Replica-Server 106和包含其中的索引Collection 107的相關(guān)信息都會注冊到Router 104中。Router 104模塊是整個系統(tǒng)架構(gòu)中的核心模塊，它負責管理所有搜索集群的業(yè)務信息。Dispatcher 103則通過和Router 104之間的通訊來獲取和感知搜索集群的業(yè)務狀態(tài)和分布，以將來自Client的搜索請求轉(zhuǎn)發(fā)到對應的Replica Server 106上。

如圖2所示，為本發(fā)明實施例的路由表結(jié)構(gòu)圖。路由表是存放在Router 104中的。它實際分為集群Key 201、2集群流量比202、搜索索引名稱203、是否啟用流量分配開關(guān)204、Replica-Server ID 205、Replica-Server的實際IP和端口206。

圖2中舉例了說明了路由表里的數(shù)據(jù)樣式了，當然為了簡便說明，數(shù)據(jù)樣式做了簡化。Cluster_A 207表示了存放在路由表中一條集群信息，路由表中的數(shù)據(jù)是由集群Key 201和搜索索引名稱203組合成為唯一主鍵，即相同的Cluster中不能有同名搜索索引。路由表中還包含了Replica—Server的具體信息209和210，209表示的是一個集群key和一個索引名稱組成的主鍵可對應多個Replica-Server ID 205和Replica-Server的實際IP和端口206。

圖中208所表示的collection_2表示該業(yè)務對應的集群是具備了流量分配功能，分配的百分比為Cluster_B和Cluster_C各占50％。

如圖3所示，為本發(fā)明實施例的基于路由表系統(tǒng)搜索請求集群服務方法的流程圖，具體包括:

步驟301：Client發(fā)出搜索請求。Client端為整個搜索系統(tǒng)的服務客戶端，負責向服務端發(fā)出搜索服務請求，接收搜索結(jié)果。

步驟302：Client發(fā)出搜索請求時會首先判斷是否已經(jīng)配置了可連接的Dispatcher地址。Client不直接和搜索的實際服務器Replica-Search Server 106發(fā)生關(guān)聯(lián)，所以必須在Client配置可以連接的Dispatcher地址

步驟303：如果沒有配置Dispatcher地址，則Client直接拋出異常，表示無法進行搜索服務連接。搜索請求異常終止。

步驟304：如果已配置Dispatcher地址，則會與該地址進行連接，發(fā)出搜索服務請求，判斷該Dispatcher是否能正常對外服務

步驟305：一旦成功建立連接后，假設該Client是第一次與Dispatcher進行通訊，則會將該Dispatcher所連接的Router上的所有Dispatcher信息全部獲取，并傳回客戶端本地進行持久化，持久化以文件方式存儲。

步驟306：Dispatcher收到Client發(fā)過來的有效搜索查詢請求后，會在Router上進行路由檢索，獲取所有相關(guān)該查詢Collection名稱的所有路由表信息

步驟307：Dispatcher會解析Client發(fā)過來的搜索請求中是否明確指定了需要連接的Cluster信息。如果明確指明了目標Cluster信息，則在該Cluster的所有Replica-Server信息中選擇一個可用的Replica-Server轉(zhuǎn)發(fā)搜索請求。選擇Cluster中的Replica-Server的方法有多種，有按照分配的負荷權(quán)重進行分配，也可以按照查詢請求的條件進行Hash后，選擇將特定Hash數(shù)值的請求轉(zhuǎn)發(fā)給特定的Server。

步驟308：如果沒有指定目標的Cluster信息，則會隨機從當前可用的Cluster中選擇一個(也可以采用的規(guī)則是選擇最新創(chuàng)建的Cluster作為目標Cluster)，然后在該Cluster中按照步驟307的算法選擇一個Replica-Server進行搜索服務請求轉(zhuǎn)發(fā)

步驟309:Replica-Server進行搜索實際查詢服務執(zhí)行，因為搜索應用是一個高CPU和高內(nèi)存消耗的應用，且由于硬件資源的條件限制，搜索應用可能不一定能夠得到需要的搜索結(jié)果，可能出現(xiàn)搜索實例超時或者內(nèi)存溢出等異常情況

步驟310：如果出現(xiàn)搜索得到結(jié)果失敗的情況，則表示當前所執(zhí)行搜索服務請求的Replica-Server出現(xiàn)故障，需要更換Cluster中的其他可用Replica進行重試

步驟311：如果所有當前Cluster下的Replica都嘗試過出現(xiàn)無法服務的故障，則Dispatcher會將異常信息拋出給客戶端Client,Client會放棄當前的Dispatcher，切換到本地所緩存的其他Dispatcher地址，進行重新搜索服務請求。重復步驟304-310

步驟312：如果replica執(zhí)行成功，得到搜索請求的結(jié)果，則返回給client，表示一個完正的搜索請求服務流程完畢。

如圖4所示，為本發(fā)明實施例的搜索流量集群分發(fā)方法的流程圖，具體包括

步驟401：類似圖3所描述的搜索請求服務流程的起點，Client發(fā)出搜索服務請求。

步驟402：類似圖3部分的流程此處進行簡化，不做具體描述。當Dispatcher收到Client發(fā)出的搜索請求后，會檢索Router上的相關(guān)路由管理信息，當判斷發(fā)現(xiàn)如果該次搜索請求需要進行流量集群分發(fā)，即將調(diào)用同一個搜索業(yè)務的請求按照用戶特性進行流量切分，切分的相關(guān)百分比配置已經(jīng)在Router的路由表信息中進行了約定。

步驟403：計算Client傳入的搜索服務請求中包含的用戶特征信息，一般來說，采用的用戶端Cookie信息中包含的UUID組成的一個數(shù)值型字串。

步驟404：針對用戶的特征值然后進行取模計算，再結(jié)合一致性哈希的算法，進行不同的比例的權(quán)重計算，最后得出該次用戶的搜索請求服務應該分配的目標對應Cluster結(jié)果。

步驟405：在對應的Cluster包含的Replica中選擇一個Replica作為本次搜索請求服務的執(zhí)行方。選擇的算法類似于圖3中的步驟307

步驟406：搜索服務端得到搜索結(jié)果，返回給Dispatcher，再傳遞給Client結(jié)果。如果出現(xiàn)搜索異常，則拋出異常給Client。此處重試的機制在圖3的步驟中已經(jīng)做過描述，此處不再贅述。

本發(fā)明還可有其他多種實施方式，在不違背離本發(fā)明精神及其實質(zhì)的情況下，熟悉本領域的技術(shù)人員可根據(jù)本發(fā)明做出相應的改變和變形，這些改變和變形都應屬于本發(fā)明所附的權(quán)利要求的保護范圍。