1、分佈式RPC存在的問題
假如後端的訂單服務提供了四臺服務器給客戶端使用，而客戶端使用的是配置文件的方式配置了後端服務的地址，那麼問題就出現了，如果後臺的訂單服務故障或者新增了新的服務器，客戶端是無法實時知道的，這就導致服務不穩定。
2、抽象一下：註冊中心
可以考慮提供一個註冊中心，客戶端如果需要服務時，直接請求註冊中心來獲取。而註冊中心返回一個可用的地址。
這個註冊中心的數據結構如果設計爲樹形結構，如下所示：
其中/orderService表達了一個服務的概念，而下面的每個節點表示的是一個服務的實例。（orderService表示訂單服務，而node表示的是每個有訂單服務的服務器實例。）而每個節點也是需要和註冊中心能進行通信的，因爲只有這樣，註冊中心才能知道實時的正常服務。
3、master選舉機制
思路：三個Batch Job啓動以後，都去註冊中心爭搶去創建一個樹的節點。（如/master）誰先創建成功，誰就是master(註冊中心必須保證只能創建成功一次，其他請求就失敗了。)其他兩個batch job就對這個節點進行監控，如果這個節點被刪除，就開始新一輪的爭搶。
個人小結：
zookeeper可以用來實現分佈式鎖，同時也可以用來作爲服務註冊中心，其主要特點就是其數據結構是一個類似下面的樹狀圖。可以使用sdk來增刪改查各種節點。當時，只要你想象力夠豐富，還可以做很多其他的事情。當然，zookeeper可以搭建集羣來實現高可用。
