基本结构
服务端：
- broker 存储数据，一个kafka实例节点代表一个 broker
- kafka connect 连接其它系统（包括其它kafka集群），从而导入导出事件流
- zookeeper zk集群用来存储kafka中broker和topic的信息
客户端：
https://cwiki.apache.org/confluence/display/KAFKA/Clients
基本概念对象
事件
包含键（可选），值，时间戳，元数据标头（可选），存储在主题的分区中
批次
kafka每次积攒事件，达到形成一个批次的条件后，按批次打包发送
生产者
将事件写入到服务端的客户端程序
消费者
从服务端获取事件的客户端程序
消费者组
多个消费者共用一个唯一标识组ID
主题
主题是存储事件的逻辑层。一个主题就如同一个管道，管道左边是多个生产者，管道右边是多个消费者。我们通过主题分类事件。
每个主题的事件存储周期，取决于配置。不管存储存多少，kafka的性能都是o(1)级别，也就是性能不会变。
主题散列在多个broker的多个buckets。
分区
每一个主题包含多个分区，分区会自动尽量平均的分散在多个broker上.
多分区允许客户端并发访问主题中的数据.
同一个主题下的相同key的事件将始终写入同一个分区【通过hash(key)来落点】。
同一个主题下的没有定义key的事件遵循两个分发策略：轮询策略和粘性策略。粘性策略性能更好。
ℹ️分区内事件读取的时候遵循先入先出原则。
ℹ️添加新分区不会导致现有分区的数据发生改变。
为了防止重复消费：
-
同一个分区里的事件同一时间不会被一个消费者组里的多个消费者消费。
-
同一个分区里的事件同一时间可以被多个消费者组里的一个消费者消费。
-
消费者消费完会触发位移提交，刷新主题下次消费的起始点。
副本因子
每一个分区有几个副本
节点存活
- 节点时刻与zk保持沟通。
- 追随节点的数据始终不会落后主节点太多。
满足上面两个条件的节点，状态标记为in sync，也就是存活中。
消息发送机制
当一个事件被分区所有副本写入后，kafka才会将事件发送给消费者。
rebalance机制
这个概念是针对消费者组，意思是消费者组将一个topic的所有分区尽可能的分发给所有消费者。
另外，消费者出现消费不完，或者没有发送心跳，都会被踢出消费者组，导致消费者组成员发生变化，从而引发rebalance。
在上述情况中，被踢出的消费者又因为无法执行提交位移，这会导致相当于没有消费，最终产生重复消费问题。