前言：最近工作不是很忙，本應(yīng)該乘著閑暇的時間看書的，之前每天晚上都要翻翻的，可是自己竟然迷戀上了王曉磊 寫的 卑鄙的小人-曹操傳? 剛開始的時候還沒啥 后面迷的無法自控，以前中午吃完飯的時候，都是趴著玩手機，現(xiàn)在是一吃完飯都是拿著kindle看上一會兒，弄的技術(shù)書好久都沒翻過 連博客也不寫了，實在不該，罪過罪過 ，一個技術(shù)狗 不搞技術(shù)，那不是坐著等死嗎。話不多說，回歸正題。
? ? 前段時間 我給大家介紹了ZK的一些基礎(chǔ)知識，讓大家對ZK有了一個初步了解，但在實際的過程中 怎么將zk運用到實際的項目中去了 zk的節(jié)點有幾種特點，以及如何調(diào)整好我們的zk配置 才能達到最優(yōu)了 今天我給大家簡單的介紹一下。
我們以我們的實際項目為例 給大家介紹一下。 場景：我們有兩個直播房間服務(wù)yunva-room，用戶登入房間，根據(jù)yunva-room-lvs服務(wù)將房間里的用戶分部在不同的服務(wù)機器上，即不同的服務(wù)器有相同的房間，房間里有不同的用戶。那么這時候問題就來了
1 分布在不同服務(wù)器上的相同房間怎么保證用戶數(shù)負載均衡? ？
2? 一臺機器的房間服務(wù)掛掉后，另一臺服務(wù)器怎么感知？
此時ZK的出現(xiàn) 可以很好的解決這兩個問題。
解決方式： 1? 將不同服務(wù)器上房間用戶的數(shù)據(jù)都掛在ZK上，根據(jù)zk的數(shù)據(jù)的變化 動態(tài)的將用戶分配在合適的機器上。
? ? ? ? ? ? ? ? ? 2? ZK的臨時節(jié)點的變化，ZK是可以感知的，可以通知到其他的臨時節(jié)點，這樣就很好的解決一臺服務(wù)掛掉后，很好的通知到另幾臺房間服務(wù)所在的服務(wù)器。將緩存在本地的可用房間服務(wù)列表清掉即可。
不同服務(wù)器上的房間服務(wù)啟動后，向ZK注冊自己的房間服務(wù)信息并建立節(jié)點 配置的信息寫在配置文件上
服務(wù)啟動后向zk注冊 并訂閱監(jiān)聽子節(jié)點時間，接受其他房間服務(wù)掛掉的通知：
RoomServerInfo 和 ServiceInfo 是我們房間服務(wù) 節(jié)點 的基本配置信息
yunva-room 服務(wù)啟動后都會向zk注冊，zk里的節(jié)點信息如下：
roomServer節(jié)點下面都是我們的不同的房間服務(wù)? 房間里面的數(shù)據(jù)大家大家也是可以看得到的。
yunva-room-lvs 服務(wù)啟動后? 會向zk訂閱所有的房間服務(wù) 進行用戶的分配 達到負載均衡。訂閱房間服務(wù)的時候，全部load到本地緩存中，如果子節(jié)點發(fā)生變化了，則從本地緩存中移除掛掉的服務(wù)數(shù)據(jù)。也就不進行用戶的分配。
當(dāng)我們的房間服務(wù)掛掉后 我們的節(jié)點也就發(fā)生了變化，在此之前，我們簡單的介紹一下ZK的節(jié)點相關(guān)知識，
ZK的節(jié)點是有生命周期的，可以分為以下幾種節(jié)點：
持久節(jié)點（PERSISTENT）
所謂持久節(jié)點，是指在節(jié)點創(chuàng)建后，就一直存在，直到有刪除操作來主動清除這個節(jié)點——不會因為創(chuàng)建該節(jié)點的客戶端會話失效而消失。
臨時節(jié)點（EPHEMERAL）
和持久節(jié)點不同的是，臨時節(jié)點的生命周期和客戶端會話綁定。也就是說，如果客戶端會話失效，那么這個節(jié)點就會自動被清除掉。注意，這里提到的是會話失效，而非連接斷開。另外，在臨時節(jié)點下面不能創(chuàng)建子節(jié)點。
我們創(chuàng)建的節(jié)點肯定是臨時的，服務(wù)掛掉后，子節(jié)點也就消失了 ZK感知后 通知到訂閱節(jié)點變化的服務(wù)yunva-room-lvs 從本地移除到?jīng)]有用的服務(wù)。
回歸到如何監(jiān)聽節(jié)點 我們用的zk 是用開源的curator框架來進行對zk操作，這個比較成熟，還有一些類似其他的vertx spring-clound 都有對zk的封裝 ，大家如果有時間的話 可以看一下 挺有意思的。
那么curator 監(jiān)聽的節(jié)點三種方式：
1 PathChildrenCache? PathChildrenCacheListener 監(jiān)聽子節(jié)點變化
實現(xiàn)類似如下：
2 NodeCache NodeCacheListener 監(jiān)聽父節(jié)點變化 如下：
3 TreeCache TreeCacheListener 監(jiān)聽父節(jié)點和子節(jié)點的變化 如下：
在我們的項目中肯定用的是監(jiān)聽子節(jié)點變化 能感知服務(wù)是否可用
我們監(jiān)聽子節(jié)點的方式? 訂閱子節(jié)點變化的時候 我們用了java 的觀察者模式? 有變化 通知到實際的服務(wù)
上面我們講到了 我們要實現(xiàn)不同服務(wù)器的房間用戶負載均衡，房間人數(shù)是要掛到ZK服務(wù)上去的，并且要實現(xiàn)負載均衡算法。 由于yunva-room-lvs 監(jiān)聽節(jié)點了變化? 每次用戶登入房間 zk節(jié)點發(fā)生變化 并同步到y(tǒng)unva-room-lvs 即不同服務(wù)器上的房間人數(shù)也同步到了本地緩存? 負載均衡 根據(jù)yunva-room-lvs 本地緩存的房間數(shù)據(jù)來進行分配房間的服務(wù)器分配即可。
用戶登入房間 yunva-room感知后? 向zk偽實時（2分鐘同步一次）同步數(shù)據(jù)：
yunva-room-lvs 進行用戶服務(wù)器的分配
? ? 本想給大家繼續(xù)介紹在ZK服務(wù)實際在生產(chǎn)環(huán)境的優(yōu)化配置? 使ZK達到最好的狀態(tài) 今天就到這里吧 我都沒吃飯 在公司默默的碼字。 今天簡單的介紹了zk在實際項目中的運用以及zk節(jié)點以及如何監(jiān)聽的基本知識，后面我給大家介紹ZK的生產(chǎn)環(huán)境優(yōu)化我們的配置? 以及其他的一些知識? 比如分布式鎖? 分布式隊列 我們這個項目已經(jīng)在線上穩(wěn)定運行。是一個很好的例子? 而且我們的并發(fā)還很高。?
? ? ? 不多說了? 該回去吃狗糧了? 不然猝死在辦公桌上都沒人收尸，我是小志碼字，一個簡單碼代碼的小人物。如果想了解這個項目和代碼? 加我微信? 微信號：2B青年? 歡迎交流 相互學(xué)習(xí)。
