先介紹學心理學的時候記住的兩個把妹秘籍:
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 謝謝哦~~