莊周夢蝶

    最近因為空閑時間有一些，所以去看了不少開源項目，大部分東西如果看過不記錄下來，其實還是相當于沒看，所以想想還是有必要摘要記錄一下。

    首先是去了解了zookeeper這個項目，基于paxos算法的分布式服務組件，同事對此有非常深入的研究和介紹，具體可以看我們的團隊Blog。令我感慨的是這么一個非常難以理解的算法，卻用一個簡單的樹狀目錄模型表達出來，并且在這個模型的基礎(chǔ)上衍生出種種應用：集群感知、分布式鎖、分布式隊列、分布式并發(fā)原語等等，具體可以看文檔給出的recipes。在實現(xiàn)這些應用的時候，突出強調(diào)的是避免網(wǎng)絡風暴，例如分布式鎖的實現(xiàn)，競爭創(chuàng)建子節(jié)點，節(jié)點序列號最小的獲取鎖，其他節(jié)點等待，但是等待在什么條件上是有講究的，如果所有節(jié)點都等待最小節(jié)點的刪除事件，那么當最小節(jié)點釋放鎖的時候，就需要廣播消息給所有其他等待的節(jié)點；換一個思路，如果每個等待節(jié)點只是等待比它序列號小的節(jié)點上，那么就可以避免這種廣播風暴，變成一個順序喚醒的過程。因此盡管有了zookeeper幫助實現(xiàn)分布式這些服務，但是要實現(xiàn)好仍然有一定難度，具體可以參考官方例子。我本來萌生了基于zookeeper實現(xiàn)一套封裝好的類似j.u.c的服務框架，后來在郵件列表發(fā)現(xiàn)已經(jīng)有人搞了這么一個基礎(chǔ)類庫放在github上:https://github.com/openUtility/menagerie 。不過我沒有繼續(xù)深入了，有興趣的朋友可以瞧瞧。

    然后又去看了我們淘寶開源的TimeTunnel。TimeTunnel你可以理解成一個消息中間件，它整個設計跟我們的產(chǎn)品相當接近，但是兩者的目的完全不同，tt強調(diào)的是高吞吐量，而notify強調(diào)的則是可靠性。TT的通訊層直接采用Facebook的thrift，并且利用zookeeper做集群管理和路由。TT的代碼質(zhì)量很好，有興趣可以拉出來看一下，并且對zookeeper的應用也是一個典型的案例。TT在高可用性上的方案也很有特色，所有的服務器節(jié)點形成一個環(huán)，兩兩相互主輔備份，一個節(jié)點掛了，后續(xù)節(jié)點仍然可以提供服務直到主節(jié)點回來，有點類似一致性哈希的概念。節(jié)點的主從關(guān)系和順序也是通過zookeeper保證。消息順序的實現(xiàn)是通過稱為router的路由到固定節(jié)點做傳輸，router默認是策略不是固定而是RR。TT的數(shù)據(jù)存儲優(yōu)先放在內(nèi)存，并設置了一個內(nèi)存狀況監(jiān)視的組件，當發(fā)現(xiàn)內(nèi)存放不下的時候，swap到磁盤文件緩存，實現(xiàn)類似內(nèi)存換頁的功能。正常情況數(shù)據(jù)都應該在內(nèi)存，當然如果可靠級別要求高的話可以先存磁盤再傳輸。TT目前仍然還是比較適合傳輸日志這樣的文本增量數(shù)據(jù)，并且提供了TailFile這樣的python腳本幫你做這個事情，這個腳本可以通過checkpoint做斷點續(xù)傳。在學習這個項目的時候，發(fā)現(xiàn)文檔有很大問題，要么錯誤，要么遺漏，并且代碼也不是最新的，我估計開源出來外面的人用的還不太多，希望慢慢能搞的更好一些。

    跟TT類似，另一個追求高吞吐量的MQ是linkedin開源的kafka。Kafka就跟這個名字一樣，設計非常獨特。首先，kafka的開發(fā)者們認為不需要在內(nèi)存里緩存什么數(shù)據(jù)，操作系統(tǒng)的文件緩存已經(jīng)足夠完善和強大，只要你不搞隨機寫，順序讀寫的性能是非常高效的。kafka的數(shù)據(jù)只會順序append，數(shù)據(jù)的刪除策略是累積到一定程度或者超過一定時間再刪除。Kafka另一個獨特的地方是將消費者信息保存在客戶端而不是MQ服務器，這樣服務器就不用記錄消息的投遞過程，每個客戶端都自己知道自己下一次應該從什么地方什么位置讀取消息，消息的投遞過程也是采用客戶端主動pull的模型，這樣大大減輕了服務器的負擔。Kafka還強調(diào)減少數(shù)據(jù)的序列化和拷貝開銷，它會將一些消息組織成Message Set做批量存儲和發(fā)送，并且客戶端在pull數(shù)據(jù)的時候，盡量以zero-copy的方式傳輸，利用sendfile（對應java里的FileChannel.transferTo/transferFrom）這樣的高級IO函數(shù)來減少拷貝開銷。可見，kafka是一個精心設計，特定于某些應用的MQ系統(tǒng)，這種偏向特定領(lǐng)域的MQ系統(tǒng)我估計會越來越多，垂直化的產(chǎn)品策略值的考慮。

     在此期間，我還重新去看了activemq和hornetq的存儲實現(xiàn)，從實現(xiàn)上大家都大同小異，append log + data file的模式。Activemq采用異步隊列寫來提高吞吐量，而Hornetq干脆就直接利用JNI調(diào)用原生aio來實現(xiàn)高性能。在搜索Java的aio實現(xiàn)的時候，碰巧發(fā)現(xiàn)Mina的沙箱里有個aioj的實現(xiàn)，源碼在：https://svn.apache.org/repos/asf/mina/sandbox/mheath/aioj/ 。我測試了完全可用，也嘗試改造我們的磁盤存儲組件，可惜提升不多，估計不從整個設計上調(diào)整服務器，不大可能從aio上獲益。

     最近也重新看起了clojure的一些開源項目，clojure的開源資源在github上也非常豐富，有待挖掘，下次有機會再嘗試介紹一二。