zookeeper_負載均衡

本文介紹zookeeper在集羣負載均衡中的應用。

1、zookeeper的重要概念總結：

• zookeeper的數據是樹形結構的，與linux目錄結構是同樣的，zeekeeper的每一個數據目錄就是一個znode(節點)；
• zookeeper的全部服務器中的全部數據結構（樹形結構）是徹底同樣的，就是說我搭建一個zookeeper集羣，集羣裏面全部的機器的數據同樣的；
  
  

• zookeeper的做用：分佈式，開源的分佈式引用程序協調服務；

  也就是第三方，要你查數據的時候，能夠返還給客戶端，因此具體他是不知道幹什麼的
  （最重要的功能也就是替客戶端保管數據，爲客戶提供數據的監聽服務)

  內部本身設計了本身分佈式內存數據庫（用於保管數據）
• zookeeper底層其實就提供了兩個功能：
• 一、管理（存儲、讀取）用戶程序提交的數據； 二、爲用戶程序提交數據節點監聽服務；
• zookeeper自己就是一個分佈式程序（只要半數以上節點存活，Zookeeper就能正常服務）；                                                                                                                                                                                                                                                                      2、zookeeper在集羣負載均衡中的應用
  
  
  上文中大體介紹了zookeeper的概念和應用，從上文中得知，zookeeper自己是不提供負載均衡的策略的，須要本身來實現，因此肯定的說：是在負載均衡中應用到了zookeeper作集羣的協調；
  
  
  對於http請求的負載均衡，成熟的解決方案是Nginx(或者Haproxy)+keepalived。其中Niginx負責代理Http請求，經過某種負載均衡策略訪問集羣中的服務器，keepalived負責檢測集羣中的服務器運行狀況（有故障的機器移除，機器回覆工做後從新加入）；
  
  
  而對應TCP層的負載均衡，好比用Apache Mina作的網絡通訊用用，上面這種方案明顯不合適，由於網絡通訊客戶端和服務端要保持長鏈接， 因此針對這種長鏈接作的負載均衡，通常都是基於鏈接數這種均衡策略，也就是在第一次鏈接時，分配服務器ip,取當前鏈接數最少的那臺服務器進行鏈接；
  
  
  集羣中有幾臺服務器處於運行狀態，每一臺服務器鏈接的客戶數量，最大鏈接數，等等這些信息都須要記錄起來，而後每次作負載均衡時根據這些信息來作分配，通常首先想到的是將這些信息存放到數據庫裏。
  
  
  簡單的作法就是
  
  
  服務器啓動時，--------->把數據庫裏相應的狀態改成運行;
  
  
  客戶鏈接或者斷開時----->把鏈接數作加數或者減數運算;
  
  
  可是，服務器關閉時，問題就出現了:
  
  
  一、服務器關閉，能夠數據源也已經被關閉了，無法操做數據庫，該機器在數據庫裏一直處於運行狀態（數據庫不能及時記錄服務器狀態。）
  
  
  二、服務器宕機，這種問題就很致命，這是鏈關閉的程序都沒有執行，更不用說能操做數據庫了。
  
  
  解決的方案就是用zookeeper保存服務器的鏈接信息：
  
  
  一、當服務器啓動時，往zookeeper的節點裏寫入數據（節點的類型是臨時節點）；
  
  
  二、當關閉服務器時，從zookeeper移除相應的節點數據；
  
  
  三、當服務器宕機，zookeeper由於沒有檢測到心跳，自動把該節點移除，並通知其餘服務器，其餘服務器得知該機器已宕機，在分配鏈接時，不會分配到這臺機器上，這點也就是本文中所說，負載均衡中使用zookeeper的緣由。
  
  
  

對比了一下保存在數據庫那種方式，zookeeper其實就是一個具備通知功能的數據庫，也就是它底下節點數據有變化時，會通知它的全部客戶端（這裏的客戶端指的鏈接到zookeeper的服務器）

更多技術資訊可關注：gzitcast