一，Kafka的架构

二，核心概念

2.1 分区策略

Kafka 有主题（Topic）的概念，它是承载真实数据的逻辑容器，而在主题之下还分为若干个分区，也就是说 Kafka 的消息组织方式实际上是三级结构：主题 - 分区 - 消息。主题下的每条消息只会保存在某一个分区中，而不会在多个分区中被保存多份。官网上的这张图非常清晰地展示了 Kafka 的三级结构，如下所示：

那么Kafka这么设计有什么好处呢？为什么使用分区的概念而不是直接使用多个主题呢？

其实分区的作用就是提供负载均衡的能力，或者说对数据进行分区的主要原因，就是为了实现系统的高伸缩性（Scalability）。不同的分区能够被放置到不同节点的机器上，而数据的读写操作也都是针对分区这个粒度而进行的，这样每个节点的机器都能独立地执行各自分区的读写请求处理。并且，我们还可以通过添加新的节点机器来增加整体系统的吞吐量。

分区策略是决定生产者将消息发送到哪个分区的算法。

•  指明 partition 的情况下，直接将指明的值直接作为 partition 值

•  没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值；

•  既没有 partition 值又没有 key 值的情况下， kafka 采用 Sticky Partition(黏性分区器)，会随机选择一个分区，并尽可能一直使用该分区，待该分区的 batch 已满或者过了间隔时间，kafka 再随机一个分区进行使用

2.2 生产者-偏移量（分区和副本）

1.Leader如果挂掉了，那么选择哪一个Follower当Leader？

如果leader挂掉了，剩余的follower会争抢成为leader，先到先得。

2.Leader数据没有完全同步到follower中，那么消费者如何消费？

这里就需要使用到偏移量。每一个分区都会有，LogStartOffset，LogEndOffset和HW。

LogStartOffset表示log开始的位置。 LogEndOffset（LEO）表示最后一个log的下一个位置。 HW表示生产者或消费者可用的log。

示例1：只有一个follower

初始状态 同步过程：follower先从leader中fetch B，follower的状态就是变成 LSO=0,LEO=2,HW=1,然后follower会将LEO=2，传递给leader，leader会比较自己的LEO和follower的LEO，因为相等，说明follower已经将B复制保存下来，然后leader会将HW变为2，表示B消息可用，再将Hw=2传递给follower，改变follower的HW。

示例2：多个follower

大体过程和只有一个follower是相同的，主要不同为，leader的HW修改，是取多个follower传递回来的LEO最小的一个；follower的HW是取leader传递过来的HW和自己的LEO最小的一个。

2.3 消费策略

消费策略谁来定？

消费者组中有一个管理者，称为Coordinator，主要用来管理消费者组。

Kafka会选择位移主题的Leader（Broker）作为Coordinator。Coordinator会将第一个加入的Consumer作为Leader，其他Consumer作为Follower，Leader来决定消费策略后，将策略上传到Coordinator，其他消费者在Join后，可以获取消费策略。

4个消费策略

1.范围策略（默认）

2.轮询策略

3.粘性策略

4.合作策略

二，Topics和Partition

Topic在逻辑上可以被认为是一个queue，每条消息都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。创建一个topic时，同时可以指定分区数目，分区数越多，其吞吐量也越大，但是需要的资源也越多，同时也会导致更高的不可用性，kafka在接收到生产者发送的消息之后，会根据均衡策略将消息存储到不同的分区中。因为每条消息都被append到该Partition中，属于顺序写磁盘，因此效率非常高。

对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。当然，因为磁盘限制，不可能永久保留所有数据（实际上也没必要），因此Kafka提供两种策略删除旧数据。一是基于时间，二是基于Partition文件大小。

三，Producer消息路由

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

在发送一条消息时，可以指定这条消息的key，Producer根据这个key和Partition机制来判断应该将这条消息发送到哪个Parition。Paritition机制可以通过指定Producer的paritition. class这一参数来指定，该class必须实现kafka.producer.Partitioner接口。

四，Consumer Group

使用Consumer high level API时，同一Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。

这是Kafka用来实现一个Topic消息的广播（发给所有的Consumer）和单播（发给某一个Consumer）的手段。一个Topic可以对应多个Consumer Group。如果需要实现广播，只要每个Consumer有一个独立的Group就可以了。要实现单播只要所有的Consumer在同一个Group里。用Consumer Group还可以将Consumer进行自由的分组而不需要多次发送消息到不同的Topic。

五，Push 和 Pull

pull（拉）模式就是消费者主动去消息队列拉取消息，push（推）模式消费者不需要主动，消息队列会自动将消息发送到消费者方。

作为一个消息系统，Kafka遵循了传统的方式，选择由Producer向broker push消息并由Consumer从broker pull消息。

push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成Consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据Consumer的消费能力以适当的速率消费消息。

对于Kafka而言，pull模式更合适。pull模式可简化broker的设计，Consumer可自主控制消费消息的速率，同时Consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

六，Kafka delivery gurarantee

有这么几种可能的delivery guarantee：

At most once 　　消息可能会丢，但绝不会重复传输

At least one 　　  消息绝不会丢，但可能会重复传输

Exactly once 　　 每条消息肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。

当Producer向broker发送消息时，一旦这条消息被commit，因数replication的存在，它就不会丢。但是如果Producer发送数据给broker后，遇到网络问题而造成通信中断，那Producer就无法判断该条消息是否已经commit。虽然Kafka无法确定网络故障期间发生了什么，但是Producer可以生成一种类似于主键的东西，发生故障时幂等性的重试多次，这样就做到了Exactly once。

接下来讨论的是消息从broker到Consumer的delivery guarantee语义。（仅针对Kafka consumer high level API）。Consumer在从broker读取消息后，可以选择commit，该操作会在Zookeeper中保存该Consumer在该Partition中读取的消息的offset。该Consumer下一次再读该Partition时会从下一条开始读取。如未commit，下一次读取的开始位置会跟上一次commit之后的开始位置相同。当然可以将Consumer设置为autocommit，即Consumer一旦读到数据立即自动commit。如果只讨论这一读取消息的过程，那Kafka是确保了Exactly once。但实际使用中应用程序并非在Consumer读取完数据就结束了，而是要进行进一步处理，而数据处理与commit的顺序在很大程度上决定了消息从broker和consumer的delivery guarantee semantic。

Kafka默认保证At least once，并且允许通过设置Producer异步提交来实现At most once。而Exactly once要求与外部存储系统协作，幸运的是Kafka提供的offset可以非常直接非常容易得使用这种方式。