初識kafka的zookeeper

 

        最近項目中，使用redis進行消息的分發與訂閱。這種模式就是一種多播的方式，可是隨着消息的不斷增長，消費端來不及處理全部的數據。在沒有持久化的功能下，不少數據丟失了。固然，也可使用redis的list,的確這是一個好主意，可是咱們的list須要給不一樣的用戶，list中一旦pop以後，數據就沒有了，它針對的是單一的用戶。且，由於隊列中的數據很重要，一旦數據在處理的過程當中發生了失敗，那麼操做失敗->數據也丟失了。替代方案，採用了rpoplpush，這種設計卻無故的增長了複雜性。固，持久化，多用戶，kafka彷佛在這方面表現的很好。

1、      Kafka的基本構件

Kafka就是一個分佈式的消息系統。由producer、broker、consumer、zookeeper這幾大構件組成。Zookeeper的引入極大的支持了其拓展。

Producer：生產者。向broker中發佈信息。

Broker：服務器，一臺服務器能夠視爲一個Broker,衆多的broker構成集羣。

Topic：按照redis來講，有點相似頻道，即發佈消息的隊列名稱

Partition：分區,每一個topic包含1個到多個topic,就mongodb來講，有點像其shard。可是在kafka中，分區的上一層是topic.

Consumer:消費者，從broker的partition中pull數據。

Controller:進行leader選擇及faliover的維護

 

以文件的方式存儲數據，能夠適應不一樣的用戶處理數據的需求，更大的保護數據不丟失。

2、      Zookeeper做用

管理broker、consumer

建立Broker後，向zookeeper註冊新的broker信息，實如今服務器正常運行下的水平拓展。具體的，經過註冊watcher，獲取partition的信息。

Topic的註冊，zookeeper會維護topic與broker的關係，經過/brokers/topics/topic.name節點來記錄。

Producer向zookeeper中註冊watcher,瞭解topic的partition的消息，以動態瞭解運行狀況，實現負載均衡。Zookeepr是沒有管理producer，只是可以提供當前broker的相關信息。

Consumer可使用group形式消費kafka中的數據。全部的group將以輪詢的方式消費broker中的數據，具體的按照啓動的順序。Zookeeper會給每一個consumer group一個ID,即同一份數據能夠被不一樣的用戶ID屢次消費。所以這就是單播與多播的實現。以單個消費者仍是以組別的方式去消費數據，由用戶本身去定義。Zookeeper管理consumer的offset跟蹤當前消費的offset.

3、      Kafka的zookeeper與mongodb的blancer
  

     由於先接觸的mongodb,在最初瞭解kafka的時候，我認爲kafka對於用戶來講只提供單一的接口，全部的負載均衡，包括節點失效等都由內部機制決定。先說說mongodb

在mongodb中有一個blancer的後臺進程，根據設置的片鍵，塊大小，獲取全部分片的當前信息。根據當前chunk數量計算shard相對較空的分片，而後進行塊轉移。自動的平衡數據，用戶須要作的事情是合理的設置索引、片鍵等信息。當mongodb的某一個分片失效或者是某個服務器失效時，以副本集+分片的部署方式中，mongodb會根據必定的算法自動的選擇出正確的基分片。Mongos做爲全部的入口。

Kafka的zookeeper一樣利用controller來選擇出leader來，有着failover的功能，可是用戶在鏈接的時候，必須利用watcher來獲知當前的broker的信息，發佈信息到指定的Topic，甚至利用算法將信息發佈到指定的partition中，在mongodb中數據具體存儲在哪一個shard,咱們是不用去處理。若是broker已經失效，producer須要本身實現負載均衡。 ---------------------