在想自己和剛畢業的時候處理問題有什么不同。剛畢業的時候如果想卸載停用什么東西提示說正在使用，我就去找個強力卸載軟件。如果我想清理瀏覽器緩存，會直接用工具，如果想找到緩存路徑選擇性的清理，會百度一下這個瀏覽器的默認緩存路徑在哪里。現在，我會打開資源監視器查看磁盤活動，對文件，找到使用文件的進程；對應用，找到它在讀寫的文件路徑。
現在接口服務組的性能卡在memcahe緩存上。對於緩存的過渡依賴，而且為了維護這個緩存數據，業務流程的復雜性大大提高。其實本身接口這塊業務流程是很簡單的，只是要求承擔很大的並發量。要高並發，業務就更得簡單。nginx服務單台機器號稱能承載10億的並發，為啥？邏輯簡單啊，就是按照規則找到對應的處理服務，將請求轉發過去。
前段時間接了個私活。話說這一年多的時間還真干了不少事情，干過私活創過業的。業務就是創建一個帶支付的途家+攜程。剛拿到活兒，因為是php的，我又不會php，愁死了。因為是男票幫忙接的活兒。我就說是男票把我給賣了。確實是，他接活兒，但是自己看都不看一眼，只負責拿錢。我自己啥都沒有，還怕做不好壞了男票的名聲。本來人家預算是2w的，我說這個得5w。最后給了3w。1個月時間確實是搞定了。總結一下，這個從UI設計到編碼測試只有我一個人的項目，就前端JS樣式這一樣，別人也很難做的很快。我之所以能做的很快，綜合能力是一方面，最重要的原因是：業務邏輯理的順，包括支付，結算，后台給商家打款，統計分析。業務邏輯划分的清楚，做起來工作量就沒有那么大。話說男票給我接私活這事兒，我嘴里是埋怨的，心里很清楚：他之所以給我接這個活兒是因為我想做。他並不是為了錢，是真心知道我想要什么。而我嘴上的埋怨也只是因為一時的辛苦發泄一下而已。這埋怨也是笑着埋怨的，誰也沒當回事情。在日本的時候看過一個日文版的韓國水木連續劇<黃真伊>，真伊有兩個愛她超過愛自己的母親。她的生母和老師。生母拼其一生想讓真伊得到愛，老師拼其一生想讓真伊得到痛。因為痛是才藝的源泉。恩浩注定不能和真伊在一起，因為他的軟弱。愛一個不對的人，心就像是浮萍，漂泊探索一無所獲。看破看不破，終究是寂寞。真伊與正翰的愛感化了所有人，而真伊終究也沒與正翰白首不相離。而愛一個對的人，他們的經歷是別人所不能比的，他們最終心里都是踏實的。真伊為才藝而生，正翰為天下而活。這才是他們的平靜與歸宿。不像真伊那般有才，也不像真伊那般命苦。過着幸福的小生活，做着自己想做的事，吾復何求。
又想到離線數據那個小項目，在想之前跑全量只是取ID都要跑四個小時，我寫的程序只要20多分鍾，為啥呢，最重要的原因也是划分的清楚。人家問我這個項目用到了哪些線程之間共享資源的地方，我說：這里面有個AtomicInteger作為線程計數器算不算，我需要計算是不是所有的線程都是正常跑完終止的。其他的共享資源我都放到一個類里面了，但是Map我就是用的HashMap，也沒用到ConcurrentHashMap，話說咱也是知道並發包里的各種並發容器的原理的。但是業務邏輯划分清楚了，我能保證寫HashMap的時候，只有一個線程在訪問，我沒有必要非要用並發啊。所有的線程最終要生成全量文件，我用幾百個線程，每個線程生成一個文件，各自讀寫打包壓縮，各不干擾，當然要比給文件加鎖，等待寫操作快得多。話說這個技巧也已經被用的很多了，lucene的添加索引就是這么干的。
上周開會的時候，我突然想到(其實之前早就想到了，但是每次說都沒人搭理，就過去了)，媒資接口高並發的地方都是根據各種條件取數據，其他的程序都是為了維護這份數據服務的，維護數據很復雜。除了接業務線的消息，還有自己的數據庫和緩存對比補數據的。將來，因為聯通和電信要做物理隔離，隔離后還需要一個寫緩存的統一監控專門負責給業務線返回更新消息，數據補償的。然而所有的這些復雜邏輯，一個搜索引擎全能搞定。
之所以我之前提議沒人搭理，分析其原因：我們目前的組內搜索引擎做的不好，大家只會用最簡單的功能。而我並沒向大家完整介紹過搜索引擎都能干什么，而且我自己什么都沒有做。陽哥自己搭建了一套redis來做日志的統一收集，我受到啟發。現在，我有服務器，熟悉java底層和算法，搭建一套適合中國人用的搜索引擎又是我一直以來的心願，現在又有業務場景需要用，干嘛不自己做一套。之前離開人人之后看過王志亮寫的庖丁jade的源碼，覺得自己也是可以做這么一套框架的，況且只是一個持久層框架，原理非常清晰明了。果然，來到樂視看到了和庖丁jade非常像的mango框架。如果現在我不研發這么一套專門應用場景的，適合中文分詞的，非常合適作為列表緩存的搜索引擎框架出來，過兩年肯定會有人比我先發布的，因為確實是很有應用場景的。
先說為什么接口服務要用搜索引擎。搜索引擎可以支持高並發，之前用過基於lucene的solr搜索引擎，可以支持單台上萬的並發。它是有多少內存就可以吃掉多少內存的，將集中式緩存的以空間換時間用到了極致。接口服務只更新緩存，不更新DB。如果換做搜索引擎，搜索引擎每分鍾從數據庫的從庫中讀取數據，對數據庫基本沒壓力。業務線給我們發消息，我更新完緩存再返回消息也需要好幾分鍾。用搜索引擎實時性會更高。業務邏輯簡單，現在接口服務用到了龐大的SOA架構，邏輯復雜，響應時間長。用搜索引擎，只需要一個接口服務調用搜索引擎搞定所有事情。搜索引擎內的數據高度結構化，可以添加復雜的條件，函數，分組，排序，實際上也是在JVM內完成的，直接和內存中數據交互。速度快太多了。接口服務目前的瓶頸在緩存上(必須在緩存上啊，整個都在和緩存打交道)，經常性的緩存返回數據時間長。多個鍵值的時候mget性能差，還很容易堵塞，影響到整個服務。目前能采用的措施就是將一部分任務轉給DB，另外考慮將memcache換成Redis緩存。不管是memcache還是redis，都不合適這種動輒就100K以上的大數據的情況。鍵值對的緩存最佳應用場景都應該是key和value體積都是極小的。所以我們現在的嘗試其實都不解決本質問題。用的dubbo做的RPC調用也有問題，dubbo有自己的bug，一旦遇到就很頭大。增加這層dubbo，增加了通訊開銷和系統復雜性，實際性的好處卻沒得到發揮。而搜索引擎本身就是為大數據而生，大數據量，大數據體，高並發，而且對於這種多維查詢，是搜索引擎最合適的用武之地。搜索引擎也可以單獨作為RPC的被調用方，直接給其他業務線用。我們甚至可以將接口服務接收請求接口層都去掉，接口服務只有一個搜索引擎。德偉最頭疼的部署問題迎刃而解。
最最重要的原因，搜索引擎是基於全文索引的，目前的搜索模型純波爾模型，向量空間模型，概率模型都是不適合像媒資這種主要是ID列表查詢的。相應的，搜索引擎的分析工具的側重面也是不合適媒資這樣的業務場景的。
來看接口服務目前的架構：
很復雜且不合理，需要很多的優化。其中還用到了Falcon監控平台和美團點評的CAT監控。數據庫更新目前要通知ES搜索引擎，通知緩存，通知業務線。
換用搜索引擎之后的架構：
就是這么簡單，要不是為了保持目前的對外接口不變，接口api都可以不要。
搜索引擎自己集成日志，監控。想要調試也只要輸入參數，內部處理過程可以一目了然。從實現上，包裝lucene做一個平台即可。較其他搜索引擎優化的點：着重提高根據ID維度作為查詢條件的有序輸出，將接口的常用操作函數化，使其適合作為接口服務。將solr中不合適中文分詞的詞根化等環節去掉，加強中文特有的拼音，近義詞的搜索(等后續有時間時優化)。集成jvm，內存，cpu的日志，監控和報警，部署方便。初始不需要做太多，以后根據業務場景需要慢慢優化。其實我是要嘗試使用自己的算法的，自認才疏學淺，沒好意思說。
如需轉載，請注上我的原文鏈接： http://www.cnblogs.com/xiexj/p/6761570.html 謝謝哦~~