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