作者：threedayman 恒生LIGHT云社区 接着上一讲 消息中间件之RabbitMQ初识，这笔我们来讲讲RabbitMQ中消息丢失的问题。已经怎样在核心业务中避免消息丢失。 血泪故事：商品购物流程中的发货环...
原创
2022-03-03 14:56:35
271阅读
kafka的解决方式1.消费者弄丢了数据 唯一可能导致消费者弄丢消息的情况是消费者自动提交了 offset消息，kafka认为你已经消费了这个消息，但是你刚刚处理的过程中，自己就挂掉了，那么这个消息就丢失了 那么大家都知道，kafka能够自己自动提交offset,那么只要关闭自动提交offset,在处理完之后自己手动提交offset,就可以保证数据不会丢...
原创
2019-10-08 09:44:26
88阅读
接上一讲，这篇我们来讲讲RabbitMQ中消息丢失的问题。已经怎样在核心业务中避免消息丢失。
原创
2021-06-10 16:23:21
448阅读
消息的可靠投递除了需要硬件，网络，消息中间件等的可靠保证外，还需要生产者，消费者来共同保证来完成。一条消息从生产者产生，到发送到交换机，并被投递到队列，并最终被消费者消费，这整个路径上，途径的每一个地方都要保证消息的可靠性。其实，官方文档Reliability Guide已经总结了消息系统安全的方方面面。网络方面可以使用心跳检测TCP连接：Detecting Dead TCP Connection
转载
2024-04-16 12:20:15
117阅读
1 问题分析:可靠性传输或者说理消息丢失的问题,这个是肯定的，用 MQ 有个基本原则，就是数据不能多一条，也不能少一条，不能多，就是前面说的重复消费和幂等性问题。不能少，就是说这数据别搞丢了。那这个问题你必须得考虑一下。如果说你这个是用 MQ 来传递非常核心的消息，比如说计费、扣费的一些消息，那必须确保这个 MQ 传递过程中绝对不会把计费消息给弄丢。2 面试题回答:数据的丢失问题，可能出现在生产者
原创
2021-01-01 15:32:39
586阅读
定义普通队列和死信队列，并设置死信交换器。// 创建普通交换器和队列 channel . exchangeDeclare(EXCHANGE_NAME , BuiltinExchan
本文来自网易云社区 作者：田宏增 Kafka的高可靠性的保障来源于其健壮的副本（replication）策略。通过调节其副本相关参数，可以使得Kafka在性能和可靠性之间运转的游刃有余。Kafka从0.8.x版本开始提供partition级别的复制,replication的数量可以在$KAFKA_H
转载
2018-09-28 10:41:00
163阅读
2评论
本文来自网易云社区 作者：田宏增 Kafka的高可靠性的保障来源于其健壮的副本（replication）策略。通过调节其副本相关参数，可以使得Kafka在性能和可靠性之间运转的游刃有余。Kafka从0.8.x版本开始提供partition级别的复制,replication的数量可以在$KAFKA_H
转载
2018-09-28 10:40:00
257阅读
2评论
UDP网络协议
原创
2021-11-05 17:43:36
858阅读
# Redis消息队列的可靠性
在实时数据处理和系统架构中，消息队列是一个非常重要的组件，它可以帮助解耦系统各个模块之间的耦合性，提高系统的可靠性和性能。在消息队列中，Redis作为一个高性能的内存数据库，被广泛应用于实现消息队列。
## Redis消息队列的可靠性
Redis本身提供了一些数据结构，如List、Pub/Sub和Stream，可以用来实现消息队列。但是，这些原生的数据结构并不
原创
2024-05-21 07:22:28
110阅读
1.JMS消息确认机制
JMS消息只有在被确认之后，才认为已经被成功地消费了。消息的成功消费通常包含三个阶段：客户接收消息、客户处理消息和消息被确认。在事务性会话中，当一个事务被提交的时候，确认自动发生。在非事务性会话中，消息何时被确认取决于创建会话时的应答模式（acknowledgement mode）。该参数有以下三个可选值：
Sess
原创
2013-01-15 14:47:39
4871阅读
1.RabbitMQ的消息可靠性投递讲解 什么是消息的可靠性投递 保证消息百分百发送到消息队列中去 详细流程 保证mq节点成功接收消息 消息发送端需要接收到mq服务端接收到消息的确认应答 完善的消息补偿机制，发送失败的消息可以再感知并二次处理 RabbitMQ消息投递路径 生产者-->交换机-->队 ...
转载
2021-08-26 17:55:00
551阅读
2评论
一、可靠性问题分析 消息的可靠性投递是使用消息中间件不可避免的问题，不管是使用哪种MQ都存在这种问题，接下来要说的就是在RabbitMQ中如何解决可靠性问题；在前面 在前面说过消息的传递过程中有三个对象参与分别是：生产者、RabbitMQ(broker)、消费者；接下来就是要围绕这三个对象来分析消息 ...
转载
2021-10-15 17:20:00
111阅读
2评论
缘起在项目中使用RabbitMQ时，我们可能会遇到这样的问题:如一个订单系统当用户付款成功时我们往消息中间件添加一条记录期望消息消费者修改订单状态，但是最终实际订单状态并没有被修改成功。遇到这种问题我们排查的思路如下:
原创
2022-02-15 14:01:51
230阅读
消息传输在两个环节上进行：第一个环节是生产者发送消息到队列；第二个环节是消费者从队列获得消息。因此，在下面的三个阶段可能会使消息
原创
2024-09-02 10:40:20
72阅读
缘起在项目中使用RabbitMQ时，我们可能会遇到这样的问题:如一个订单系统当用户付款成功时我们往消息中间件添加一条记录期望消息消费者修改订单状态，但是最终实际订单状态并没有被修改成功。遇到这种问题我们排查的思路如下:1.消息是否已经成功发送到消息中间件2.消息是否有丢失的情况 消息是否已经被消费成功在生产环境下是不容许出现消息投递/消费错误的情况的，因为这可能会对企业产生巨大的损失，本...
原创
2021-08-26 15:19:14
489阅读
项目开发中经常会使用消息队列来完成异步处理、应用解耦、流量控制等功能。虽然消息队列的出现解决了一些场景下的问题，但是同时也引出了一些问题，其中使用消息队列时如何保证消息的可靠性就是一个常见的问题。如果在项目中遇到需要保证消息一定被消费的场景时，如何保证消息不丢失，如何保证消息的可靠性？ 最近在项目使
原创
2023-10-27 14:25:34
0阅读
本章目标 掌握生产者确认（Publisher Confirms）机制，确保消息到达Broker。 深入理解消费者确认（Consumer Acknowledgments）的最佳实践。 学习死信队列（Dead Letter Exchange, DLX）处理失败消息。 实现完整的消息可靠性保障体系。 一、 ...
1，基于session实现1.1 流程图1.1 pom<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>
转载
2024-10-15 10:28:09
29阅读
一般的消息中间件（MQ）只能保证消息不丢，但是不能保证重复发送等问题。
原创
2021-07-12 17:04:50
738阅读
