鬱金香搜索引擎的方案

　　先介紹學心理學的時候記住的兩個把妹祕籍:

　　1>巴甫洛夫把妹法:巴甫洛夫的狗的反射試驗上學的時候你們都應該學過，每天給狗餵食的時候搖鈴，後來不餵食只搖鈴狗仍是分泌唾液。應用到把妹這個很是有實際意義的事情上面就是：天天給妹子送早晨，等人家造成了習慣，忽然不送了，人家就開始以爲不自在了，開始各類想這個男孩紙~~

　　2>吊橋效應:在吊橋上，因爲危險的情境，人們會不自覺地心跳加快，錯把由這種情境引發的心跳加快理解爲對方使本身心動，才產生的生理反應，故而對對方滋生出愛情的情愫。

　　心理學是門很實用的學問吧[偷笑][偷笑]。

昨天開會討論我本身的搜索引擎的事情，我說我這個都計劃了好幾年了，老大說：「那我不讓曉靜作，她還不得殺了我~~」 要不是開會，我會很負責任的跟他說：「不會那麼慘啦，可是每次見你都朝你吐舌頭是免不了的~~」。因而今年個人核心任務就這麼定下來了。

 

 

 　　我開始的時候提出：將搜索引擎的索引所有設置內存索引，不持久化存儲，這樣速度會快。由於是一個集羣，因此發版能夠定時一臺一臺的重啓服務。由於重啓後會重建索引，須要大概10分鐘。集羣直接採用nginx作負載均衡，服務之間不作強數據一致，而是每一個服務獨立的從數據庫中沒100ms按照更新時間查找當前1m內的更新數據。更新數據首先存入java的Set，設置兩個Set。Set內的數據按ID作爲key，一個Set存儲當前1s內已經更新到索引中的數據，一條存儲沒有更新到索引的數據。對於已經更新到索引的數據，當新的數據和已經更新的數據對比，不一致則更新，不然不處理。對於未更新到索引的數據，直接覆蓋舊數據。之因此這麼作是由於mysql數據庫的更新時間都是秒級的，我用毫秒級的間隔，會屢次重建索引。

　　服務之間的一致性按照存儲的ID和更新時間定時對比，也能夠手動對比來保證。

　　對於現有的通知服務，由於業務方更新了原本會發消息通知咱們更新緩存，更新了緩存再返回更細成功的消息給業務方。我說非要保留這個的話，我拿到通知更新的，我就直接返回，由於個人更新是ms秒級的，確定比收消息再發消息這個通訊過程快。

　　我提出了現有服務的問題：維護成本高，部署複雜，結構複雜，還有一些499的超時，個人搜索引擎均可以解決。由於個人內存支持全量索引數據和查詢結果的緩存，因此接口直接調用，本身基本什麼都不須要作。

　　好了，上面的均可以不看，由於被咱們的技術大牛們批的體無完膚。下面是他們給出的考慮和建議：

　　首先，我最怕的問題，作與不作的問題。

我說我們的業務其實特別簡單，都是查，只要求高可用，高併發，這種場景自己就特別合適搜索引擎。你們反饋說：你這個佔內存太大，線上的通常機器內存也就30G。這個樣子啊，我土豪慣了，一直認爲線上別人也都是用24核128G高配物理機。而後，萬一所有宕機，重啓過程當中有10分鐘服務不可用。我原本是想有聯通和電信，這種概率很小，因此服務宕機重啓過程當中直接查數據，緩存結果也能扛得住。好吧，也是我考慮不周，我說那就作可持久化的。內存不夠和啓動問題全能解決，lucene原本就支持，只是能夠根據宕機概率，減小寫的頻率來提升效率。給業務線回消息，由於個人索引更新有兩部分的時間：一部分是讀從數據庫有從數據庫和主數據庫的同步時間和索引更新時間兩部分組成，不必定比消息要快。我說那就按消息被nginx轉發的搜索引擎節點查一次，更新了就回OK的消息。你們反饋說：由於集羣之間不是實時通訊，因此強一致性也不能保證，因此回的消息不可靠。我說那我大不了採用現有的ES搜索引擎的或者SolrCloud的集羣技術來作集羣之間的強一致，確定是能解決的。你們說：那你的優點在哪裏啊，幹嗎不直接用ES？(好刻薄，好尖銳[恐怖][恐怖]，可是作技術的，你們都知道，也都習慣了，爭論纔有提升，特別是對於我們程序員)。我說你們也應該都看到了，我擅長函數，擅長算法，在內部我有不少能夠優化的地方，而後大家還沒好好看個人博客，我都寫了的[委屈][委屈]。

到時候會支持兩種調用模式，一種是RMI調用，一種是RPC調用。目前的SOA基本都在用通用性更強的RPC調用，如:dubbo,thrift, 還有市面上的搜索引擎。實際上RMI更快，對於咱們內部使用，RMI更合適。在Java中，只要一個類extends了java.rmi.Remote接口，便可成爲存在於服務器端的遠程對象，供客戶端訪問並提供必定的服務。不過不管RMI仍是RPC，都是下面這種簡單的架構：

 

 

　　陽哥說回到最初的問題，由於業務簡單，那徹底能夠用Lua來寫啊。被批了十幾分鍾，個人大小姐脾氣忽然就來了"那大家誰會Lua，讓他寫一個"。仍是陽哥機靈，話鋒忽然一轉，讓我馬上感受到不是不讓作的意思。而後陽哥就說人家也確實就是會Lua。我說確實是什麼均可以實現，可是陽哥您擅長Lua那您就會採用Lua的方式來解決，我擅長搜索引擎，那我就會採用搜索引擎來解決。陽哥就說本身在阿里的時候人家直接用數據庫就雙十一就扛住了高併發。好了，空氣的緊張氛圍緩和下來了。

 　　我說話也確實說不清楚，脾氣還容易急。最後仍是男神老大出馬[撒花][撒花]。老大說：「首先這個定位問題，咱們是要作一個通用的搜索引擎的中間件，不是特定爲接口服務而寫的，可是作好了接口服務能夠用。其餘的服務也能夠接，目前的ES搜索引擎也能夠被代替。」不對，不對，記得男神哥哥當時說的可好聽了，可是隻顧着仰望了，具體啥全忘了。而後我要爭取其餘人的支持："陽哥您看您有您本身的平臺，磊哥您有本身的日誌收集系統，大家都說本身有什麼優點，可是咱們也沒聽很明白，可是大家本身知道。我要作本身的中間件也是同樣。" 其實我都沒有必要這麼擔憂不讓作的問題，由於咱們部門是一個很開明，很能容納新思想，很願意接受改變的部門，誰有什麼想法，都按本身的想法去作了。最壞的結果也就是失敗了，沒啥大不了的。可是個人語言功力確實欠練。我家男票是個很沉默是金的人，他媽都以爲他太悶了。由於他說話少，在爺爺奶奶那邊，他也比別的孫子孫女更吃虧。可是跟我他是無話不談的，我都睡着了，他還說個沒完~~由於我有絕招啊，首先一個不是很熟的人，聊天的話先聊什麼呢，小時候啊。他也可能沒看過我看過的書，我看過的電影，沒有我有的東西……可是他必定有小時候，通常人提到小時候話匣子一會兒就打開了。而後聽到關於他本身的越多，聊得也就越多了。可是，要說聊正事，差的真遠。

　　接下來就是怎麼作的問題。

陽哥說你這個集羣最好用分片的索引數據，這樣才能發揮集羣的優點。我說這真是個好主意，也是很好實現的，採用集中式緩存的算法便可。如今ES就是採用的memcached協議的，原理和moxi同樣。經過memecached協議來訪問ES的接口,支持二進制和文本兩種協議.經過一個名爲transport-memcached插件提供。磊哥和德偉說我應該去研究一下ES和Solr，吸收其精華，好中肯。德偉還提到我用的直接按100ms去數據庫拉取數據，能夠用訂閱更新來作（https://github.com/alibaba/canal）還給我推薦了這個實現。由於搜索引擎原本就是一個文檔型的nosql數據庫，那麼未來能夠不但支持多種外接數據庫等數據錄入方式，還能夠提供默認本身就是數據庫，去掉數據庫環節的服務。你們還提議作成插件形式的。

　　你們提出這個可以帶來的一個很大的好處就是目前咱們作的分庫分表，採用搜索引擎的話，接口服務就不會受到影響。老大還提出：這個比較合適列表，和查詢條件複雜的搜索，可是對於單個ID的搜索是否是仍是走數據庫更合適。這個須要等服務作出來以後測試來定。我我的傾向於都走搜索，由於保持一致，維護容易。我看過solrcloud的集羣策略，集羣之間的複製確實要比每一個服務直接和數據庫打交道出錯率要高，因此我能夠試着結合數據庫直接數據交互，分片，加上高效的容錯來作數據的一致性保證。會上忘了說搜索引擎的目前的搜索模型不合適媒資這樣大多根據ID來查詢的問題，到時候須要好好考慮。

對於這個搜索中間件，你們都提了不少。我就說開發就一我的就好，大家就負責提意見。你們說：都規劃好了，編碼是很簡單的，未來你也能夠招一些人幫你編碼。太nice了，怕我累着~~對了，最後是項目的名字問題。我本身的域名是brmayi。br是換行符，那麼個人域名就解釋爲<換行螞蟻>吧，發現和螞蟻沾點邊很容易火[偷笑][偷笑]。我喜歡花，因此本身作的東西都以花的名字來命名。週末植物園滿園的鬱金香特別好看，這個項目就叫<鬱金香>了，英文是tulip，隨手畫的，等五一放假好好設計下logo[偷笑][偷笑]

 

 如需轉載，請註上個人原文連接：http://www.cnblogs.com/xiexj/p/6782350.html  謝謝哦~~