solr 搜索架構優化
剛剛將solrt升級到最新版本3.6.1，除了精簡了索引結構設計，新版本的天生優勢更加重要，比之前solr1.4的性能算是小部分提升，響應由100ms以內佔80%升到了90%，且搜索系統穩定性好了很多，出現掛掉的機率降低了，當然還得繼續觀察。同時優化了舊的搜索系統架構 ，加上系統的配置優化管理，方便修改調整，對外提供的接口重新設計了一翻，加入了一些請求的跟蹤，方便接口升級時能找到對應的前端請求位置，對症下藥。同時對後面的架構優化打下很好的基礎 .
將現在架構大小索引方式，一個大索引有幾千萬數據 ，小索引幾萬數據，還有另一個結點有三百萬左右數據，現在每天有900萬左右的請求量，已經可以達到90%以上在100ms以下響應。但還是有少許的搜索可能達到了兩秒以上，還有一個就是現在索引是放在共享內存裏，如果那天這兩臺神機沒有了話就比較麻煩，這次的升級就是一個經驗，說明我們更希望在某些情況能使用更普通的機器就能完成，特別是在機器比較不允許的條件下， 這樣的架構的存活纔有可能 .
所以纔開始有想過測試將大索引切分爲多個核來使用，因爲搜索默認排序是由多維度動態計算的值來排序，所以，特別是在命中特別多文檔的時候，計算耗時比較大，比如搜索高頻詞的時候。所以切爲多個核，可以將這些計算分到其它機器，大索引分拆爲小索引，倒排表索引數據 也變小，輕量級了，搜索命中這個環節也會提升，動態計算的這個，由於分擔到多個機器並行計算，這兩者的提升對於整體性能來說很重要。
當然這個也是有代價的，要犧牲一定的網絡帶寬以及http連接數，以前三個結點，對於每次的請求就變成了2*3+1=7個請求，現在分了差不多要10個結點，那麼一個請求就變爲了2*10+1=21個請求，還好這些請求是併發進行的，所以只取兩個階段請求最耗時再加結果合併消耗的時間 .所以這樣的設計理論上應該是可以提高性能的，當然再怎麼優化都需要經過實踐才能證實，所以爲了更好了做壓力測試，引用了tcpcopy這個工具，引流線上的真實用戶請求模擬測試對比。
暫時只需要測試大索引切分的幾個結點的耗時，使用4臺8核8g的機器作測試：（8個核 ，每個核大概是1G多索引數據，所以每臺機器放兩個核）
將索引數據全放在內存裏，測試性能 響應特快，比現在的架構快了幾倍
然後再把其中一臺機器索引放到了硬盤，使用MMapDirectory方式，作對比後，效果也不錯，性能沒減。
現在全部使用MMapDirectory，看看效果是不是一樣，如果這種方式可行的話，比完全放內存的方式維護方面更佳。測試效果也不錯
整體性能可以估計提升了3倍左右，單測試高頻詞，更不只3倍，即使命中文檔在1千萬左右，也能在一秒左右響應，當然現實搜索這種情況會比較少，測試搜索長詞的時候大多也是在100-200ms,當然實際中用戶搜索串都是在7個字以內，響應都能保持在100ms以內，並且cpu的負載也不會太高。
測試10萬請求只有1%的響應高於100ms。
當然現在變多個核，管理方面的優化也是要的，方便升級與調整，還有分多結點的時候，索引應該如何切分也是個要解決的問題。。
現在只是確認方案可行性。
可以測試搜索效果：http://so.56.com/all/%E6%A2%A6%E6%83%B3%E7%A7%80/
請多多提意見
轉載請聲明：http://blog.csdn.net/duck_genuine/article/details/8113482
