概述
Kafka 是一个高吞吐量跨语言的分布式发布/订阅消息系统（没有严格实现 JMS 规范的点对点模型，但可以实现其效果），在企业开发中有广泛的应用。高性能是其最大优势，劣势是消息的可靠性（丢失或重复），这个劣势是为了换取高性能，开发者可以以稍降低性能，来换取消息的可靠性
基本架构
Producer：消息的产生者
Broker：kafka实例，每个服务器上可以有一个或多个kafka的实例，我们姑且认为每个broker对应一台服务器。每个kafka集群内的broker都有一个不重复的编号，如图中的broker-0、broker-1等……
kafka cluster：多个Broker组成的集群
Topic：消息的主题，可以理解为消息的分类，kafka的数据保存在topic。在每个broker上都可以创建多个topic。
Partition：Topic的分区，每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的，partition的表现形式就是一个个的文件夹
Replication:每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
Consumer：消息的消费方
Consumer Group：可以将多个消费者组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量
Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。
patition结构
每个topic都可以分为一个或多个partition。Partition在服务器上的表现形式就是一个个的文件夹，每个partition文件夹下面会有多组segment文件，每组segment文件又包含.index文件、.log文件、.timeindex文件（早期版本中没有）三个文件， log文件就实际是存储message的地方，而index和timeindex文件为索引文件，用于检索消息。
如上图，这个partition有三组segment文件，每个log文件的大小是一样的，但是存储的量。文件的命名以该segment最小offset来命名的，如000.index存储offset为0~368795的消息，kafka就是利用分段+索引的方式来解决查找效率的问题。
message结构
上面说到log文件就是存储message的地方，我们在producer往kafka写入的也是一条条的message，那存储在log中的message是什么样子的呢？消息主要包含消息体、消息大小、offset、压缩类型……等等！我们重点需要知道的是下面三个：
- offset：一个8byte的long型有序id号，可以唯一确定每条消息在parition内的位置
- kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行
随机读写 - kafka高性能的一个重要原因也在于此, 因为append log是顺序IO
- kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行
- 消息大小：占用4byte，用于描述消息的大小。
- 消息体：实际的消息数据（被压缩过）。
工作流程
发送数据
回看上面的架构图中的红色箭头，Producer在写入数据时永远找leader，不会直接将数据写入follower
需要注意的一点是，消息写入leader后，follower主动与leader进行同步。producer采用push模式将数据发布到broker，每条消息追加到分区中，顺序写入磁盘，所以保证同一分区内的数据有序
kafka为什么要分区？
- 方便扩展：topic可以有多个partition，可以通过扩展机器去轻松的应对日益增长的数据量。
- 提高并发：以partition为读写单位，可以多个消费者同时消费数据，提高了消息的处理效率。
如何负载均衡？
- partition在写入时可指定需要写入的partition，如果有指定，则写入对应的partition。
- 如果没有指定partition，但是设置了数据的key，则会根据key的值hash出一个partition。
- 如果既没指定partition，又没有设置key，则会轮询选出一个partition。
如何保证消息不丢失？
上面的写入流程图中有描述，通过ACK应答机制来保证。在生产者向队列写入数据时可以设置参数来确定是否确认kafka接收到数据，这个参数可设置的值为0、1、all。
- 0：producer往集群发送数据不需要等到集群的回应。安全性最低，效率最高。
- 1：producer往集群发送数据只要leader应答就可以发送下一条，只确保leader发送成功。
- all：producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条，确保leader发送成功和所有的副本都完成备份。安全性最高，但是效率最低。
能否往不存在的topic写数据？
kafka会自动创建topic，分区和副本的数量根据默认配置都是1。
保存数据
Producer将数据写入kafka后，集群就需要对数据进行保存。kafka会单独开辟一块磁盘空间，顺序写入数据（效率比随机写入高）。
存储策略
无论消息是否被消费，kafka都会保存所有的消息。那对于旧数据有什么删除策略呢？
- 基于时间，默认配置是168小时（7天）。
- 基于大小，默认配置是1073741824。
需要注意的是，kafka读取特定消息的时间复杂度是O(1)，所以这里删除过期的文件并不会提高kafka的性能
消费数据
消息存储在log文件后，消费者就可以进行消费了。在讲消息队列通信的两种模式时讲到过点对点模式和发布订阅模式。Kafka采用的是点对点的模式，消费者主动的去kafka集群拉取消息，与producer相同的是，消费者在拉取消息时也是找leader去拉取。
多个消费者可以组成一个消费者组，每个消费者组都有一个组id。同一个消费组的消费者可以消费同一topic下不同分区的数据，但是不会组内多个消费者消费同一分区的数据
图示是消费者组内的消费者小于partition数量的情况，所以会出现某个消费者消费多个partition数据的情况，消费的速度也就不及只处理一个partition的消费者的处理速度！如果消费者多于partition的数量，多出来的消费者不消费任何partition的数据。所以在实际的应用中，建议消费者组的consumer的数量与partition的数量一致
查找消息的时候是怎么利用segment+offset配合查找的呢？
假如现在需要查找一个offset为368801的message
- 先找到offset的368801message所在的segment文件（利用二分法查找），这里找到的就是在第二个segment文件。
- 打开找到的segment中的.index文件（368796.index文件，该文件起始偏移量为368796+1，我们要查找的offset为368801的message在该index内的偏移量为368796+5=368801，所以这里要查找的相对offset为5）。由于该文件采用的是稀疏索引的方式存储着相对offset及对应message物理偏移量的关系，所以直接找相对offset为5的索引找不到，这里同样利用二分法查找相对offset小于或者等于指定的相对offset的索引条目中最大的那个相对offset，所以找到的是相对offset为4的这个索引。
- 根据找到的相对offset为4的索引确定message存储的物理偏移位置为256。打开数据文件，从位置为256的那个地方开始顺序扫描直到找到offset为368801的那条Message。
这套机制是建立在offset为有序的基础上，利用segment+有序offset+稀疏索引+二分查找+顺序查找等多种手段来高效的查找数据
消费组与分区重平衡
当新的消费者加入消费组，它会消费一个或多个分区，而这些分区之前是由其他消费者负责的；另外，当消费者离开消费组（比如重启、宕机等）时，它所消费的分区会分配给其他分区。这种现象称为重平衡（rebalance） 。
重平衡是 Kafka 一个很重要的性质，这个性质保证了高可用和水平扩展。不过也需要注意到，在重平衡期间，所有消费者都不能消费消息，因此会造成整个消费组短暂的不可用。 而且，将分区进行重平衡也会导致原来的消费者状态过期，从而导致消费者需要重新更新状态，这段期间也会降低消费性能。
消费者通过定期发送心跳到一个作为组协调者的 broker 来保持在消费组内存活。这个 broker 不是固定的，每个消费组都可能不同。当消费者拉取消息或者提交时，便会发送心跳。
如果消费者超过一定时间没有发送心跳，那么它的会话就会过期，组协调者会认为该消费者已经宕机，然后触发重平衡。
在 0.10.1 版本，Kafka 对心跳机制进行了修改，将发送心跳与拉取消息进行分离，这样使得发送心跳的频率不受拉取的频率影响。另外更高版本的 Kafka 支持配置一个消费者多长时间不拉取消息但仍然保持存活，这个配置可以避免活锁（应用没有故障但是由于某些原因不能进一步消费）。
Partition 与消费模型
上面提到，Kafka 中一个 topic 中的消息是被打散分配在多个 Partition中存储的， 消费组在消费时需要从不同的 Partition 获取消息，那最终如何重建出 Topic 中消息的顺序呢？
答案是：没有办法。Kafka 只会保证在 Partition 内消息是有序的，而不管全局的情况。
下一个问题是：Partition 中的消息可以被不同的消费组多次消费，那 Partition中被消费的消息是何时删除的？ Partition 又是如何知道一个消费组当前消费的位置呢？
无论消息是否被消费，除非消息到期 Partition 从不删除消息。例如设置保留时间为 2 天，则消息发布 2 天内任何 Group 都可以消费，2 天后，消息自动被删除。
Partition 会为每个 Consumer Group 保存一个偏移量，记录 Group 消费到的位置。 如下图：
为什么 Kafka 是 pull 模型
消费者应该向 Broker 要数据（pull）还是 Broker 向消费者推送数据（push）？作为一个消息系统，Kafka 遵循了传统的方式，选择由 Producer 向 broker push 消息并由 Consumer 从 broker pull 消息。push 模式和 pull 模式各有优劣。
push 模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。 push 模式的目标是尽可能以最快速度传递消息，但是这样很容易造成 Consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 Consumer 的消费能力以适当的速率消费消息。
对于 Kafka 而言，pull 模式更合适。 pull 模式可简化 broker 的设计，Consumer 可自主控制消费消息的速率，同时 Consumer 可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。
kafka的可靠性
Kafka 的可靠性保证有如下四点：
- 对于一个分区来说，它的消息是有序的。如果一个生产者向一个分区先写入消息A，然后写入消息B，那么消费者会先读取消息A再读取消息B。
- 当消息写入所有in-sync状态的副本后，消息才会认为已提交 。这里的写入有可能只是写入到文件系统的缓存，不一定刷新到磁盘。生产者可以等待不同时机的确认，比如等待分区主副本写入即返回，后者等待所有in-sync状态副本写入才返回。
- 一旦消息已提交，那么只要有一个副本存活，数据不会丢失。
- 消费者只能读取到已提交的消息。
使用这些基础保证，我们构建一个可靠的系统，这时候需要考虑一个问题：究竟我们的应用需要多大程度的可靠性？可靠性不是无偿的，它与系统可用性、吞吐量、延迟和硬件价格息息相关，得此失彼。因此，我们往往需要做权衡，一味的追求可靠性并不实际。
