背景：單執行緒為30萬條資料建索引花了10分鐘，為了提高效率採用多執行緒
起初我採用多個執行緒共享乙個indexwriter例項（也意味著往同乙個目錄寫索引），這是
lucene in action 和lucene wiki的推薦做法，不知道到為什麼總是報filenotfoundexception，
很讓人困惑。偶爾會成功一次。這個錯誤讓我想起另外乙個問題，就是在建索引的時候搜尋也會報這個
錯誤，lucene in action 明明也說了建索引讀的時候沒問題。
言歸正傳，我第二次嘗試使用每個執行緒單獨擁有自己的indexwriter例項，但往同乙個目錄寫索引，果然報了
寫鎖的錯， 這和書上說的很一致。
最後沒辦法了，我使用每個執行緒單獨使用自己的例項，往自己的目錄寫索引，最後乙個幹完的執行緒將所有的索引合併
比如我開了4個執行緒，那麼就有5個目錄build_index,build_index1,build_index2,build_index3,build_index4
執行緒1往build_index1中寫，執行緒2往build_index2，。。。依次類推，最後乙個幹完的將build_index1-4目錄的索引合併到
build_index.
我開了4個執行緒嘗試發現也要花大概7-8分鐘，合併索引的過程非常快20秒左右。
開了10個執行緒，整個過程需要6分多鐘，合併索引也只花了21秒。
似乎效果並不明顯,這因該是因為資料量還不夠大引起的,資料量越大,並行的優勢會越明顯
可見合併索引的過程非常快，這又提供了另外的好處，我們通常將build_index作為搜尋目錄，就像上面說的那樣，建索引的過程會影響搜尋（雖然按照書上說是不影響的），如果我們採用這種方案，建索引的絕大部分過程其實與build_index目錄無關，只有最後合併的時候需要用到build_index，但那個過程又非常的快速，所以可以極大的緩解建索引給搜尋帶來的問題。
順便說：當然你也可以再開乙個通知執行緒專門等待索引執行緒，當索引執行緒完畢之後加入通知執行緒的佇列，通知執行緒發現自己的佇列有通知記錄就開始合併索引，這樣就不用所有的執行緒完畢之後才開始合併索引。（這種方案待嘗試）
如果條件允許，你可以擴充套件一下這個方案，將多執行緒索引公升級為多台機器同時建。
lucene並行建索引解決方案
背景 單執行緒為30萬條資料建索引花了10分鐘，為了提高效率採用多執行緒 起初我採用多個執行緒共享乙個indexwriter例項 也意味著往同乙個目錄寫索引 這是luceneinaction和lucenewiki的推薦做法，不知道到為什麼總是報filenotfoundexception，很讓人困惑。...
lucene並行建索引解決方案
寫，執行緒2往build index2，依次類推，最後乙個幹完的將build index1 4目錄的索引合併到 build index.我開了4個執行緒嘗試發現也要花大概7 8分鐘，合併索引的過程非常快20秒左右。開了10個執行緒，整個過程需要6分多鐘，合併索引也只花了21秒。似乎效果並不明顯,這因...
多版本（ 30）並行控制的解決方案
之前也寫了和轉了一些解決方案，發現並沒有乙個能完全符合自己需求的方式，於是在現有的方案中取各家精華，盡量規避各種坑，形成了現在的管理模式，可以看做 是 fork 機制的另一種實現方式。fork 是同乙個賬戶只能 對同乙個專案 fork 一次，無法滿足我的要求 單版本庫多分支簡直滅絕人性，分支數量多到...