Kafka实现原理
一.kafka定义
Kafka是一款分布式消息发布和订阅系统，它的特点是高性能、高吞吐量。最早设计的目的是作为LinkedIn的活动流和运营数据的处理管道。这些数据主要是用来对用户做用户画像分析以及服务器性能数据的一些监控。所以kafka一开始设计的目标就是作为一个分布式、高吞吐量的消息系统，所以适合运用在大数据传输场景。kafka的简单定义：分布式的基于发布订阅的消息系统，它的特性如下：
- 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。
- 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。
- 支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。
- 同时支持离线数据处理和实时数据处理。
- Scale out：支持在线水平扩展。
二.kafka的应用场景
由于kafka具有更好的吞吐量、内置分区、冗余及容错性的优点(kafka每秒可以处理几十万消息)，让kafka成为了一个很好的大规模消息处理应用的解决方案。所以在企业级应用上，主要会应用于如下几个方面：
- 行为跟踪：kafka可以用于跟踪用户浏览页面、搜索及其他行为。通过发布-订阅模式实时记录到对应的topic中，通过后端大数据平台接入处理分析，并做更进一步的实时处理和监控。
- 日志收集：日志收集方面，有很多比较优秀的产品，比如Apache Flume，很多公司使用kafka代理日志聚合。日志聚合表示从服务器上收集日志文件，然后放到一个集中的平台（文件服务器）进行处理。在实际应用开发中，我们应用程序的log都会输出到本地的磁盘上，排查问题的话通过linux命令来搞定，如果应用程序组成了负载均衡集群，并且集群的机器有几十台以上，那么想通过日志快速定位到问题，就是很麻烦的事情了。所以一般都会做一个日志统一收集平台管理log日志用来快速查询重要应用的问题。所以很多公司的套路都是把应用日志集中到kafka上，然后分别导入到es和hdfs上，用来做实时检索分析和离线统计数据备份等。而另一方面，kafka本身又提供了很好的api来集成日志并且做日志收集。
2.1 为什么使用kafka？使用kafka会帮助解决哪些问题？
-
解耦：在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
-
冗余：有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
-
扩展性：因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
-
灵活性 & 峰值处理能力：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
-
可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
-
顺序保证：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。
-
缓冲：在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。
-
异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
2.2 各种Message Queue的对比
-
RabbitMQ：RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
-
Redis：Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
-
ZeroMQ：ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。
-
ActiveMQ：ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。
-
Kafka：Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。
三.kafka的架构
3.1 kafka依赖的Zookeeper
3.1.1 ZooKeeper中的各种角色
3.1.2 ZooKeeper节点数据操作流程
- 在Client向Follwer发出一个写的请求。
- Follwer把请求发送给Leader。
- Leader接收到以后开始发起投票并通知Follwer进行投票。
- Follwer把投票结果发送给Leader。
- Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit。
- Follwer把请求结果返回给Client。
选举流程：
3.1.3 watch机制
| 触发 |
事件类型 |
| create |
NodeCreated |
| setData |
NodeDataChanged |
| delete |
NodeDeleted |
| create |
NodeChildrenChanged |
| delete |
NodeChildrenChanged |
3.1.4 原子广播协议 -ZAB
- 广播模式-同步：
当 ZooKeeper 集群选举出 leader 同步完状态退出恢复模式之后，便进入了原子广播模式。 所有的写请求都被转发给 leader，再由 leader 将更新 proposal 广播给 follower 。
- 恢复模式-选主：
当服务启动或者在领导者崩溃后，ZAB 就进入了恢复模式，当领导者被选举出来，且大 多数 Server 完成了和 leader 的状态同步以后，恢复模式就结束 。
恢复模式-basic paxos实现：
1、选举线程由当前 Server 发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的 Server。
2、选举线程首先向所有 Server 发起一次询问(包括自己)。
3、选举线程收到回复后，验证是否是自己发起的询问(验证 zxid 是否一致)，然后获取对方 的 serverid(myid)，并存储到当前询问对象列表中，最后获取对方提议的 leader 相关信息 (serverid,zxid)，并将这些信息存储到当次选举的投票记录表中
4、收到所有 Server 回复以后，就计算出 id 最大的那个 Server，并将这个 Server 相关信息设 置成下一次要投票的 Server
5、线程将当前 id 最大的 Server 设置为当前 Server 要推荐的 Leader，如果此时获胜的 Server 获得 n/2 + 1 的 Server 票数， 设置当前推荐的 leader 为获胜的 Server，将根据获胜的 Server 相关信息设置自己的状态，否则，继续这个过程，直到 leader 被选举出来。
恢复模式-fast paxos实现：
3.2 kafka的相关概念
- Broker
Kafka集群包含一个或多个服务器，这种服务器被称为broker。 - Topic
Topic在逻辑上可以被认为是一个queue，每条消费都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。若创建topic1和topic2两个topic，且分别有13个和19个分区，则整个集群上会相应会生成共32个文件夹（本文所用集群共8个节点，此处topic1和topic2 replication-factor均为1）。 - Partition
Parition是物理上的概念，每个Topic包含一个或多个Partition。 - Producer
负责发布消息到Kafka broker。 - Consumer
消息消费者，向Kafka broker读取消息的客户端。 - Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
一个典型的kafka集群包含若干Producer（可以是应用节点产生的消息，也可以是通过Flume收集日志产生的事件），若干个Broker（kafka支持水平扩展）、若干个Consumer Group，以及一个zookeeper集群。kafka通过zookeeper管理集群配置及服务协同。Producer使用push模式将消息发布到broker，consumer通过监听使用pull模式从broker订阅并消费消息。多个broker协同工作，producer和consumer部署在各个业务逻辑中。三者通过zookeeper管理协调请求和转发。这样就组成了一个高性能的分布式消息发布和订阅系统。Kafka有一个细节是和其他mq中间件不同的点，producer 发送消息到broker的过程是push，而consumer从broker消费消息的过程是pull，主动去拉数据。而不是broker把数据主动发送给consumer。
Producer发送消息到broker时，会根据Paritition机制选择将其存储到哪一个Partition。如果Partition机制设置合理，所有消息可以均匀分布到不同的Partition里，这样就实现了负载均衡。如果一个Topic对应一个文件，那这个文件所在的机器I/O将会成为这个Topic的性能瓶颈，而有了Partition后，不同的消息可以并行写入不同broker的不同Partition里，极大的提高了吞吐率。可以在$KAFKA_HOME/config/server.properties中通过配置项num.partitions来指定新建Topic的默认Partition数量，也可在创建Topic时通过参数指定，同时也可以在Topic创建之后通过Kafka提供的工具修改。
3.3 kafka的数据存储和查找
每条消息都被append到该Partition中，属于顺序写磁盘，顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证。
通过索引定位到文件里，在通过偏移量找打存储的消息。
3.4 高吞吐使用技术
如果把消息以随机的方式写入到磁盘，那么磁盘首先要做的就是寻址，也就是定位到数据所在的物理地址，在磁盘上就要找到对应柱面、磁头以及对应的扇区；这个过程相对内存来说会消耗大量时间，为了规避随机读写带来的时间消耗，kafka采用顺序写的方式存储数据。即使是这样，但是频繁的I/O操作仍然会造成磁盘的性能瓶颈，所以kafka使用了页缓存和零拷贝技术。
当 一 个进程准备读取磁盘上的文件内容时， 操作系统会先查看待读取的数据是否在页缓存中，如果存在则直接返回数据， 从而避免了对物理磁盘的I/O操作；如果没有命中， 则操作系统会向磁盘发起读取请求并将读取的数据页存入页缓存， 之后再将数据返回给进程。一 个进程需要将数据写入磁盘， 那么操作系统也会检测数据对应的页是否在页缓存中，如果不存在， 则会先在页缓存中添加相应的页， 最后将数据写入对应的页。 被修改过后的页也就变成了脏页， 操作系统会在合适的时间把脏页中的数据写入磁盘， 以保持数据的 一 致性。Kafka中大量使用了页缓存， 这是Kafka实现高吞吐的重要因素之 一 。 虽然消息都是先被写入页缓存，然后由操作系统负责具体的刷盘任务的， 但在Kafka中同样提供了同步刷盘及间断性强制刷盘(fsync),可以通过 log.flush.interval.messages 和 log.flush.interval.ms 参数来控制。同步刷盘能够保证消息的可靠性，避免因为宕机导致页缓存数据还未完成同步时造成的数据丢失。但是实际使用上，我们没必要去考虑这样的因素以及这种问题带来的损失，消息可靠性可以由多副本来解决，同步刷盘会带来性能的影响。
3.4.1 Page Cache
写消息由堆转入Page Cache（物理内存），由异步线程刷盘，消息从Page Cache刷入磁盘；读消息直接从page Cache转入socket发送出去。
页缓存的好处：
-
I/O Scheduler会将连续的小块写组装成大块的物理写从而提高性能。
-
I/O Scheduler会尝试将一些写操作重新按顺序排好，从而减少磁头移动时间。
-
充分利用所有空闲内存（非JVM内存）。
-
读操作可以直接在Page Cache内进行。如果消费和生产速度相当，甚至不需要通过物理磁盘交换数据。
-
如果进程重启，JVM内的Cache会失效，但Page Cache仍然可用
3.4.2 零拷贝
传统的读取文件数据并发送到网络的步骤如下：
- 操作系统将数据从磁盘文件中读取到内核空间的页面缓存。
- 应用程序将数据从内核空间读入用户空间缓冲区。
- 应用程序将读到数据写回内核空间并放入socket缓冲区。
- 操作系统将数据从socket缓冲区复制到网卡接口，此时数据才能通过网络发送。
零拷贝技术读取文件数据并发送到网络的步骤如下：
- 将磁盘文件的数据复制到页面缓存。
- 将数据从页面缓存直接发送到网卡从而发到网络中。
3.4.3 其他
- 批量发送：Kafka允许进行批量发送消息，先将消息缓存在内存中，然后一次请求批量发送出去，这种策略将大大减少服务端的I/O次数。
- 数据压缩：Kafka还支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩，Producer压缩之后，在Consumer需进行解压，虽然增加了CPU的工作，但在对大数据处理上，瓶颈在网络上而不是CPU，所以这个成本很值得
3.5 高可用使用的技术
3.5.1 Replia（副本）
Kafka的每个topic都可以分为多个Partition，并且多个partition会均匀分布在集群的各个节点下。虽然这种方式能够有效的对数据进行分片，但是对于每个partition来说，都是单点的，当其中一个partition不可用的时候，那么这部分消息就没办法消费。所以kafka为了提高partition的可靠性而提供了副本的概念（Replica）,通过副本机制来实现冗余备份。
- replica与所备份的节点不能再一台机器上，否则就起不到备份的效果。
- replica尽量均匀的分布在集群机器上，如果replica全部都在某几台机器上，那么一旦这台机器挂了，会丢失多个partition的备份。
副本复制：
- 副本所在节点必须维持着与zookeeper的连接。
- 副本最后一条消息的offset与leader副本的最后一条消息的offset之间的差值不能超过指定的阈值，如果该follower在此时间间隔内一直没有追上过leader的所有消息，则该follower就会被剔除isr列表。
- ISR数据保存在Zookeeper的 /brokers/topics//partitions//state 节点中。
如何处理所有的Replia都不工作的情况：
在ISR中至少有一个follower时，Kafka可以确保已经commit的数据不丢失，但如果某个Partition的所有Replica都宕机了，就无法保证数据不丢失了。
- 等待ISR中的任一个Replica“活”过来，并且选它作为Leader。
- 选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader。
这就需要在可用性和一致性当中作出一个简单的折衷。如果一定要等待ISR中的Replica“活”过来，那不可用的时间就可能会相对较长。而且如果ISR中的所有Replica都无法“活”过来了，或者数据都丢失了，这个Partition将永远不可用。选择第一个“活”过来的Replica作为Leader，而这个Replica不是ISR中的Replica，那即使它并不保证已经包含了所有已commit的消息，它也会成为Leader而作为consumer的数据源（所有读写都由Leader完成）。
NoRespons 0 WaitForLocal 1 WaitForAll -1
副本同步原理：
- 先通过ZooKeeper找到该Partition的Leader get /brokers/topics//partitions/2/state ，然后无论该Topic的Replication Factor为多少（也即该Partition有多少个Replica），Producer只将该消息发送到该Partition的Leader。
- Leader会将该消息写入其本地Log。每个Follower都从Leader pull数据。这种方式上，Follower存储的数据顺序与Leader保持一致。
- Follower在收到该消息并写入其Log后，向Leader发送ACK。
- 一旦Leader收到了ISR中的所有Replica的ACK，该消息就被认为已经commit了，Leader将增加HW(HighWatermark)并且向Producer发送ACK。
3.5.2 Failover（故障恢复）
Leader副本的选举过程:
- KafkaController会监听ZooKeeper的/brokers/ids节点路径，一旦发现有broker挂了，执行下面的逻辑。这里暂时先不考虑KafkaController所在broker挂了的情况，KafkaController挂了，各个broker会重新leader选举出新的KafkaController
- leader副本在该broker上的分区就要重新进行leader选举，目前的选举策略是
a) 优先从isr列表中选出第一个作为leader副本，这个叫优先副本，理想情况下有限副本就是该分区的leader副本
b) 如果isr列表为空，则查看该topic的unclean.leader.election.enable配置。
unclean.leader.election.enable：为true则代表允许选用非isr列表的副本作为leader，那么此时就意味着数据可能丢失，为false的话，则表示不允许，直接抛出NoReplicaOnlineException异常，造成leader副本选举失败。
c) 如果上述配置为true，则从其他副本中选出一个作为leader副本，并且isr列表只包含该leader副本。一旦选举成功，则将选举后的leader和isr和其他副本信息写入到该分区的对应的zk路径上。
3.6 什么情况会丢失信息？
- acks=0、1：acks设置为1时，Leader副本接收成功，Kafka集群就返回成功确认信息，而Follower副本可能还在同步。这时Leader副本突然出现异常，新Leader副本(原Follower副本)未能和其保持一致，就会出现消息丢失的情况；异步、ack=0。
- acks=-1，但isr列表为空：所有的Replia都不工作，等待Replica唤醒期间的消息都会丢失。