將現在架構大小索引方式，乙個大索引有幾千萬資料 ，小索引幾萬資料，還有另乙個結點有三百萬左右資料，現在每天有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。
當然現在變多個核，管理方面的優化也是要的，方便公升級與調整，還有分多結點的時候，索引應該如何切分也是個要解決的問題。。
現在只是確認方案可行性。
可以測試搜尋效果：
請多多提意見
solr搜尋分詞優化
solr搜尋分詞優化 solr伺服器配置好在搜尋時經常會搜出無關內容，把不該分的詞給分了，導致客戶找不到自己需要的內容，那麼我們就從配置詞典入手解決這個問題。首先需要知道自帶的詞典含義 停止詞 停止詞是無功能意義的詞，比如is a are 的 得 我 等，這些詞會在句子中多次出現卻無意義，所以在分詞...
Solr集群的架構
架構圖最近要搭乙個solr集群，我們先來了解一下架構。架構搭建需要用到solr zookeeper。看以下結構 要完成的集群結構如下圖 我們來了解一下solr和zookeeper。solr zookeeper 在此架構中，zookeeper扮演了三個功能，分別是集群管理，配置檔案的集中管理和分布式鎖...
Solr 分詞與搜尋
name ik cnanalyzer class solr.textfield positionincrementgap 100 type index class org.wltea.analyzer.lucene.iktokenize ctory usesmart false analyzer t...