阅读 136

初识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指定的转换器转换成对应的格式