先介紹一下工具吧：
Sphinx ：Sphinx是一個基于SQL的全文檢索引擎，可以結(jié)合MySQL,PostgreSQL做全文搜索，它可以提供比數(shù)據(jù)庫本身更專業(yè)的搜索功能，使得應(yīng)用程序更容易實現(xiàn)專業(yè)化的全文檢索。Sphinx特別為一些腳本語言設(shè)計搜索API接口，如PHP,Python,Perl,Ruby等，同時為MySQL也設(shè)計了一個存儲引擎插件。
下載方式：http://www.sphinxsearch.com/
基于sphinx的coreseek：http://www.coreseek.cn/
中文分詞工具：LibMMSeg：http://www.coreseek.cn/opensource/mmseg/
tokyocabinet：在我第一篇博客有詳細介紹。
mysql：大家都熟悉的開源數(shù)據(jù)庫。
這個輕量級框架，保守估計，可以支持5線程同時并發(fā)搜索，根據(jù)我自己測試的結(jié)果，tokyocabinet(下稱tc )FIFO隊列返回10w條數(shù)據(jù)，只需要10ms，100w條數(shù)據(jù)要100ms左右。tc的key-value方式緩存，保守估計，100w條數(shù)據(jù)100ms沒問題。
介紹一下流程主要部分吧（看圖流程，比較像張宴的“億萬級搜索框架”，老實說當(dāng)時我看過，只是表面了解一下 | 恕我冒犯，大師級的東東我不是很懂，圖片漂亮，但是內(nèi)部實現(xiàn)，根本是比較模糊的，算是一半原創(chuàng)吧，哈哈）。
1、程序入口會判斷用戶輸入的關(guān)鍵字是否有關(guān)鍵字緩存，如果不存在，就會調(diào)用sphinx對mysql數(shù)據(jù)庫進行全文檢索。
然后sphinx會吧搜索索引的文檔id結(jié)果緩存到tc。
我故意把數(shù)據(jù)庫的文本結(jié)果緩存到FiFo隊列。因為sphinx是不會做文本索引的，所以它返回的知識搜索索引的文檔id，也就是數(shù)據(jù)庫主鍵id（或用戶自定義ID），程序必須要吧結(jié)果id放到數(shù)據(jù)庫搜索，吧文本結(jié)果取出來。雖然mysql根據(jù)id返回搜索結(jié)果的速度很快，（如果單用int類型id以遞增方式查詢mysql數(shù)據(jù)庫，每秒可處理1000w數(shù)據(jù)）。但實際不會這么用。所以文本結(jié)果緩存就顯得格外重要了。
最后通過FIFO隊列，把相同關(guān)鍵字的搜索結(jié)果返回到頁面現(xiàn)實。
2、當(dāng)然，如何關(guān)鍵字緩存存在，就會直接從FIFO隊列返回搜索結(jié)果。
我的想法：
因為知道sphinx的缺陷，所以想盡辦法彌補，一個基于mysql的全文檢索工具，速度之快，很是讓人佩服。
問題總結(jié)：
1、簡單統(tǒng)計： 用了tc緩存，其實有很大一部分原因是用來做統(tǒng)計。很多搜索引擎，都是用mencache，但是mencache是建立在內(nèi)存上面的，不釋放的話，資源消耗頗大。而tc就不一樣，它是寫入文本的，緩存數(shù)據(jù)得以保存。在做簡單統(tǒng)計的時候，比如說：
統(tǒng)計"java" 跟"C語言"的用戶搜索情況，我可以從tc中讀出關(guān)鍵詞緩存，知道搜索密度情況。
2、完成復(fù)雜統(tǒng)計： 復(fù)雜統(tǒng)計的話，必須要定義好，復(fù)雜的sql語句，要用到left join這樣那樣的函數(shù)，配置比較麻煩。但問題依然可以解決。（說是這么說，但是具體怎么做頭緒還差一丁點~~牽扯到多表查詢，性能如何還是要嘗試嘗試~）
希望看過文章的可以給點意見，我努力完善，獻丑啦~~
文章來源:http://henry2009.javaeye.com/blog/465834(我的舊博客)