Kakfa架构解析——初步

一、基础架构

• Producer ：消息生产者，也就是向kafka broker发送消息的客户端
• Consumer ：消息消费者，也就是向kafka broker拉取消息的客户端
• Consumer Group ：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
• Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic
• Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic
• Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker上，一个topic可以分为多个partition，每个partition是一个有序的队列
• Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower
• leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader
• follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的leader

二、深入了解

上面说到：Kafka中消息是以topic进行分类的，Producer 和Consumer都是面向topic的。(topic是逻辑上的概念，而partition是物理上的概念)

• 每个partition对应于一个log文件，该log文件中存储的就是producer生产的数据。这些数据会以追加的方式写入log文件的末端，且都有其对应的offset。consumer会实施记录自己消费数据对应的offset以便恢复。
  
  当数据过多时，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制。
  如上图，每个partition分为多个segment，每个segment对应 log 和 index 文件。这两个文件位于一个文件夹下(命名规则为:topic名称+分区序号)

• “.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中message的物理偏移地址。

2.1 Producer

2.1.1 分区

1. 原因：
   ①方便在集群中扩展(每个Partition可以通过调整以适应它所在的机器，因此整个集群就可以适应任意大小的数据了)
   ②可以提高并发(可以以Partition为单位读写了)
2. 原则：我们需要将producer发送的数据封装成一个ProducerRecord对象。
   ①指明 partition 的情况下，直接将指明的值直接作为 partiton 值
   ②没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值
   ③既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition 值，也就是常说的 round-robin 算法

2.1.2 数据可靠性保证

为保证producer发送的数据，能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要向producer发送ack（acknowledgement确认收到），如果producer收到ack，就会进行下一轮的发送，否则重新发送数据。

• 对于副本数据同步，Kafka采用了全部完成同步才发送ack。

那么，如果某个follower因为故障迟迟不能与leader进行同步，该如何解决？

• Leader维护了一个动态的in-sync replica set (ISR)，也就是一个动态的follower集合。
• 当ISR中的follower完成数据的同步之后，leader就会给producer发送ack。
• 如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。
• Leader发生故障之后，就会从ISR中选举新的leader。

ack应答机制三种级别

• 0：producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据
• 1：producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据
• -1（all）：producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复

故障处理

• follower发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘记录的上次的HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。等该 follower 的 LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了
• leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据
  此时，只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复

2.1.3 Exactly Once

上面说过ACK的三种级别。其中设置为-1，可以保证Producer到Server之间不会丢失数据，即At Least Once语义；设置为0，可以保证生产者每条消息只会被发送一次，即At Most Once语义。

At Least Once可以保证数据不丢失，但是不能保证数据不重复；相对的，At Least Once可以保证数据不重复，但是不能保证数据不丢失。

0.11版本的Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指Producer不论向Server发送多少次重复数据，Server端都只会持久化一条。也就能达到Exactly Once语义。(幂等性无法保证跨分区跨会话的Exactly Once)

2.2 Consumer

2.2.1 消费方式

consumer采用pull（拉）模式从broker中读取数据。

pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka的消费者在消费数据时会传入一个时长参数timeout，如果当前没有数据可供消费，consumer会等待一段时间之后再返回，这段时长即为timeout。

2.2.3 offset的维护

由于consumer在消费过程中可能会出现断电宕机等故障，consumer恢复后，需要从故障前的位置的继续消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。

从0.9版本开始，consumer默认将offset保存在Kafka一个内置的topic中，该topic为__consumer_offsets。

2.3 Kafka高效读写

• 顺序写磁盘

• 应用Pagecache

  Kafka数据持久化是直接持久化到Pagecache中，这样会产生以下几个好处：

   I/O Scheduler 会将连续的小块写组装成大块的物理写从而提高性能
   I/O Scheduler 会尝试将一些写操作重新按顺序排好，从而减少磁盘头的移动时间
   充分利用所有空闲内存（非 JVM 内存）。如果使用应用层 Cache（即 JVM 堆内存），会增加 GC 负担
   读操作可直接在 Page Cache 内进行。如果消费和生产速度相当，甚至不需要通过物理磁盘（直接通过 Page Cache）交换数据
   如果进程重启，JVM 内的 Cache 会失效，但 Page Cache 仍然可用

• 零复制技术
  数据直接在内核完成输入和输出，不需要拷贝到用户空间再写出去。
  kafka数据写入磁盘前，数据先写到进程的内存空间。