莊周夢(mèng)蝶

    最近因?yàn)榭臻e時(shí)間有一些，所以去看了不少開源項(xiàng)目，大部分東西如果看過不記錄下來(lái)，其實(shí)還是相當(dāng)于沒看，所以想想還是有必要摘要記錄一下。

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

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

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

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

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