今天，树哥带大家聊聊消息丢失的问题。 可靠性级别 回到标题提出的问题：我们是否真的能保证 Kafka 消息不丢失？ 答案是：我们无法保证 Kafka 消息不丢失，只能保证某种程度下，消息不丢失。...在这种情况下，如果 Leader 分片所在服务器发生宕机，那么这些已经发送的数据会丢失。...随后，Kafka 服务端会根据不同设置参数，选择不同的刷盘过程，这里有两个参数控制着这个刷盘过程： # 数据达到多少条就将消息刷到磁盘 #log.flush.interval.messages=10000...与此同时，Kafka 服务器也会进行副本的复制，该 Partition 的 Follower 会从 Leader 节点拉取数据进行保存。...能不丢失吗？ 根据我们上面的分析，Kafka 只能做到 Kafka 应用崩溃这个级别，因为 Kafka 的 acks 仅仅表示写入了 PageCache。
我们使用 Kafka 的时候，怎样能保证不丢失消息呢？今天来聊一聊这个话题。...场景三：发送端重试 如果配置 retries=0，Producer 发送消息失败后是不会进行重试的，要保证消息不丢失，可以增加 retries 的配置值，避免因为网络抖动而造成的发送失败。...如果设置为 true，也是会丢失消息的，看下图： 如果 Leader 和 Follower1 都挂了，这时就要考虑是否让 Follower2 参加竞选，把 unclean.leader.election.enable...如下图： 所以，要保证消息不丢失，unclean.leader.election.enable 这个参数值要设置为 false。...所以，消费者并发消费很可能会造成消息丢失，如果对消息丢失很敏感，最好使用单线程来进行消费。
我们都知道Kafka的吞吐量很大，但是Kafka究竟会不会丢失消息呢？又会不会重复消费消息呢？...有很多公司因为业务要求必须保证消息不丢失、不重复的到达，比如无人机实时监控系统，当无人机闯入机场区域，我们必须立刻报警，不允许消息丢失。而无人机离开禁飞区域后我们需要将及时报警解除。...可能丢失 不会重复 至少一次（at least once）: 消息不会丢失，但可能被处理多次。 可能重复 不会丢失 精确传递一次（exactly once）: 消息被处理且只会被处理一次。...两次中有一次会丢失消息，或者有一次会重复，那么最终的结果就是可能丢失或者重复的。...但是这种吞吐量最高 all或者-1：leader broker会等消息写入 并且ISR都写入后 才会响应，这种只要ISR有副本存活就肯定不会丢失，但吞吐量最低。
需要提醒一下，生产环境中如果对消息的可靠性有十分高的要求（比如订单支付的消费消息），请使用专业的消息队列（例如：rmq，amq等），对消息的丢失有一定容忍度的程序完全可以使用redis，例如我们的日志收集程序...对于基于redis实现的消息队列，一般为可忍受部分消息丢失的业务，所以很多人选择丢弃消息的方案。另一种方案是基于redis单线程机制，可以增加消费者数量，这也是仅仅针对消息只被消费一次的场景。...但是消费者没有消息消费，会导致消费者进程一直在那里浪费cpu资源，而且还会把redis的QPS拉高。...但是sleep会有一个问题，会导致处理消息的延迟，例如sleep了一秒，那消息的延迟处理就有可能会延迟一秒，虽然在大部分场景下这都不是什么问题，但是作为程序员怎么能不追求极致和完美呢？...但是还要顺便一句，redis的连接在空闲一段时间后，服务端可能会主动断开，Blpop命令会抛出异常，所以还要做好了重试或者其他策略为好。 3.
消息中间件消息丢失问题，由于本人只用过rabbitmq和kafka，就这两种中间件简单说明一下 rabbitmq中间件 生产者消息丢失 这里生产者在发送的过程中,由于网络问题导致消息没有发送到mq,有两种解决办法...这⾥再次重发这条消息 } channel.txCommit 众所周知，开启事务是同步操作，会导致性能问题。...另外一种就是ack,开启confirm模式,发送的每一条消息都有一个唯一的表示id,当发送到rabbitmq成功之后，rabbitmq会返回一个ack消息，告诉消息正常发送了，如果rabbitmq没有接收到消息...中间件默认是自动ack机制,此时我们可以关闭自动ack的机制，等我消费完之后，再去ack我们的消息，这样就可以保证消息不丢失 kafka 消费者消息丢失 kafka消息丢失和rabbitmq丢失也是一样的...,kafka消费者丢失是因为消息会自动提交offset，因此我们可以照样关闭自动提交offset,在我处理完消息的时候，手动提交offset消息，这样就可以保证消息不丢失了 broker消息丢失 比较常见的场景就是
kafka消费者在消费的时候对于位移提交的具体时机的把握也很有讲究，有可能会造成重复消费和消息丢失的现象。...也就是说，x+5 至 x+7 之间的消息并未能被消费，如此便发生了消息丢失的现象。...但随之而来的是重复消费和消息丢失的问题。...按照一般思维逻辑而言，自动提交是延时提交，重复消费可以理解，那么消息丢失又是在什么情形下会发生的呢？ 结合上图中的情形。...重试会增加代码逻辑的复杂度，不重试会增加重复消费的概率。
kafka消费者在消费的时候对于位移提交的具体时机的把握也很有讲究，有可能会造成重复消费和消息丢失的现象。 ?...也就是说，x+5 至 x+7 之间的消息并未能被消费，如此便发生了消息丢失的现象。...但随之而来的是重复消费和消息丢失的问题。...按照一般思维逻辑而言，自动提交是延时提交，重复消费可以理解，那么消息丢失又是在什么情形下会发生的呢？ 结合上图中的情形。...重试会增加代码逻辑的复杂度，不重试会增加重复消费的概率。
消息积压 其实数据积压的问题是架构设计不合理。...丢失的数据是通过日志找回来,如果日志也找不到了 那就没招了 一般这时，只能操作临时紧急扩容了，具体操作步骤和思路如下： 先修复consumer，确保恢复消费速度，然后将现有cnosumer都停掉 新建一个...queue的数据 这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据 等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息...消息丢失 假设用rabbitmq，可设置TTL，积压超时后消息就没了，数据也就丢了。...可以采取批量重导，就是大量积压时，就直接丢弃数据，然后等高峰期后，比如半夜，将丢失的那批数据，写个程序查出来，然后重新灌入MQ，把白天丢的数据补回来。
腾讯云硬盘扩容怎么解决 想要给腾讯云硬盘扩容的话，第一步需要将相应的服务器关闭并做好数据的备份，避免在扩容的过程中导致数据丢失。...腾讯云硬盘扩容会导致数据丢失吗 在给腾讯云硬盘扩容的过程中，一般情况下都不会导致数据丢失的，不过为了数据安全的保险起见，大家在扩容之前最好能够把重要的数据备份，避免系统在扩容的过程中出现差错，导致重要的数据丢失...如果能够提前备份的话，即使数据丢失了也能够找回来，并不会耽误大家太多时间。 以上为大家简单介绍了腾讯云硬盘扩容怎么解决？...其实想要给腾讯云硬盘扩容是非常简单和方便的，中间也耗费不了多少时间，但是要注意一点，那就是在扩容之前最好先把重要的信息进行备份，这样才能避免在扩容的过程中出现数据丢失的情况。
消息丢失如何排查？...这个就不得不提到RocketMQ中的一个概念，「消息消费要满足订阅关系一致性，即一个consumerGroup中的所有消费者订阅的topic和tag必须保持一致，不然就会造成消息丢失」 如下图场景，发送了...因为msg-3被投递到q0，但是consumer1不消费tagb的消息导致消息被过滤，造成消息丢失 同理msg-2这条消息也会丢失 「注意，还有一个非常重要的点」 虽然消息消费失败了，但是消息的offset...，那肯定是consumer消费消息有问题，或者producer发送消息有问题 先根据时间段找到了消息，确保了发送没有问题，接着看消息的状态为NOT_CONSUME_YET，说明consumer在线但是没有消息...本地debug一波代码，果然是本地的producer会往所有的队列发送消息，并且consumer也会消费所有队列的消息 「至此找出问题了！」
我们已经知道发生消息丢失的原因大体上分为三个部分： 1.生产者发送消息到MQ这一过程导致消息丢失 2.MQ自己发生故障导致消息丢失 3.消费者拿到消息后，由于操作不当导致消息丢失 接下来我们就针对第一种情况...，聊一聊如何解决生产者发送消息过程中的消息丢失问题。...而积分系统是无法消费half状态的消息的。 订单系统发送了half消息后就会等待MQ给出成功的响应，如下图： ? 看到这里有些小伙伴可能会问，为什么要发送half消息呢？...因为half消息发送成功，表示MQ可以正常接收消息。 ? half消息写入成功，没有得到响应 那么假如half消息发送成功，但是没有得到MQ的成功响应，会怎么办呢？...如果成功了，那就重新发送commit消息给MQ，失败了，重新发送rollback消息给MQ。后文会介绍rollback和commit消息。
生产者的正确的消息发送方式 Kafka为生产者生产消息提供了一个 send(msg) 方法, 另有一个重载的方法send(msg, callback), send(msg) 该方法可以将一条消息发送出去...生产者的配置 当我们通过 send(msg, callback) 是不是就意味着消息一定不丢失了呢？...acks=1 当leader接受到消息就会直接给客户端返回成功， 一般情况下这种模式都能很好的保证数据的不丢失， 只有在laeder接受到数据， 然后还没来得及同步到follower...， 就挂掉了才会导致数据的丢失， 这种概率还是比较小的。...Broker 端的配置 其实到这里，生产者端基本已经做好了数据不丢失的大部分准备， 但是有些东西是要配合 Broker 端一起， 才能达到预期的不丢失数据的， 比如我们上面说到的 min.insync.replicas
RabbitMQ如何保证消息不丢失？...将 ack==false 的消息 持久化到数据库,定时扫描 DB 中投递失败的数据，重新投递到MQ中； /** * 生产者 确认消息的配置 * 此函数为回调函数,用于通知producer消息是否投递成功...* * @param correlationData 消息唯一ID * @param ack 确认消息是否被MQ 接收,true是已被接收,false反之 * @param...DB 所以定时任务扫描DB就可以了) 中投递失败的数据，重新投递到MQ中,这也是保证消息投递成功的一个手段) //TODO (但是 : 如果是需要顺序消费的话，这种重新投递的策略就显得不那么合适了...，我想的是某几个顺序消息拥有同一个会话ID 。。。
上篇写了掌握Rabbitmq几个重要概念，从一条消息说起，这篇来总结关于消息丢失让人头痛的事情。网络故障、服务器重启、硬盘损坏等都会导致消息的丢失。消息从生产到消费主要结果以下几个阶段如下图。...这三个阶段都有可能消息丢失，下面一一分析。...答案是：消息丢失。原因很简单：消息在内存中，没有刷盘，并且，他们默认是非持久化的，服务重启之后，它们需要重新创建，消息自然就丢失！..." + ev.DeliveryTag); }; 消费阶段 你可能会问，消费端消息怎么会丢失呢？...这里有性能的问题，消息持久化，是要刷到磁盘上的会影响投递速度，并且消息确认也会影响到消息投递速度。不基本上能够满足需求了。
如何让“消息丢失”？ 在“如何让消息丢失”之前，让我们梳理一下消息的生命周期，先对齐下整体的概念。...} } } 2、消息存储场景丢失消息 2.1 、Broker宕机或者磁盘损坏，Broker Server内存中的消息没有落盘 2.2 、过期清理机制引发消息丢失 Apache...消息丢失的根因是，一个队列在同一时间只会被分配给一个消费者，这样队列上不符合消息过滤规则的消息消费会被忽略，并且消息消费的进度会向前移动，从而造成消息丢失。...、存储、消费整个链路中都可以让消息“丢失”。...从全链路视角看，让消息丢失的漏洞百出。 那么，你“学会”让消息丢失的"技巧"了吗？
有的用户可能会问：这么庞大的数据，怎么保证数据不丢失呢？数据丢失了又该怎么办？...我们测试发现，在EasyCVR程序正在运行中时，如果按Ctrl+C强制退出，数据库中偶尔会有数据丢失，比如添加的设备和通道没有了。比较麻烦的做法就是将视频重新上传，但总要找到问题所在才能更好解决。...找到了原因，我们即刻纠正了这类错误，在往后的正式版本中，将不会有在用户的正常操作情况下而产生的数据丢失的情况。
在工作中，谈到有小数点的加减乘除都会想到用BigDecimal来解决，但是有很多人对于double或者float为啥会丢失精度一脸茫然。还有BigDecimal是怎么解决的？话不多说，我们开始。...double的问题是从小数点转换到二进制丢失精度，二进制丢失精度。BigDecimal在处理的时候把十进制小数扩大N倍让它在整数上进行计算，并保留相应的精度信息。
id，然后如果写入了rabbitmq之中，rabbitmq会给你回传一个ack消息，告诉你这个消息发送OK了；如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息失败了，你可以进行重试...消息就会丢失。...2）普通模式：消息只会存在与当前节点中，并不会同步到其他节点，当前节点宕机，有影响的业务会瘫痪，只能等待节点恢复重启可用（必须持久化消息情况下）。...下面自己画了一张图介绍普通集群丢失消息情况： 如果想解决上面途中问题，保证消息不丢失，需要采用HA 镜像模式队列。...通过以上的处理，理论上不存在消息丢失的情况，但是系统的吞吐量以及性能有所下降。 在实际开发中，需要考虑消息丢失的影响程度，来做出对可靠性以及性能之间的权衡。
围绕消息队列，今天的大数据开发学习分享，我们主要来聊聊，消息队列如何确保消息不丢失。 1、检测消息丢失的方法 可以利用消息队列的有序性来验证是否有消息丢失。...如果没有消息丢失，Consumer收到消息的序号必然是连续递增的，如果检测到序号不连续，那就是丢消息了。还可以通过缺失的序号来确定丢失的是哪条消息，方便进一步排查原因。...有些消息队列在长时间没收到发送确认响应后，会自动重试，如果重试再失败，就会以返回值或者异常的方式告知用户。...②存储阶段 在存储阶段正常情况下，只要Broker在正常运行，就不会出现丢失消息的问题，但是如果Broker出现了故障，比如进程死掉了或者服务器宕机了，还是可能会丢失消息的。...如果Broker没有收到消费确认响应，下次拉消息的时候还会返回同一条消息，确认消息不会在网络传输过程中丢失，也不会因为客户端在执行消费逻辑中出错导致丢失。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
