kafka 的 zookeeper 初识

初识kafka的zookeeper

 

        最近项目中，使用redis进行消息的分发与订阅。这种模式就是一种多播的方式，但是随着消息的不断增加，消费端来不及处理所有的数据。在没有持久化的功能下，很多数据丢失了。当然，也可以使用redis的list,的确这是一个好主意，但是我们的list需要给不同的用户，list中一旦pop之后，数据就没有了，它针对的是单一的用户。且，因为队列中的数据很重要，一旦数据在处理的过程中发生了失败，那么操作失败->数据也丢失了。替代方案，采用了rpoplpush，这种设计却无端的增加了复杂性。固，持久化，多用户，kafka似乎在这方面表现的很好。

一、      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的维护

 

以文件的方式存储数据，可以适应不同的用户处理数据的需求，更大的保护数据不丢失。

二、      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.

三、      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需要自己实现负载均衡。