ZooKeeper初體驗

近日，公司的服務在multi-server、multi-thread下的運作遇上了同步處理時的問題。簡單的說，就是唯一的resource同時兩個server都搶到。這實在是不能允許的問題。這個服務是jackmis後來接手管理的，不然在下在使用multiserver, multithread的架構時就會要求注意此問題。不過據說起先是single server，所以只用補強的方式來必免問題；老實說，在jackmis的感覺裡，補強的方式可以說是無效的。個人認為這是基本的functional requirement，一定要做到處置有效才行，沒做到、沒proof根本不能上線。總之，要儘快解決問題。

正好最近在看Hadoop相關資料時，讀到一個叫ZooKeeper的東西。我想他可以用來保持multiserver下的一致性，那一定可以拿來做分佈式鎖。更重要的是，ZooKeeper已經從Hadoop分出來成為一個獨立項目，那表示它很可能可以被獨立使用。

經過survery，它果然完全符合我所有的需求，穩定而且簡單易用。雖然它要求的資源有點大，但我想我們的服務並沒有要求那麼多的資源，因此我並不想理會它的系統需求(心臟很大)，便測試架設ZooKeeper並寫了一些使用ZooKeeper的sample code、套用分佈式鎖的sample code給工程師，讓他把ZooKeeper加到服務的架構裡。

之後就解決了分佈式鎖的問題，工程師也覺得ZooKeeper彈性、簡單又好用。目前(2013-6-29)，ZooKeeper最後一次發佈是在2011年。我認為這表示它很穩定了，不太需要再更新。

ZooKeeper是獨立Service，所以可以獨立執行。它的部署方式就是把程式copy到目的地→調設定→執行。然後就可以用它提供的API來叫用服務。

因為ZooKeeper的使用與設定都很簡單，所以請各位自己上官網學習吧。基本上它就像是從網路抓程式回來，然後執行它的執行檔一樣，就能run起來了。

在此分享兩個API使用上的經驗。

首先，ZooKeeper的API使用的是long session的機制，所以當我們建立ZooKeeper的實例時，連線未必已經建立；因為ZooKeeper有一個自己的pooling機制。所以建立Zookeeper實例後立刻使用服務，有時會得到連線失敗等錯誤。又因為ZooKeeper是long session，所以建議不要一直開開關關，否則建立連線時經常會花費許多時間。

另一個分享的是配置：

autopurge.snapRetainCount=3
autopurge.purgeInterval=1

上面autopurge.xxx是用來清ZooKeeper日誌的(不是log4j的日誌喔!)。因為ZooKeeper會定期把memoery裡的東西寫到硬碟裡，久了會佔很多空間。若是這些日志對你的service沒有實際用途或是價值很差，可以選擇把它刪掉。在最新幾版的ZooKeeper裡，它們加入幾個配置讓ZooKeeper自己去刪掉日志。也就是上面的配置。