专栏首页爬蜥的学习之旅初识kafka对消息处理与可靠性做出的保证

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 【RocketMq实战第四篇】不同类型消费者DefaultMQPushConsumerDefaultMQPullConsumer

    前言 生产者和消费者是消息队列的两个重要角色,生产者向消息队列写人数据, 消费者从消息队列里读取数据。本篇讲解两种类型的消费者,一个是 DefaultMQPus...

    胖虎
  • Kafka 服务器集群部署

    上篇文章 Kafka 工作机制 讲述了 Kafka 的各组件(包括配置中心、Broker、消息生产者和消费者)的作用,分区与复制的机制等。有了这些概念,本文以三...

    IT技术小咖
  • Kafka 客户端开发

    前两篇文章讲述了 Kafka 的 工作机制 和 服务器集群部署。至此,Kafka 服务器已就绪,本文分别以官方API、Spring、SpringBoot三种构建...

    IT技术小咖
  • ELK日志分析方案

    1.在微服务服务器上部署Logstash,作为Shipper的角色,对微服务日志文件数据进行数据采集,将采集到的数据输出到Redis消息队列。

    IT技术小咖
  • 【RocketMq实战第一篇】-RocketMq下载与安装

    Linux/Unix/Mac 64bit JDK 1.8+; Maven 3.2.x

    胖虎
  • 重构一时爽,构错火葬场

    我相信每个接受过老项目的程序员可能都吐槽过 “前人的代码都是屎”。一个已经有些年头的项目,几乎肯定可以看到——到处拷贝来拷贝去的代码,随处可见的拼写错误,头重脚...

    周三不加班
  • Kafka 工作机制

    Kafka 是 Apache 的子项目,是一个高性能跨语言的分布式发布/订阅消息队列系统(没有严格实现 JMS 规范的点对点模型,但可以实现其效果),在企业开发...

    IT技术小咖
  • Kafka 消息可靠性

    在 Kafka 工作机制 一文提及了 Kafka 消息的不可靠性。本文就 Kafka 消息的三种不可靠性(重复、丢失、乱序),分析它们出现的内部原因和解决办法。...

    IT技术小咖
  • 昨晚直播错过了?小编给你划重点!(附直播提问中奖名单)

    ? 导语:在大家的期待中,腾讯云TStack首席架构师 贺阮 和 美女产品经理 Kitty 昨晚做客他二哥技术直播间,为大家揭开了腾讯云TStack的神秘面纱...

    腾讯技术工程官方号
  • 干趴面试官系列 | 请你简述一下Kafka中的分区分配

    “请你简述一下Kafka中的分区分配”,当面试官问你这个问题的时候,你会怎么回答?其实,这道题目里面就暗藏汹涌,因为Kafka中的分区分配在多处出现,而这个问题...

    zhisheng

扫码关注云+社区

领取腾讯云代金券