初识kafka对消息处理与可靠性做出的保证

1. 保证分区消息的顺序。同一个生产者给同一个分区写消息一定是有序的

2. 所有的同步副本写入了消息时，才会被认为已经提交 3. 只要有一个副本是活跃的消息就不会丢失 4. 消费者只能提取已经提交的消息

broker对消息可靠性的处理

1. 复制系数。即一个消息应该有多少个副本（一般3个），这些副本在机架上如何分布，保证不会应为1个broker挂掉或者一个机架路由有问题而导致不可用。 2. 不完全首领选举。允许不同步的副本作为首领。坏处是对于同一个偏移量，不同步的副本作为首领之后，获取的是新数据，而原来的副本存储的是旧数据。

出现场景可能是

1. 假设3个副本，2个副本挂了，首领副本正常运行，这时候首领副本也挂了，随后启动了新的副本，数据不同步；

2. 3个副本中，首领副本正常，但是由于网络延迟跟随副本复制存在一定的延迟，如果首领副本挂了，其它副本都是不同步的

3. 最少同步副本。当分区同步副本数少于最少同步副本的时候，就停止接受生产者的消息，抛出异常。以避免不完全选举所产生的数据写入与读出预期不一致的情况

生产者对消息可靠性的处理

生产者对消息可靠性可以从两个方面引入。

• 首先是假设acks=1，但是一共有3个副本，假如首领副本这时候恰巧崩溃，而其他的副本会被认为是同步的，对生产者而言，这里丢失了一个消息；
• 其次是假设acks=all,即3个副本都是同步的才确认，如果恰好首领副本崩溃，在选举期间来的消息，生产者只会收到首领不可用的响应，需要生产者自己去处理消息。

因而需要考虑两个方面：

1. 是acks的设置，不过需要处理吞吐量和消息丢失的关系

ack越多丢失概率越小，但是吞吐量少，得等待收到所有的

2. 是生产者的重试机制，对于可重试的采用kafka内部的重试机制，不可重试的错误考虑保存到其它地方，后续进入.

重试带来的风险是消息重复

消费者对消息可靠性的处理

消费者的最大毛病在于万一提交了消息偏移量，但是却没有处理完，导致这段消息将永远不会被处理。所以最关键的地方在于如何处理消息偏移量。

• 自动偏移提交：保证只提交已经处理过的偏移量
• 手动偏移提交的策略:确保总是在处理往后再提交，确保提交不过于频繁不过与少，做适当的重试，确保需要一次性语义的场景能够满足

kafka的零拷贝是什么意思？

零拷贝依赖于操作系统。kafka中存在大量数据持久化道磁盘和磁盘文件通过网络发送。传统的方式来说，经历4次拷贝。首先系统将调用文件数据读到内存态Buffer,然后应用程序将内核态读入到用户态buffer,接着用户通过socket发送数据将用户态拷贝到内核态buffer,最后通过DMA拷贝将数据拷贝到NIC 【4次上下文切换】，在linux2.4+操作系统，sendfile系统调用通过零拷贝，数据从DMA拷贝到NIC Buffer,无需CPU拷贝

零拷贝来源，只有两次上下文切换

数据保留时长是多少？

每个主题可以配置保留时长或者大小。每个分区会有若干个片段，当前写入数据的片段（活跃片段），永远不会被删除，假如配置了保留5天的数据，那么会保留5天

默认1G或者一周，以小的为准，一个片段数据满了则关闭当前文件，打开新的，方便查找和删除

数据存储的文件格式？

储存格式与生产者发送，发送给消费者的格式一致。消息里不仅包含建和值，同时有大小，检验和，版本，压缩算法，时间戳

如何直接删除某个键？

应用程序发送一个相同的键，但是值为null的消息【称为墓碑消息】，进行常规清理时，只保留null消息，一段时间后，消费者消费时发现null的记录，知晓应该从数据库中删除，这段时间后，清理线程便清理掉墓碑消息

消费者如果离线了就干不掉了

kafka的compact策略？

适用场景：消息中存在一样的key,但是只需要保留最新的key的value。执行compact的时候，会早内存中构建一个map,key是消息键的hash，值是消息键的偏移量，读取一定量的污浊消息每个片段后，如果当前的消息key存在且偏移量小，值过期，或者是null,就抛弃，否则保存

向kafka塞入（读取）数据的方式？

1. 通过构建kafka客户端，进行读取或者写入。这种方式代码一般会被嵌入到应用程序

2. 使用Connect Api，面对的是市面上的存储系统，

Connect Api怎么处理与其它系统交互的？

connect api包含3个基本概念：worker进程，连接器，转换器

1. 连接器：她负责决定需要运行多少的任务，按照任务来拆分数据复制，从worker获取对应任务的配置并传递下去。而任务就负责将数据搬进和移出kafka,任务在初始化的时候会得到woker进程分配的源文件上下文，里面提供一些方法可以对数据进行清理，重试偏移量保存等等操作

2. worker进程：处理HTTP请求【定义连接器和连接器配置】、保存连接器的配置、启动连接器和连接器任务、将配置信息传递给任务、提交偏移量。总的来说，它负责配置管理、可靠性、高可用性、伸缩性和负载均衡

3. 数据转换：对于每种数据有自己的schema,源链接器通过转换器将数据保存到kafka,而目标连接器则使用worker指定的转换器转换成对应的格式