【Kafka】详解 以及Zookeeper

Kafka

1.kafka是什么

kafka的定义：Apache旗下的一款分布式流媒体框架，用于实时构建流处理应用，他的一个核心功能是作为企业级的消息引擎被广泛使用。

关键字，实时，流处理，消息引擎

2.kafka的特点

• 高吞吐量
  可以满足每秒百万级别的消息生产和消费
• 持久性
  有一套完善的消息存储机制，确保数据高效安全且持久化
• 分布式
  Kafka的数据都会复制在几台不同的服务器上，某台故障失效时，生产者和消费者会使用其他的Kafka

这篇文章主要从Kafka的这三个特性进行论述，主要是实现持久性和分布式的Zookeeper

3.消息引擎

在详细说明Kafka之前，我们先了解下，Kafka作为一个消息引擎，消息引擎的概念是什么，简单的说消息引擎就是怎么把一个地方的消息，接收处理，让另外一个需要他的地方准确接收到他需要的消息

3.1消息模式

• Peer-to-Peer（PTP）
  从名字我们就可以理解，这个是点对点的消息模式，那最简单的就是一个点发送的消息只有另外一个点能收得到，所以这是一个一对一的消息模式
• Publish/Subscribe（Topic）
  发布订阅关系，这个也比较好理解，一般分为Publisher，Topics，Subscriber三个角色，我们也可以理解为作为Subscriber的你，订阅了Topic为科技类的Publisher公众号“xxx”，那么Publisher只要发了文章，Topic接收到了，你订阅量了就能看到更新的文章，那么Subscriber肯定不止你一个，当然你也可以订阅不止一个Topic，一个Topic也可以对应不止一个Publisher，所以很明显，这是一个多对多的消息模式

而Kafka就是用的Publish/Subscribe（Topic）消息模式

3.2消息引擎类目

• Kafka
  这就是我们今天文章的主角了，用的P/S消息模式，高性能，跨语言的分布式系统，同时支持在线和离线处理
• RabbitMQ
  支持PTP和P/S两种模式，基于Erlang编写，改语言天生具备分布式特性，那么RabbitMQ也具有分布式
• ActiveMQ
  PTP支持持久化
• Redis
  Redis严格来说并不是一个消息引擎，只是他内部的List是双向列表，可以完成消息队列的一部分功能，但是由于Redis是基于内存的，所以不能处理大规模消息队列，但是如果消息比较短的话，Redis的速度很快

4.Kafka的架构

Kafka作为一个消息引擎的作用，肯定是上接消息产生者Producer，然后自己存储（Topic），然后转发发布给订阅者（Consumer），而Kafka的每个节点我们称为Broker，通过Broker去管理每个Topic

• Producer
  这个可以是多个渠道，比较常见的就是网站的用户行为日志
• Broker
  Kafka的节点被称为Broker，由他创建Topic并且存储来自Producer的消息，
• Topic
  一个Topic可以包含多个分区，并且分布在不同的Broker上，每个Topic有一个复制因子，可以决定这个Topic是否有备份一般建议与Broker数量保持一致
• Consumer
  从Kafka拿到自己订阅的消息

看到这里，如果了解过分布式的同学就会有疑问了，Kafka如果是分布式的架构，那么怎么管理分布式系统肯定是一个问题吧，那么这个就涉及到Zookeeper了，Kafka一般情况下是通过Zookeeper来管理的
所以面试的时候Kafka的问题除了上面的，更有深度的就是Kafka为什么会这么快了，这个我们写完Zookeeper再写，
如果我们在跟面试官聊完Kafka之后提到Zookeeper，那么面试官对你的认可度肯定是上升好几个等级的并且Zookeeper涉及到的东西还是不少的

5.Zookeeper

5.1Kafka和Zookeeper的关系

• 节点管理
  首先我们要知道的是，Zookeeper是替Kafka管理所有Broker节点的，当然Kafka最重要的也就是Broker的管理了，所以每个Broker节点服务器在启动的时候都会在Zookeeper上注册，成为一个临时或者持久节点（这个后面会讲到，关于Zookeeper的节点），
• 负载均衡
  这个负载均衡其实就是所有分布式系统都需要的一个功能了，毕竟所有的Producer生产消息如果全往一个Broker里面放的话，那么就成了旱的旱死涝旳涝死的局面了。了解负载均衡的类别可以看看负载均衡
  Kafka支持传统的四层负载均衡，Zookeeper同时也支持Zookeeper方式实现的负载均衡
  （1）传统的四层负载均衡：根据生产者的IP地址和端口号来为其定一个关联的Broker
  （2）生产者通过Zookeeper来感知Broker节点的状态，根据状态来选择Broker节点实现负载均衡
  消费者的负载均衡与生产者负载均衡类似
• 记录消息分区与消费者的关系
• 记录消息消费进度Offset记录
• Kafka中Broker中Controller的选举

5.2 Zookeeper集群角色

• Leader
  （1）发起并维护与各Follower和Observer间的心跳
  （2）所有写操作都必须经过Leader接收，再由Leader广播给其他服务器，只要超过半数节点写入成功，该写请求就会被提交。 这个其实是一个类2PC协议，2 Phase Commitment Protocol两阶段提交协议，第一个阶段是Leader收集Follower的操作情况，第二阶段是根据情况时要提交操作还是中止操作，可以保证分布式事务中数据的一致性
• Follower
  可以直接处理客户端的读请求，并将写请求转发给Leader处理，并且负责参与Leader处理写请求的时候进行投票，其实也就是自己被分配的写操作成功了就投一票
• Observer
  因为Zookeeper可拓展，为了支持更多的Client，必须增加更多的服务器，但是服务器越多，投票阶段的延迟就越大，如果Follower数量一直增加，Zookeeper的性能就会下降，所以新增了Observer角色，除了没有投票权，其他的跟Follower是一样的

集群角色其实就是每个节点在集群管理时的地位，除此之外，节点也有两种，一个节点key看作是一台服务器

1. 短暂节点
   会在客户端会话结束时Zookeeper删除该节点，并且该节点不可以有子节点
2. 持久节点
   只有在客户端明确要删除该节点时才会删除

在这个基础上还有短暂顺序节点和临时顺序节点，Zookeeper会根据时间顺序给节点名词进行排序，暂时节点主要用于分布式锁，分布式锁在对不同系统的不同进程进行处理时，给每个进程在锁对应的排序队列中创建一个临时顺序节点来存放进程。

5.3 Zookeeper的ZAB协议

对于任意一个系统来说，在系统崩溃后怎么恢复都是一个重要的问题，而Zookeeper的ZAB协议就是用来支持崩溃恢复的原子广播协议，全称为Zookeeper Atomic Broadcast，是保证数据一致性的核心算法，借鉴了Paxos算法

ZAB的核心就是在整个集群中写操作只有Leader这个节点将写操作转化成事务或者说是Proposal，Leader节点写完数据后，向所有的Follower节点发送数据广播请求（或数据辅助），超过半数反馈OK，Leader节点就会向所有节点发送commit消息，也就是将Leader节点上的数据同步到Follower节点上。

这个过程主要包括两种模式，消息广播模式和崩溃恢复模式，

• 消息广播模式
  zookeeper的数据副本的同步方式和2PC的二阶段有所不同，虽然都是需要半数超过就可以进行，但是2PC需要接收到所有Follower节点的消息之后才进行，这会有严重的阻塞问题，但是消息广播模式是只要超过半数以上的Follower成功反馈就可以直接进行了
  具体步骤
  （1）客户端发起写操作请求
  （2）Leader服务器将客户端的request请求转化为proposal提案，同时为每一个proposal分配一个全局的ID，即ZXID
  （3）Leader和每个Follower之间有一个队列，leader把消息proposal发给队列
  （4）Follower从队列取出消息处理完后向leader服务器发送ACK
  （5）Leader收到超过半数以上的Follower的ACK之后，认为可以发送commit
  （6）Leader向所有的Follower服务器发送Commit消息

这里有几个重要的地方可以看下
一个是follower提交ACK之前，其实已经将事务写好了，Leader最后通知只是通知Follower可以commit了
还有一个是Leader和各个Follower之间有一个消息队列，这样Leader和Follower之间可以实现异步通信，就不用因为同步通信阻塞Leader服务器了

• 崩溃恢复
  在Zookeeper中，最严重的就是Leader服务器崩溃，这样一来zab协议就要求zookeeper集群进行崩溃恢复和Leader服务器选举
  崩溃恢复要保证两个事，一个是崩溃的Leader服务器已经提交的proposal一定要被所有的Follower服务器提交，保证数据的一致性，另外一个是已经被Leader提出，但是没有提交的proposal被丢弃，这两个都是为了保证数据的一致性

所以新选举的Leader服务器必须是不能包含未提交的proposal，而且已经提交了所有proposal的服务器节点，同时，必须包含最高的ZXID也就是经历了最新的额proposal，这样就可以根据Leader的状态直接进行数据同步和恢复。，关于ZXID我们在后面会讲到

ZAB协议的原理其实就是三个阶段：
第一个阶段选举出一个Leader，然后通过Leader来处理数据同步问题，
第二个阶段就是同步，Leader将本省的数据与Follower做到同步，做到多副本存储
第三个阶段就是广播，Leader可以接收客户端新的proposal请求或者Follower接收转发给Leader，Leader再将proposal广播给所有Follower

ZAB协议为Zookeeper建立高可用可拓展的分布式数据主备系统贡献了巨大的力量，即任何时刻Leader发生宕机，都能保证分布式系统数据的可靠性和最终一致性，深入了解ZAB才能明白为什么Zookeeper可以保证数据一致性和服务的高可用性

5.4 Zookeeper的选举

如果上的都看明白了，那么Zookeeper的选举的重要性就不言而喻了，首先，在集群初始化的时候肯定要选举一个Leader出来，再者，在当前Leader崩溃的时候要选举一个Leader出来，并且在ZAB中我们也知道Leader的选举跟ZXID又不小的关系，所以初始化和崩溃的时候proposal的ZXID肯定是不一样的，所以两个阶段的选举也有所不同，当然不同很小，只是每个服务器ZXID的区别

1. 在选举阶段，能够参与投票的服务器会将Following状态调整为Looking，Looking状态的服务器才有资格投票。

2. 投票的时候，每个服务器都会有myid和ZXID的票，先会投给自己，然后他们会受到来自其他服务器的票

3. 每个服务器都会根据其他服务器的票，进行比较，先比较ZXID，ZXID大的获胜，因为这代表该服务器存有更新版本的proposal，如果ZXID相等，myid大的获胜，myid就是服务器的编号，服务器会不断更新自己票

4. 当有过半数机器持有相同的票时，统计票数，选出Leader

5. 服务器更改状态，Leader状态为Leading，Follower状态为Following，Observer状态为Observing

初始选举和崩溃时选举不同的地方其实就在于ZXID的不同，初始时大家的ZXID都为0，但是崩溃时就有所不同了。

5.5 Zookeeper的分布式锁

在Zookeeper的分布式系统下，实现分布式锁是非常重要的，一个共享资源去供来自不同系统的进程访问，要做到只有一把锁一个进程使用，就需要分布式锁来实现，Zookeeper的分布式锁是可重入的公平锁。

在Zookeeper中，会为每个来访问lock的进程创建一个临时顺序节点，并且按顺序给节点编号，每个节点只要看他的前一个节点是否释放了锁，就可以知道，什么时候轮到自己占用这个锁了。

看到这里，我们别忘了，Zookeeper在这篇文章我们是讲他为Kafka提供服务的，重点还是Kafka，那么回到开始的地方，我们说Kafka有高吞吐量，持久性，分布式的特点，持久性，分布式都是通过Zookeeper实现的，那么高吞吐量就肯定是另有方法了，高吞吐两室Kafka的重要特性，了解其中门道也很重要。

6.Kafka的高吞吐量

Kafka是基于磁盘进行存储的，不同于Redis的基于内存，我们都知道基于磁盘的性能一般都是慢与内存的，那么为什么Kafka还能如此高性能和高吞吐量呢？
这里随便写两个，详细的可以看看这篇文章

6.1 磁盘的顺序写入

磁盘的读写有两种方式，顺序读写或者随机读写，在顺序读写的情况下，磁盘的速度可以跟内存持平

6.2 页缓存

即便是顺序写入，磁盘的访问速度还是不可能跟上内存，所以Kafka的另外一个优化就在于用了现代操作系统的分页存储来利用内存提高I/O效率，把磁盘中的数据缓存到内存中，实现对磁盘的访问变成对内存的访问，所以Kafka的数据也不是实时写入硬盘。