kafka

Kafka系统的角色

• Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic
• topic： 可以理解为一个MQ消息队列的名字
• Partition：为了实现扩展性，一个非常大的topic可以分布到多个 broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息 都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体 （多个partition间）的顺序。也就是说，一个topic在集群中可以有多个partition，那么分区的策略是什么？(消息发送到哪个分区上，有两种基本的策略，一是采用Key Hash算法，一是采用Round Robin算法)

Kafka存储策略

1）kafka以topic来进行消息管理，每个topic包含多个partition，每个partition对应一个逻辑log，有多个segment组成。

2）每个segment中存储多条消息（见下图），消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。

3）每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。

4）发布者发到某个topic的消息会被均匀的分布到多个partition上（或根据用户指定的路由规则进行分布），broker收到发布消息往对应partition的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。

Kafka Design

目标

1) 高吞吐量来支持高容量的事件流处理

2) 支持从离线系统加载数据

3) 低延迟的消息系统

持久化

1) 依赖文件系统，持久化到本地

2) 数据持久化到log

关于顺序和分区

Kafka 是一个力求保持消息顺序性的消息队列，但不是完全保证，其保证的是 Partition 级别的顺序性，如下图，

此图是 Topic 的分区 log 的示意图，可见，每个分区上的 log 都是一个有序的队列，所以，Kafka 是分区级别有序的。如果，某个 Topic 只有一个分区，那么这个 Topic 下的消息就都是有序的。

分区是为了提升消息处理的吞吐率而产生的，将一个 Topic 中的消息分成几份，分别给不同的 Broker 处理。如下图，

此图中有2个 Broker，Server 1 和 Server 2，每个 Broker 上有2个分区，总共4个分区，P0 ~ P3；有2个 Consumer Group，Consumer Group A 有2个 Consumer，Consumer Group B 有4个 Consumer。Kafka 的实现是，在稳定的情况下，维持固定的连接，每个 Consumer 稳定的消费其中某几个分区的消息，以上图举例，Consumer Group A 中的 C1 稳定消费 P0、P3，C2 稳定消费 P1、P2。这样的连接分配可能会导致消息消费的不均匀分布，但好处是比较容易保证顺序性。

关于副本

副本是高可用 Kafka 集群的实现方式。假设集群中有3个 Broker，那么可以指定3个副本，这3个副本是对等的，对于某个 Topic 的分区来说，其中一个是 Leader，即主节点，另外2个副本是 Follower，即从节点，每个副本在一个 Broker 上。当 Leader 收到消息的时候，会将消息写一份到副本中，通常情况，只有 Leader 处于工作状态。在 Leader 发生故障宕机的时候，Follwer 会取代 Leader 继续传送消息，而不会发生消息丢失。Kafka 的副本是以分区为单位的，也就是说，即使是同一个 Topic，其不同分区的 Leader 节点也不同。甚至，Kafka 倾向于用不同的 Broker 来做分区的 Leader，因为这样能做到更好的负载均衡。

在副本间的消息同步，实际上是复制消息的 log，复制可以是同步复制，也可以是异步复制。同步复制是说，当 Leader 收到消息后，将消息写入从副本，只有在收到从副本写入成功的确认后才返回成功给 Producer；异步复制是说，Leader 将消息写入从副本，但是不等待从副本的成功确认，直接返回成功给 Producer。同步复制效率较低，但是消息不会丢；异步复制效率高，但是在 Broker 宕机的时候，可能会出现消息丢失。

关于丢消息和重复收到消息

任何一个 MQ 都需要处理丢消息和重复收到消息的，正常情况下，Kafka 可以保证：1. 不丢消息；2. 不重复发消息；3. 消息读且只读一次。当然这都是正常情况，极端情况，如 Broker 宕机，断电，这类情况下，Kafka 只能保证 1 或者 2，无法保证 3。

在有副本的情况下，Kafka 是可以保证消息不丢的，其前提是设置了同步复制，这也是 Kafka 的默认设置，但是可能出现重复发送消息，这个交给上层应用解决；在生产者中使用异步提交，可以保证不重复发送消息，但是有丢消息的可能，如果应用可以容忍，也可以接受。如果需要实现读且只读一次，就比较麻烦，需要更底层的 API