浅谈Kafka

一、基本概念

1、Kafka里面消息的保存策略

不同于其它消息队列，消息不是消费完就被销毁，而是通过指定的保存期限，在期限到来之前，消息是一直存在的；在期限到达，消息才会被销毁。

2、leader的选择

在Kafka中，不是以服务器broker为单位划分leader、follower，而是以副本（replication）为单位划分leader、follower。这样集群中每个服务器broker都可以持有一部分leader和一部分follower，从而达到将写入的压力分摊到不同的broker中，即利用分布式分摊写压力，提升性能。

3、关于消费者

1）消费者自己维护自己的消费情况，即维护的是消息在日志中的位置（offset），该值随着该消费者的读取不断累加。

2）两种消费模式：

发布订阅模式，一个消息可以被多个消费者读取到，消费者之间互不影响，达到一种共享数据的效果；

队列模式：一条消息只能被一个消费者读取，达到多个消费者之间竞争消息的效果。

3）消费者组：多个消费者可以组成一个组，在消费者组里消息是竞争的，即队列模式；在消费者组之间消息是共享的，即发布订阅模式。

3、存储策略

从物理结构上看，Kafka中的分区（partition）是一个存储目录下（可配置）的一个文件夹，文件夹的名称是主题名-分区编号（从0开始）；

在分区中，存在segment的概念，一个segment是一个.log文件和一个.index文件组成，其中.log文件存放数据，.index文件存放对应.log的索引信息，每个segment的文件名为上一个segment文件中最后一条消息的offset值。

扩展：读取分区中的消息时，先根据offset和当前分区的segment的名称作比较，确定出在哪个segment中；查找该segment的.index文件，确定消息在.log中的开始位置，从此位置开始读取文件。

二、可靠性保障

0、分布式下两种消息写入成功的条件

1）leader独裁：只要leader中写入消息成功，就说明消息写入成功。

    弊端：当leader宕机后，若follower没有同步，导致消息的丢失。

2）follower民主制：只有所有的follower都成功写入，才说明消息写入成功。

    弊端：当有一个follower宕机后，导致leader收不全所有follower的确认，导致消息无法写入成功。

1、AR、ISR、OSR

AR：包含所有分区的副本编号，即AR=ISR+OSR；

ISR：同步列表，在其中的副本都同步了leader的消息，才算消息写入成功；

OSR：非同步列表，消息的数量大于等于ISR中副本中的消息数量。

默认副本全在ISR中，在写入消息时，当ISR中的某个副本同步消息的时间大于指定的阈值，则被移入OSR列表中。

2、LEO、HW

LEO（LogEndOffset）：leader中最新消息的offset，即使还未被ISR中的follower同步；

HW（HighWatermark）:消费者可以消费的最新消息的offset，该值小于等于LEO指向的offset。

3、分区同步消息的流程（仔细看图，总结自己的说法)

4、分区同步消息时的截断机制

在leader宕机后，选出的新leader，所有副本都会将消息截断到leader宕机之前的HW位置，从而保证了副本有着共同的消息，若是有消息已经被部分副本同步，此时会将多余的消息丢弃，这就是截断机制。

5、可靠性保证

1）消费消息时的可靠性：借助于LEO-HW机制保证消费者只能读取到HW之前的消息，从而当leader宕机后，可以从follower中读取到，保证了消费消息的可靠性；

弊端：ISR中只剩写一个leader时，leader宕机后的消息的消费。

2）生产消息的可靠性保证（关于可靠性保证可参考本人博客：理解分布式数据处理的三个级别）：

三种：

消息最多生产一次，可能会导致存储时消息丢失；

消息最少生产一次，不会丢失消息，但可能会导致存储时消息冗余；

消息存储时恰好一次

而在Kafka中，request.required.acks可以设定可靠性级别，分别是0（默认），1，-1

6、leader选举机制

在Kafka中，选举机制不同于ZooKeeper的过半选举，是通过ISR中的follower进行选举，但是当ISR中只有存在leader时，leader宕机，此时存在两种选举策略：

1）不允许OSR中的follower成为新的leader，这时只能等待原来的leader恢复，造成Kafka很长时间无法工作（unclean.leader.election.enable=false）；

评价：保证了数据的一致性，但是可用性低

2）允许OSR中的follower成为新的leader，但可能造成消息的丢失（unclean.leader.election.enable=true）。

评价：可用性高，一致性没有保证

建议：根据业务需求进行取舍

 

和ZooKeeper选举机制的比较：

ZooKeeper具有较高的可靠性，较低的可用性

Kafka具有较低的可靠性，较高的可用性