精华内容
下载资源
问答
  • kafka丢消息

    2019-02-26 15:52:26
    kafka丢消息主要集中在两个环节 消息落盘时机 消息落盘有异步刷新和同步刷新两种,明显异步刷新的可靠性要高很多。但在某些场景下追求性能而忽略可靠性,可以启用。 消息存储维护 持久化存储,这句话...

    kafka会丢消息主要集中在两个环节

    1. 消息落盘时机

    消息落盘有异步刷新和同步刷新两种,明显异步刷新的可靠性要高很多。但在某些场景下追求性能而忽略可靠性,可以启用。

    1. 消息存储维护

    持久化存储,这句话不是说来玩的。Oracle/MySQL做了这么久的存储,其中的灾难恢复工具等都非常完备并形成体系(出问题你能找到人并能解决问题)kafka的存储谁特么知道~工具又特么的少!

    另外就是落盘的存储介质,如果不做raid,那么单盘存在损坏的可能;做了raid,则成本上升。如果做多集copy,则存在网络同步延时所带来的瞬间数据不一致。

    小结:kafka你要做到完全不丢数据(在非大灾大难的情况下,比如机房被原子弹轰炸;或者raid被误操作弄错同步时间或者低格等),是完全可以的。代价就是丢失一定的性能。

    所以kafka我一般用在业务允许少量数据丢失但整体吞吐量非常大的场景(比如日志采集),数据统计分析(却少几百条数据不会对亿万级的样本空间产生什么影响)。

    kafka也可以用在两个可靠存储之间做数据同步,比如MySQL(写)->MySQL(度),因为MySQL(写)保证了数据可被重放,所以kafka出问题时恢复速度和恢复可靠程度是可以得到保证的

     

    kafka环节丢失数据,常见的kafka环节丢失数据的原因有:

    1. 如果auto.commit.enable=true,当consumer fetch了一些数据但还没有完全处理掉的时候,刚好到commit interval出发了提交offset操作,接着consumer crash掉了。这时已经fetch的数据还没有处理完成但已经被commit掉,因此没有机会再次被处理,数据丢失。

    2. 网络负载很高或者磁盘很忙写入失败的情况下,没有自动重试重发消息。没有做限速处理,超出了网络带宽限速。kafka一定要配置上消息重试的机制,并且重试的时间间隔一定要长一些,默认1秒钟并不符合生产环境(网络中断时间有可能超过1秒)。

    3. 如果磁盘坏了,会丢失已经落盘的数据

    4. 单批数据的长度超过限制会丢失数据,报kafka.common.MessageSizeTooLargeException异常
      解决:

      Consumer side:fetch.message.max.bytes- this will determine the largest size of a message that can be fetched by the consumer.
      
      Broker side:replica.fetch.max.bytes- this will allow for the replicas in the brokers to send messages within the cluster and make sure the messages are replicated correctly. If this is too small, then the message will never be replicated, and therefore, the consumer will never see the message because the message will never be committed (fully replicated).
      
      Broker side:message.max.bytes- this is the largest size of the message that can be received by the broker from a producer.
      
      Broker side (per topic):max.message.bytes- this is the largest size of the message the broker will allow to be appended to the topic. This size is validated pre-compression. (Defaults to broker'smessage.max.bytes.)
      
    5. partition leader在未完成副本数follows的备份时就宕机的情况,即使选举出了新的leader但是已经push的数据因为未备份就丢失了!
      kafka是多副本的,当你配置了同步复制之后。多个副本的数据都在PageCache里面,出现多个副本同时挂掉的概率比1个副本挂掉的概率就很小了。(官方推荐是通过副本来保证数据的完整性的)

    6. kafka的数据一开始就是存储在PageCache上的,定期flush到磁盘上的,也就是说,不是每个消息都被存储在磁盘了,如果出现断电或者机器故障等,PageCache上的数据就丢失了。
      可以通过log.flush.interval.messages和log.flush.interval.ms来配置flush间隔,interval大丢的数据多些,小会影响性能但在0.8版本,可以通过replica机制保证数据不丢,代价就是需要更多资源,尤其是磁盘资源,kafka当前支持GZip和Snappy压缩,来缓解这个问题 是否使用replica取决于在可靠性和资源代价之间的balance

     

    消息发送方式

    想清楚Kafka发送的消息是否丢失,需要先了解Kafka消息的发送方式。

    Kafka消息发送分同步(sync)、异步(async)两种方式

    默认是使用同步方式,可通过producer.type属性进行配置;

    Kafka保证消息被安全生产,有三个选项分别是0,1,-1

    通过request.required.acks属性进行配置:

    0代表:不进行消息接收是否成功的确认(默认值);

    1代表:当Leader副本接收成功后,返回接收成功确认信息;

    -1代表:当Leader和Follower副本都接收成功后,返回接收成功确认信息;

    六种发送场景

    两个维度相交,生成六种情况,如下图:

     

    消息丢失的场景

    网络异常

    acks设置为0时,不和Kafka集群进行消息接受确认,当网络发生异常等情况时,存在消息丢失的可能;

    客户端异常

    异步发送时,消息并没有直接发送至Kafka集群,而是在Client端按一定规则缓存并批量发送。在这期间,如果客户端发生死机等情况,都会导致消息的丢失;

    缓冲区满了

    异步发送时,Client端缓存的消息超出了缓冲池的大小,也存在消息丢失的可能;

    Leader副本异常

    acks设置为1时,Leader副本接收成功,Kafka集群就返回成功确认信息,而Follower副本可能还在同步。这时Leader副本突然出现异常,新Leader副本(原Follower副本)未能和其保持一致,就会出现消息丢失的情况;

    以上就是消息丢失的几种情况,在日常应用中,我们需要结合自身的应用场景来选择不同的配置。

    想要更高的吞吐量就设置:异步、ack=0;想要不丢失消息数据就选:同步、ack=-1策略

    附:Kafka备份策略,不理解的可以看我的另一篇文章《Kafka消息的备份策略》

    展开全文
  • Kafka 是一个分布式消息中间件,但是它并不符合JMS 规范,即使消息已经被消费,也不会被马上删除,当消息保留一定时间后,会被批量删除。 在Kafka 中,消息被持久化到磁盘上,因此Kafka 堆积消息的能力非常强大。 ...

    分布式消息中间件
    作用:

    1. 解耦(同步调用是一种强依赖,而异步调用是一种弱依赖);
    2. 削峰填谷;
    3. 降低响应时间;
    4. 提升吞吐量(Kafka 的吞吐量是MySQL 吞吐量的30-40倍,并且Kafka的扩展性远高于MySQL);

    Kafka 的设计原理
    Kafka 是一个分布式消息中间件,但是它并不符合JMS 规范,即使消息已经被消费,也不会被马上删除,当消息保留一定时间后,会被批量删除。
    在Kafka 中,消息被持久化到磁盘上,因此Kafka 堆积消息的能力非常强大。
    Kafka 依赖于 Zookeeper 管理元数据。

    Kafka 架构图
    在这里插入图片描述
    Broker
    Kafka的服务端,负责接收数据,并持久化数据,Broker 可以有多个,每个Broker 可以包含多个 Topic,Broker 并不保存 Offset(消费者消费的位置)数据,由 Consumer 自己负责保存,默认保存在 ZooKeeper 中。
    Producer 生产者
    生产数据发送到Broker 存储数据。Producer 直连 Broker,不经过任何代理,Producer 将会和 Topic 下所有 Partition Leader 保持 Socket 连接。通常 Producer 是一个包含 Kafka客户端的业务服务。
    Consumer 消费者
    业务服务从 Broker 订阅Topic,并从 Topic 中接收数据。
    每个消费者都属于某个消费者组,一个组里的消费者订阅的是同一个Topic,同一个组的消费者分别订阅同一个 Topic下的不同 Partition 的数据。
    需要注意的是,每个 Partition 只能被一个消费者订阅,一个消费者可以订阅多个 Partition,用这种方式避免一定的重复消费。
    当一个消费者挂掉之后,会重新进行负载均衡。

    Topic 主题
    相当于数据库找那个的表名,生产者和消费者之间通过 Topic 建立对应关系。
    Topic 更像一个逻辑概念,每个 Topic 下包含了多个 Partition,所有元数据都存储在 ZooKeeper 中。
    Partition 分区
    Kafka 为了扩展性,提升性能,可以将一个 Topic 拆分为多个分区,每个分区可以独立放到一个 Broker 中。
    ZooKeeper
    Kafka将元数据信息保存在Zookeeper中,但是发送给Topic本身的数据是不会发到ZooKeeper上。

    Kafka 使用Zookeeper来实现动态的集群扩展,不需要更改客户端(producer和consumer)的配置。Broker会在Zookeeper注册并保持相关的元数据(topic,partition信息等)更新。

    而客户端会在Zookeeper上注册相关的watcher。一旦zookeeper发生变化,客户端能及时感知并作出相应调整。这样就保证了添加或去除Broker时,各Broker间仍能自动实现负载均衡。

    这里的客户端指的是Kafka的消息生产端(Producer)和消息消费端(Consumer)。Producer端使用Zookeeper用来"发现"broker列表,以及和Topic下每个partition的Leader建立socket连接并发送消息。也就是说每个Topic的partition是由Leader角色的Broker端使用Zookeeper来注册Broker信息,以及监测partition leader存活性。Consumer端使用Zookeeper用来注册Consumer信息,其中包括Consumer 消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息。

    ZooKeeper 在Kafka 集群中承担的作用
    1)Zookeeper管理着Kafka集群中的若干个Broker,保存着一份完整的Broker列表。
    2)维护Topic信息,比如Partitions、Replication Factor、ISR(In-sync Replica)等。
    3)Zookeeper帮助选举Partition的Leader。
    4)当有任何变动时,由Zookeeper给Kafka发送通知,比如添加一个新的Topic、Broker挂掉了、删除Topic等等。
    5)Zookeeper集群中也有Leader和Follower的概念。Leader负责写数据,Follower负责读数据.
    6)存储Kafka集群ID。
    7)存储访问控制列表(ACL,Access Control List)。控制Topic、Consumer Group、User等访问权限
    在这里插入图片描述
    为什么 Kafka 性能高?
    1)顺序写磁盘,媲美内存随机访问的性能。
    2)顺序写磁盘的性能是随机写入的性能的6000倍的提升,磁盘不再是瓶颈点。
    3)零拷贝技术,减少上下文切换和拷贝次数。
    如何保证Kafka 不丢消息

    1. ACK 机制
      通过 ACK 机制保证消息送达。Kafka 采用的是至少一次(At least once),消息不会丢,但是可能会重复传输。
    2. 复制机制
      Kafka 保证可靠性依赖的是复制机制,因为单机容易出现故障。Kafka 以Topic 为单位进行设置复制因子,以 Partition 为单位进行复制,允许一份数据复制到集群中的多个节点上。通过复制,Kafka 在Broker 集群中的部分节点挂掉的情况下,仍然可以继续发送和接收消息。
      在这里插入图片描述
    3. 消息删除机制
      Broker 端删除消息有一个配置策略,默认是7天,如果7天消息还没有消费,则有可能被删除,也就是丢消息了。
    4. 发送消息
      为了得到更好的性能,Kafka 支持在生产者一侧进行本地buffer,也就是累积到一定的条数才发送,如果这里设置不当是会丢消息的。
      生产者端设置 producer.type=async, sync,默认是 sync。
      当设置为 async,会大幅提升性能,因为生产者会在本地缓冲消息,并适时批量发送。
      如果对可靠性要求高,那么这里可以设置为 sync 同步发送。
    5. 消费消息
      如果更注重可靠性,则需要显示提交 Offset,也就是当所有业务都处理完成的时候,再提交 Offset。这样会导致重复消费,需要提供幂等性接口。
    展开全文
  • kafka:发现kafka丢消息后的排查

    千次阅读 2018-10-05 14:13:26
     最近在用kafka消息中间件,producer从hive中读取消息发送到kafka,后端storm对消息分类发送到elasticsearch建立索引。 问题:  hive表中总共350万数据,当时整个全量索引结束后发现,最后索引条数总共310万...

    背景:

          最近在用kafka做消息中间件,producer从hive中读取消息发送到kafka,后端storm对消息分类发送到elasticsearch建立索引。

    问题:

          hive表中总共350万数据,当时整个全量索引结束后发现,最后索引条数总共310万左右。storm日志没有任何错误日志。

    排查:

          首先排查storm consumer的问题,由于发现storm日志没有任何异常,所以第一步基本排除建索引程序的问题。storm 消费kafka用的官方storm-kafka包,而且已开启ack,所以基本排除storm端的问题。

        现在怀疑kafka里的数据本身只有310万条数据,写了一个程序扔到了kafka集群上探查了一下,印证了自己的想法。果然,数据只有310万条。现在基本判断问题的在kafka producer上。仔细查看了下producer代码

    props.put("acks","all");

    props.put("retries",3);     

         "acks" 选项表示kafka 的ack级别:acks=0 意味着producer永远不会等待任何一个来自broker的ack,意味着不需要任何确实,发送及以为着成功。acks=1 意味着在leader replica已经接收到数据后,producer会得到一个ack,这个选项对速度与安全性做一个平衡,但是不需要等其他副本确认,如果发生leader挂了,其他副本还没来得及同步,这时就会发生数据丢失的情况。最后一种数据最安全的情况就是acks=al,l意味着在所有的ISR都接收到数据后,producer才得到一个ack。这个选项提供了最好的持久性,只要还有一个replica存活,那么数据就不会丢失,但是相应的吞吐量会受到影响。本着对业务对数据可靠性的要求,我选择了最高的可靠级别,这点没毛病。

        "retries"选项大于0的值将使客户端重新发送任何数据,一旦这些数据发送失败,会间隔一段时间重试,这个值设置的就是重试间隔时间。初步怀疑这个值太小,如果磁盘卡顿,网络中断超过三秒,是否会丢数据。所以将这个参数调大到300。

         重新打包上传到storm集群重新跑了一回,数据还是丢了30多万。场面一度尴尬。。问题陷入了僵局。

    转机:

        现在的问题已经超过了我的认知,之前从来没出现过如此严重的丢数据的问题。在网上搜的资料大部分都看过。理论上可靠性可以通过副本解决,没有类似于我这个种问题。心想着如果不行,只能更改broker 从page cache同步到硬盘的频率了。鬼使神差下,我更改了下producer的压缩格式,从snappy改到gzip,这次kafka中的消息,竟然只少了2000。同样的参数,只改了下压缩格式。我又查看下了前两次用snapp格式,kafka里的消息数,发现了一个问题,两次用snappy的时候,kafka消息数竟然一模一样。如果不是玄学的问题,理论上如果丢消息,350万条,丢相同条数的信息概率简直太小了。

      现在问题似乎已经很清晰了,gzip压缩率要比snappy高,snappy优势在于压缩速度。压缩率高意味着单条数据要小。现在基本问题定位在单条数据大小的问题。但是为什么producer端没有异常日志呢。查看一下producer发送消息的源码:“Future send(ProducerRecord var1)” producer 发送消息后会发挥一个future,这种模式是异步发送方式,当broker返回异常信息时并不会抛出。,producer.send(producerRecord).get(),加上get(),将异步改同步,打包运行果然发送到30万条左右数据时就已经抛出异常

    kafka.common.MessageSizeTooLargeException

    解决:

      至此问题已经定位到,下一步解决问题,搜了下stackoverflow,参考下最高票回答:

    Consumer side:fetch.message.max.bytes- this will determine the largest size of a message that can be fetched by the consumer.

    Broker side:replica.fetch.max.bytes- this will allow for the replicas in the brokers to send messages within the cluster and make sure the messages are replicated correctly. If this is too small, then the message will never be replicated, and therefore, the consumer will never see the message because the message will never be committed (fully replicated).

    Broker side:message.max.bytes- this is the largest size of the message that can be received by the broker from a producer.

    Broker side (per topic):max.message.bytes- this is the largest size of the message the broker will allow to be appended to the topic. This size is validated pre-compression. (Defaults to broker'smessage.max.bytes.)

        已完美解决问题。



     

     Curtis李

    4楼 · 2018.06.07 22:03

    楼主有没有出现丢列数据的问题,我现在没有出现丢失行,但是发现一条数据里,某些列丢失了,一直没找到原因,是通过kettle发kafka

      回复

     

     一波酱油

    3楼 · 2017.11.27 10:09

    350w条丢了30万条,是因为其中30w条消息大小本身超过kafka server的限制了吧,后来通过调整压缩格式后压缩率更高,就2000超过系统限制。能得出这个结论?

      回复

     

    MoCuishle_15b7

     那我应该得到什么样的结论呢?

    2017.12.20 17:19  回复

     

    John1988

     我觉得楼主的思路没毛病。

    2018.02.26 16:39  回复

     添加新评论

     李俊_d984

    2楼 · 2017.07.20 16:30

    到底怎么解决的?能否写一下详细的步骤?仅仅贴一些英文描述,太不实用了

      回复

     

    鲁邦三世

     调整了broker端的消息大小啊

    原文参考:https://www.jianshu.com/p/ec93eb4f7733

    展开全文
  • 最近在用kafka消息中间件,producer从hive中读取消息发送到kafka,后端storm对消息分类发送到elasticsearch建立索引。 问题: hive表中总共350万数据,当时整个全量索引结束后发现,最后索引条数总共310万左右...

    背景:

          最近在用kafka做消息中间件,producer从hive中读取消息发送到kafka,后端storm对消息分类发送到elasticsearch建立索引。

    问题:

          hive表中总共350万数据,当时整个全量索引结束后发现,最后索引条数总共310万左右。storm日志没有任何错误日志。

    排查:

          首先排查storm consumer的问题,由于发现storm日志没有任何异常,所以第一步基本排除建索引程序的问题。storm 消费kafka用的官方storm-kafka包,而且已开启ack,所以基本排除storm端的问题。

        现在怀疑kafka里的数据本身只有310万条数据,写了一个程序扔到了kafka集群上探查了一下,印证了自己的想法。果然,数据只有310万条。现在基本判断问题的在kafka producer上。仔细查看了下producer代码

    props.put("acks","all");

    props.put("retries",3);     

         "acks" 选项表示kafka 的ack级别:acks=0 意味着producer永远不会等待任何一个来自broker的ack,意味着不需要任何确实,发送及以为着成功。acks=1 意味着在leader replica已经接收到数据后,producer会得到一个ack,这个选项对速度与安全性做一个平衡,但是不需要等其他副本确认,如果发生leader挂了,其他副本还没来得及同步,这时就会发生数据丢失的情况。最后一种数据最安全的情况就是acks=al,l意味着在所有的ISR都接收到数据后,producer才得到一个ack。这个选项提供了最好的持久性,只要还有一个replica存活,那么数据就不会丢失,但是相应的吞吐量会受到影响。本着对业务对数据可靠性的要求,我选择了最高的可靠级别,这点没毛病。

        "retries"选项大于0的值将使客户端重新发送任何数据,一旦这些数据发送失败,会间隔一段时间重试,这个值设置的就是重试间隔时间。初步怀疑这个值太小,如果磁盘卡顿,网络中断超过三秒,是否会丢数据。所以将这个参数调大到300。

         重新打包上传到storm集群重新跑了一回,数据还是丢了30多万。场面一度尴尬。。问题陷入了僵局。

    转机:

        现在的问题已经超过了我的认知,之前从来没出现过如此严重的丢数据的问题。在网上搜的资料大部分都看过。理论上可靠性可以通过副本解决,没有类似于我这个种问题。心想着如果不行,只能更改broker 从page cache同步到硬盘的频率了。鬼使神差下,我更改了下producer的压缩格式,从snappy改到gzip,这次kafka中的消息,竟然只少了2000。同样的参数,只改了下压缩格式。我又查看下了前两次用snapp格式,kafka里的消息数,发现了一个问题,两次用snappy的时候,kafka消息数竟然一模一样。如果不是玄学的问题,理论上如果丢消息,350万条,丢相同条数的信息概率简直太小了。

      现在问题似乎已经很清晰了,gzip压缩率要比snappy高,snappy优势在于压缩速度。压缩率高意味着单条数据要小。现在基本问题定位在单条数据大小的问题。但是为什么producer端没有异常日志呢。查看一下producer发送消息的源码:“Future send(ProducerRecord var1)” producer 发送消息后会发挥一个future,这种模式是异步发送方式,当broker返回异常信息时并不会抛出。,producer.send(producerRecord).get(),加上get(),将异步改同步,打包运行果然发送到30万条左右数据时就已经抛出异常

    kafka.common.MessageSizeTooLargeException

    解决:

      至此问题已经定位到,下一步解决问题,搜了下stackoverflow,参考下最高票回答:

    Consumer side:fetch.message.max.bytes- this will determine the largest size of a message that can be fetched by the consumer.

    Broker side:replica.fetch.max.bytes- this will allow for the replicas in the brokers to send messages within the cluster and make sure the messages are replicated correctly. If this is too small, then the message will never be replicated, and therefore, the consumer will never see the message because the message will never be committed (fully replicated).

    Broker side:message.max.bytes- this is the largest size of the message that can be received by the broker from a producer.

    Broker side (per topic):max.message.bytes- this is the largest size of the message the broker will allow to be appended to the topic. This size is validated pre-compression. (Defaults to broker'smessage.max.bytes.)



    作者:MoCuishle_15b7
    链接:https://www.jianshu.com/p/ec93eb4f7733
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    展开全文
  • 背景:最近在用kafka消息中间件,producer从hive中读取消息发送到kafka,后端storm对消息分类发送到elasticsearch建立索引。问题:hive表中总共350万数据,当时整个全量索引结束后发现,最后索引条数总共310万左右...
  • kafka 丢消息的处理

    2020-11-17 14:09:01
    转载ref:https://blog.dogchao.cn/?p=305 Kafka丢消息的处理 一个示意图 Kafka存在丢消息的问题,消息丢失会发生在Broker,Producer和Consumer三种。 Broker Broker丢失消息是由于Kafka本身的原因造成的,kafka...
  • kafka什么时候会丢消息

    千次阅读 2019-06-29 23:25:47
    kafka集群中的部分或全部broker挂了,导致consumer没有及时收到消息,这不属于丢消息。broker挂了,只要消息全部持久化到了硬盘上,重启broker集群之后,使消费者继续拉取消息,消息就没有丢失,仍然全量消费了。 ...
  • Kafka会不会丢消息

    2021-07-16 13:59:44
    本文来说下Kafka是否会丢消息的问题 文章目录概述 概述 大型互联网公司一般都会要求消息传递最大限度的不丢失,比如用户服务给代金券服务发送一个消息,如果消息丢失会造成用户未收到应得的代金券,最终用户会投诉...
  • 网上很多文章都有讲解Kafka是如何保证不丢失消息的,但是真正的不丢消息吗?特别是当我看到broker写消息是写入内存中,也就是操作系统页缓存中,我就在想,如果这个时候物理机重启,内存东西都没了,消息不久没有了...
  • Kafka存在丢消息的问题,消息丢失会发生在Broker,Producer和Consumer三种。 Broker Broker丢失消息是由于Kafka本身的原因造成的,kafka为了得到更高的性能和吞吐量,将数据异步批量的存储在磁盘中。消息的刷盘...
  • 消息队列kafka丢数据解决方案

    千次阅读 2018-12-27 20:11:06
    ACK=0:发出消息不进行确认;...1、Client端宕机或程序问题导致消息为发出,就报错了; 2、异步情况下,消息并非实时发出,而是积累到一定程度后发出,此时Client端出现问题导致积累的所有消息...
  • 大型互联网公司一般都会要求消息传递最大限度的不丢失,比如用户服务给代金券服务发送一个消息,如果消息丢失会造成用户未收到应得的代金券,最终用户会投诉。避免上面类似情况的发生,除了做好补偿...
  • Kafka 居然还会丢消息?

    2020-12-23 14:05:45
    Kafka存在丢消息的问题,消息丢失会发生在Broker,Producer和Consumer三种。 Broker Broker丢失消息是由于Kafka本身的原因造成的,kafka为了得到更高的性能和吞吐量,将数据异步批量的存储在磁盘中。消息的刷盘...
  • 1.为什么要使用 kafka为什么要使用消息队列? 缓冲和削峰:上游数据时有突发流量,下游可能扛不住,或者下游没有足够多的机器来保证冗余,kafka在中间可以起到一个缓冲的作用,把消息暂存在kafka中,下游服务就...
  • 1、kafka什么 一种高吞吐量的分布式、发布订阅消息系统,它可以处理消费者规模的,网站中的所有动作流数据,具有高性能、持久化、多副本备份、横向扩展能力…… 以时间复杂度 O(1) 的方式提供消息持久化能力,...
  • Kafka到底会不会丢消息
  • 来源:https://blog.dogchao.cn/?p=305Kafka存在丢消息的问题,消息丢失会发生在Broker,Producer和Consumer三种。图片BrokerBrok...
  • - 前言 -Kafka 存在丢消息的问题,消息丢失会发生在 Broker,Producer 和 Consumer 三种。- Broker -Broker丢失...
  • Kafka 数据问题

    2020-07-17 10:18:54
    Kafka是最初由Linkedin公司开发,是一个分布式、分区的、多副本的...以时间复杂度O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单
  • 大型互联网公司一般都会要求消息传递最大限度的不丢失,比如用户服务给代金券服务发送一个消息,如果消息丢失会造成用户未收到应得的代金券,最终用户会投诉。避免上面类似情况的发生,除了做好补偿...
  • Kafka存在丢消息的问题,消息丢失会发生在Broker,Producer和Consumer三种。Java面试宝典PDF完整版 Broker Broker丢失消息是由于Kafka本身的原因造成的,kafka为了得到更高的性能和吞吐量,将数据异步批量的存储在...
  • 前言:Kafka存在丢消息的问题,消息丢失会发生在Broker,Producer和Consumer三种。BrokerBroker丢失消息是由于Kafka本身的原因造成的,kafka为了得...
  • List<String> messages = consumer.poll(); consumer.commitOffset(); processMsg(messages);
  • Kafka消息模型

    2021-01-14 22:39:54
    Kafka消息模型 kafka采用的是标准的发布-订阅模型,主要用在异步、解耦的场景、流量控制(削峰填谷)的场景。 生产者和消费者 一个典型的发布订阅系统长这个样子,如图1所示。 图1 发布-订阅模型在发布 - 订阅...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 11,676
精华内容 4,670
关键字:

为什么kafka丢消息