Zookeeper与Kafka基础概念和原理

一、zookeeper概念介绍

　　在介绍ZooKeeper以前，先来介绍一下分布式协调技术，所谓分布式协调技术主要是用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种共享资源，防止形成资源竞争（脑裂）的后果。

　　这里首先介绍下什么是分布式系统，所谓分布式系统就是在不一样地域分布的多个服务器，共同组成的一个应用系统来为用户提供服务，在分布式系统中最重要的是进程的调度，这里假设有一个分布在三个地域的服务器组成的一个应用系统，在第一台机器上挂载了一个资源，而后这三个地域分布的应用进程都要竞争这个资源，但咱们又不但愿多个进程同时进行访问，这个时候就须要一个协调器，来让它们有序的来访问这个资源。这个协调器就是分布式系统中常常提到的那个“锁”，例如”进程1“在使用该资源的时候，会先去得到这把锁，”进程1“得到锁之后会对该资源保持独占，此时其它进程就没法访问该资源，“进程1”;在用完该资源之后会将该锁释放掉，以便让其它进程来得到锁。因而可知，经过这个“锁”机制，就能够保证分布式系统中多个进程可以有序的访问该共享资源。这里把这个分布式环境下的这个“锁”叫做分布式锁。这个分布式锁就是分布式协调技术实现的核心内容。

　　目前，在分布式协调技术方面作得比较好的有Google的Chubby，还有Apache的ZooKeeper，它们都是分布式锁的实现者。ZooKeeper所提供锁服务在分布式领域久经考验，它的可靠性、可用性都是通过理论和实践验证的。

　　ZooKeeper是一种为分布式应用所设计的高可用、高性能的开源协调服务，它提供了一项基本服务：分布式锁服务，同时，也提供了数据的维护和管理机制，如：统一命名服务、状态同步服务、集群管理、分布式消息队列、分布式应用配置项的管理等等。

二、zookeeper应用举例

1）什么是单点故障问题呢？

　　所谓单点故障，就是在一个主从的分布式系统中，主节点负责任务调度分发，从节点负责任务的处理，而当主节点发生故障时，整个应用系统也就瘫痪了，那么这种故障就称为单点故障。那咱们的解决方法就是经过对集群master角色的选取，来解决分布式系统单点故障的问题。

2）传统的方式是怎么解决单点故障的？以及有哪些缺点呢？

　　传统的方式是采用一个备用节点，这个备用节点按期向主节点发送ping包，主节点收到ping包之后向备用节点发送回复Ack信息，当备用节点收到回复的时候就会认为当前主节点运行正常，让它继续提供服务。而当主节点故障时，备用节点就没法收到回复信息了，此时，备用节点就认为主节点宕机，而后接替它成为新的主节点继续提供服务。

　　这种传统解决单点故障的方法，虽然在必定程度上解决了问题，可是有一个隐患，就是网络问题，可能会存在这样一种状况：主节点并无出现故障，只是在回复ack响应的时候网络发生了故障，这样备用节点就没法收到回复，那么它就会认为主节点出现了故障，接着，备用节点将接管主节点的服务，并成为新的主节点，此时，分布式系统中就出现了两个主节点（双Master节点）的状况，双Master节点的出现，会致使分布式系统的服务发生混乱。这样的话，整个分布式系统将变得不可用。为了防止出现这种状况，就须要引入ZooKeeper来解决这种问题。

3）zookeeper的工做原理是什么？

　　下面经过三种情形来说解：

　　（1）master启动

　　在分布式系统中引入Zookeeper之后，就能够配置多个主节点，这里以配置两个主节点为例，假定它们是 主节点A 和 主节点B，当两个主节点都启动后，它们都会向ZooKeeper中注册节点信息。咱们假设 主节点A 锁注册的节点信息是 master00001 ， 主节点B 注册的节点信息是 master00002 ，注册完之后会进行选举，选举有多种算法，这里以编号最小做为选举算法，那么编号最小的节点将在选举中获胜并得到锁成为主节点，也就是 主节点A 将会得到锁成为主节点，而后 主节点B 将被阻塞成为一个备用节点。这样，经过这种方式Zookeeper就完成了对两个Master进程的调度。完成了主、备节点的分配和协做。

　　（2）master故障

　　若是  主节点A 发生了故障，这时候它在ZooKeeper所注册的节点信息会被自动删除，而ZooKeeper会自动感知节点的变化，发现 主节点A  故障后，会再次发出选举，这时候  主节点B  将在选举中获胜，替代  主节点A  成为新的主节点，这样就完成了主、被节点的从新选举。

　　（3）master恢复

　　若是主节点恢复了，它会再次向ZooKeeper注册自身的节点信息，只不过这时候它注册的节点信息将会变成 master00003 ，而不是原来的信息。ZooKeeper会感知节点的变化再次发动选举，这时候 主节点B 在选举中会再次获胜继续担任  主节点 ， 主节点A 会担任备用节点。

　　zookeeper就是经过这样的协调、调度机制如此反复的对集群进行管理和状态同步的。

 4）zookeeper集群架构

　　zookeeper通常是经过集群架构来提供服务的，下图是zookeeper的基本架构图。

　　

　　zookeeper集群主要角色有server和client，其中server又分为leader、follower和observer三个三绝，每一个角色的含义以下：

Leader：领导者角色，主要负责投票的发起和决议，以及更新系统状态。
follower：跟随着角色，用于接收客户端的请求并返回结果给客户端，在选举过程当中参与投票。
observer：观察者角色，用户接收客户端的请求，并将写请求转发给leader，同时同步leader状态，可是不参与投票。Observer目的是扩展系统，提升伸缩性。
client：客户端角色，用于向zookeeper发起请求。

　　Zookeeper集群中每一个Server在内存中存储了一份数据，在Zookeeper启动时，将从实例中选举一个Server做为leader，Leader负责处理数据更新等操做，当且仅当大多数Server在内存中成功修改数据，才认为数据修改为功。

　　Zookeeper写的流程为：客户端Client首先和一个Server或者Observe通讯，发起写请求，而后Server将写请求转发给Leader，Leader再将写请求转发给其它Server，其它Server在接收到写请求后写入数据并响应Leader，Leader在接收到大多数写成功回应后，认为数据写成功，最后响应Client，完成一次写操做过程。

三、Kafka基础与入门

1）kafka基本概念

　　Kafka是一种高吞吐量的分布式发布/订阅消息系统，这是官方对kafka的定义，这样提及来，可能不太好理解，这里简单举个例子：如今是个大数据时代，各类商业、社交、搜索、浏览都会产生大量的数据。那么如何快速收集这些数据，如何实时的分析这些数据，是一个必需要解决的问题，同时，这也造成了一个业务需求模型，即生产者生产（produce）各类数据，消费者（consume）消费（分析、处理）这些数据。那么面对这些需求，如何高效、稳定的完成数据的生产和消费呢？这就须要在生产者与消费者之间，创建一个通讯的桥梁，这个桥梁就是消息系统。从微观层面来讲，这种业务需求也可理解为不一样的系统之间如何传递消息。

　　kafka是Apache组织下的一个开源系统，它的最大的特性就是能够实时的处理大量数据以知足各类需求场景：好比基于hadoop平台的数据分析、低时延的实时系统、storm/spark流式处理引擎等。kafka如今它已被多家大型公司做为多种类型的数据管道和消息系统使用。

2）kafka角色术语

　　kafka的一些核心概念和角色

Broker：Kafka集群包含一个或多个服务器，每一个服务器被称为broker。
Topic：每条发布到Kafka集群的消息都有一个分类，这个类别被称为Topic（主题）。
Producer：指消息的生产者，负责发布消息到kafka broker。
Consumer：指消息的消费者，从kafka broker拉取数据，并消费这些已发布的消息。
Partition：Partition是物理上的概念，每一个Topic包含一个或多个Partition，每一个partition都是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。
Consumer Group：消费者组，能够给每一个Consumer指定消费组，若不指定消费者组，则属于默认的group。
Message：消息，通讯的基本单位，每一个producer能够向一个topic发布一些消息。

 3）kafka拓扑架构

　　一个典型的Kafka集群包含若干Producer，若干broker、若干Consumer Group，以及一个Zookeeper集群。Kafka经过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。典型架构以下图所示：

 

　　从图中能够看出，典型的消息系统有生产者（Producer），存储系统（broker）和消费者（Consumer）组成，Kafka做为分布式的消息系统支持多个生产者和多个消费者，生产者能够将消息分布到集群中不一样节点的不一样Partition上，消费者也能够消费集群中多个节点上的多个Partition。在写消息时容许多个生产者写到同一个Partition中，可是读消息时一个Partition只容许被一个消费组中的一个消费者所消费，而一个消费者能够消费多个Partition。也就是说同一个消费组下消费者对Partition是互斥的，而不一样消费组之间是共享的

　　kafka支持消息持久化存储，持久化数据保存在kafka的日志文件中，在生产者生产消息后，kafka不会直接把消息传递给消费者，而是先要在broker中进行存储，为了减小磁盘写入的次数，broker会将消息暂时缓存起来，当消息的个数或尺寸、大小达到必定阀值时，再统一写到磁盘上，这样不但提升了kafka的执行效率，也减小了磁盘IO调用次数。

　　kafka中每条消息写到partition中，是顺序写入磁盘的，这个很重要，由于在机械盘中若是是随机写入的话，效率将是很低的，可是若是是顺序写入，那么效率倒是很是高，这种顺序写入磁盘机制是kafka高吞吐率的一个很重要的保证。

4）Topic和partition　　

　　Kafka中的topic是以partition的形式存放的，每个topic均可以设置它的partition数量，Partition的数量决定了组成topic的log的数量。推荐partition的数量必定要大于同时运行的consumer的数量。另外，建议partition的数量要小于等于集群broker的数量，这样消息数据就能够均匀的分布在各个broker中

　　那么，Topic为何要设置多个Partition呢，这是由于kafka是基于文件存储的，经过配置多个partition能够将消息内容分散存储到多个broker上,这样能够避免文件尺寸达到单机磁盘的上限。同时，将一个topic切分红任意多个partitions，能够保证消息存储、消息消费的效率，由于越多的partitions能够容纳更多的consumer，可有效提高Kafka的吞吐率。所以，将Topic切分红多个partitions的好处是能够将大量的消息分红多批数据同时写到不一样节点上，将写请求分担负载到各个集群节点。

 　　在存储结构上，每一个partition在物理上对应一个文件夹，该文件夹下存储这个partition的全部消息和索引文件。partiton命名规则为topic名称+序号，第一个partiton序号从0开始，序号最大值为partitions数量减1。

　　在每一个partition(文件夹)中有多个大小相等的segment(段)数据文件，每一个segment的大小是相同的，可是每条消息的大小可能不相同，所以segment<br/>数据文件中消息数量不必定相等。segment数据文件有两个部分组成，分别为index file和data file，此两个文件是一一对应，成对出现，后缀”.index“和“.log”分别表示为segment索引文件和数据文件。

5）Producer生产机制

　　Producer是消息和数据的生产者，它发送消息到broker时，会根据Paritition机制选择将其存储到哪个Partition。若是Partition机制设置的合理，全部消息均可以均匀分布到不一样的Partition里，这样就实现了数据的负载均衡。若是一个Topic对应一个文件，那这个文件所在的机器I/O将会成为这个Topic的性能瓶颈，而有了Partition后，不一样的消息能够并行写入不一样broker的不一样Partition里，极大的提升了吞吐率。

6）Consumer消费机制

　　Kafka发布消息一般有两种模式：队列模式（queuing）和发布/订阅模式(publish-subscribe)。在队列模式下，只有一个消费组，而这个消费组有多个消费者，一条消息只能被这个消费组中的一个消费者所消费；而在发布/订阅模式下，可有多个消费组，每一个消费组只有一个消费者，同一条消息可被多个消费组消费。　　

Kafka中的Producer和consumer采用的是push、pull的模式，即producer向 broker进行push消息，comsumer从bork进行pull消息，push和pull对于消息的生产和消费是异步进行的。pull模式的一个好处是consumer可自主控制消费消息的速率，同时consumer还能够本身控制消费消息的方式是批量的从broker拉取数据仍是逐条消费数据。