keepalived和zookeeper對比 漫天雪_崑崙巔2018-01-15 17:28:18 6896 收藏2 分類專欄：Hadoop研究文章標籤：keepalivedkeepalived 和zookeeper對比zookeeper 版權 keepalived與zookeeper都可以用來實現高可用，高可用一般跟負載均衡會一起考慮，所以通常也會考慮到相應的負載均衡能力， 以下是Keepalived與Zookeeper的對比： 一、概括對比： 1、Keepalived： 優點：簡單，基本不需要業務層面做任何事情，就可以實現高可用，主備容災。而且容災的宕機時間也比較短。 缺點：也是簡單，因為VRRP、主備切換都沒有什麼複雜的邏輯，所以無法應對某些特殊場景，比如主備通訊鏈路出問題，會導致腦裂。同時，keepalived也不容易做負載均衡。 2、zookeeper： 優點：可以支援高可用，負載均衡。本身是個分散式的服務。 缺點：跟業務結合的比較緊密。需要在業務程式碼中寫好ZK使用的邏輯，比如註冊名字。拉取名字對應的服務地址等。 所以，區別很明顯。從簡單性來說：Keepalived最簡單，zookeeper稍微複雜一些。 從負載均衡能力來看，zookeeper較強，Keepalived弱很多。 從與業務的緊密程度來看：zookeeper最緊密，而Keepalived基本跟業務層面沒有關係。 keepalive只可以選出一臺機器作為主機，所以keepalive只能實現M:1的備份 zookeeper可以選出N臺機器作為主機，它可以實現M:N的備份 二、具體明細對比： 1.從主被動的角度考慮 我們知道，nginx server通常和keepalived進行結合，那麼keepalived是怎麼知道nginx是否存活呢?是nginx主動向keepalived彙報資訊？不是的。keepalived是主動向nginx傳送請求，如果有響應，那麼則nginx可用。 對於zookeeper而言，HDFS，HBase，Yarn基於zookeeper做高可用，這裡的zookeeper就是被動的，也就是說HDFS，HBase，Yarn主動向zookeeper中寫資料。 2.從負載的角度來考慮 keepalived可以幫助我們做到主從，主從的劃分是通過配置檔案（主從的priority之差>50）指定的，如果主沒有掛掉，那麼大量的請求通過主然後負載到後端的nginx，而從如果想要起作用只有等到主掛掉。 而利用zookeeper做HA，zookeeper中可以說是“人人平等”，客戶端無論訪問follower，還是observer，異或是leader，都能給我們返回相應的結果，可以很好的實現了負載均衡，這也可以說是zookeeper的一個優點。 3.從儲存資料的角度 keepalived不可以儲存資料，假設keepalived的主現在有50個連線，如果沒有外部資料庫儲存這些連線的資訊，主掛了的話，連線資訊也就丟了，所以使用keepalived需要一個外部的資料庫，但是如果主掛了的同時資料庫也掛了，那麼就over了，資訊就會丟失，或者從起來後，連不上資料庫，那麼之前的連線資訊也會丟失。 zookeeper可以儲存資料，zookeeper中可以建立一個zNode，裡面存放資料，zookeeper可以做到一個分散式資料的一致性，zookeeper中每個節點的檢視是一致的，資料本身可以做到最終一致性，也就是說其中一個server掛了，其他的server還有存的資料，那麼這樣的話就不需要額外的資料庫，zookeeper本身就可以儲存一定量的資訊。這也可以說是zookeeper的另一個優點。 4.從業務的角度 keepalived可以說比較簡單，只需要簡單的配置一下就可以了，使用keepalived的場景：如果我們只需要簡單的知道當前的業務中哪個是主，哪個是從，那麼可以選用keepalived。 如果除了高可用以外，比如kafka，storm等還要想zookeeper中寫一些資料，這時候就需要zookeeper。