1 消息队列功能介绍消息队列是分布式系统中重要的组件，主要解决分布式环境下各个服务同步调用、负载不均、应用耦合等问题。 消息队列的作用就是可以让各个服务可以异步处理、流量削峰、应用解耦1.1 异步处理以电商用户下单为例，用户创建订单后发送订单创建成功的短信。传统方式可以做成串行处理，先调用订单服务创建订单，订单创建成功后调用短信服务发送短信。 假设创建订单100ms，发送短信100ms，那么整个过
转载
2024-03-21 16:12:05
35阅读
1.JMS消息确认机制
JMS消息只有在被确认之后，才认为已经被成功地消费了。消息的成功消费通常包含三个阶段：客户接收消息、客户处理消息和消息被确认。在事务性会话中，当一个事务被提交的时候，确认自动发生。在非事务性会话中，消息何时被确认取决于创建会话时的应答模式（acknowledgement mode）。该参数有以下三个可选值：
Sess
原创
2013-01-15 14:47:39
4871阅读
上面是我们可以手动设置消息的持久化方式，但如果是默认的话，情况是怎样的呢？这样得分两种情况，即Queue和Topic Quue的默认消息传递方式：持久化 Topic默认是非持久化的，不过它这个没有意义，因为我们说非持久的消息，无论是否mq有无宕机，它发的消息要是目前消费者在线才行，不然没有的话跟宕机
转载
2020-11-28 20:10:00
120阅读
2评论
持久化持久化可以在创建生产者之后再开启：messageProducer.setDeliveryMode(DeliveryMode.PERSISTENT);DeliveryNode的源码如下：package javax.jms;
public interface DeliveryMode {
//非持久化
static final int NON_PERSISTENT = 1;
//
转载
2024-04-17 17:21:58
48阅读
消息的签收(Acknowledgment): 客户端成功接收一条消息的标志是这条消息被签收。 成功接收一条消息一般包括如下三个阶段： (1) 客户端接收消息 (2) 客户端处理消息 (3) 消息被签收 签收可以由ActiveMQ发起，也可以由客户端发起，取决于Session签收模式的设置。 在带事务
转载
2019-01-30 10:34:00
182阅读
2评论
持久性（PERSISTENT）messageProducer.setDeliverMode(DeliverMode.NON_PERSISTENT); 非持久化：当服务器宕机，消息不存在messgageProducer.setDeliveryMode(DeliveryMode.PERSISTENT); 持久化：当服务器宕机，消息依然存在。队列（queue）的持久化：队列的默认为持久化模式，此模式保证
转载
2024-03-31 22:31:03
29阅读
项目开发中经常会使用消息队列来完成异步处理、应用解耦、流量控制等功能。虽然消息队列的出现解决了一些场景下的问题，但是同时也引出了一些问题，其中使用消息队列时如何保证消息的可靠性就是一个常见的问题。如果在项目中遇到需要保证消息一定被消费的场景时，如何保证消息不丢失，如何保证消息的可靠性？ 最近在项目使
原创
2023-10-27 14:25:34
0阅读
作者：threedayman 恒生LIGHT云社区 接着上一讲 消息中间件之RabbitMQ初识，这笔我们来讲讲RabbitMQ中消息丢失的问题。已经怎样在核心业务中避免消息丢失。 血泪故事：商品购物流程中的发货环...
原创
2022-03-03 14:56:35
271阅读
定义普通队列和死信队列，并设置死信交换器。// 创建普通交换器和队列 channel . exchangeDeclare(EXCHANGE_NAME , BuiltinExchan
本章目标 掌握生产者确认（Publisher Confirms）机制，确保消息到达Broker。 深入理解消费者确认（Consumer Acknowledgments）的最佳实践。 学习死信队列（Dead Letter Exchange, DLX）处理失败消息。 实现完整的消息可靠性保障体系。 一、 ...
本文来自网易云社区 作者：田宏增 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评论
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阅读
消息的可靠投递除了需要硬件，网络，消息中间件等的可靠保证外，还需要生产者，消费者来共同保证来完成。一条消息从生产者产生，到发送到交换机，并被投递到队列，并最终被消费者消费，这整个路径上，途径的每一个地方都要保证消息的可靠性。其实，官方文档Reliability Guide已经总结了消息系统安全的方方面面。网络方面可以使用心跳检测TCP连接：Detecting Dead TCP Connection
转载
2024-04-16 12:20:15
117阅读
一、消息接收确认JMS消息只有在被确认之后，才认为已经被成功地消费了。消息的成功消费通常包含三个阶段：客户接收消息、客户处理消息和消息被确认。事务相关 1、在事务性会话中，当一个事务被提交的时候，确认自动发生。 final Session session = connection.createSessi
原创
2017-04-11 15:41:53
976阅读
点赞
全文用到的生产者代码: 1.消息接收确认 JMS 消息只有在被确认之后，才认为已经被成功地消费了。消息的成功消费通常包含三个阶段：客户接收消息、客户处理消息和消息被确认。 (1) 在事务性会话中，事务被提交的时候，确认自动发生。也就是事务性回话需要进行session.commit()。如下消费者代码
原创
2021-07-15 10:25:34
230阅读
ActiveMQ高可靠性解决方案 ,ActiveMQ官方推荐“Shared storage”模式作为首选方案，并提供了多个优秀的存储策略，
原创
精选
2023-05-12 16:52:52
517阅读
kafka的解决方式1.消费者弄丢了数据 唯一可能导致消费者弄丢消息的情况是消费者自动提交了 offset消息，kafka认为你已经消费了这个消息，但是你刚刚处理的过程中，自己就挂掉了，那么这个消息就丢失了 那么大家都知道，kafka能够自己自动提交offset,那么只要关闭自动提交offset,在处理完之后自己手动提交offset,就可以保证数据不会丢...
原创
2019-10-08 09:44:26
88阅读
发送者的可靠性发送者重连有的时候由于网络波动，可能会出现发送者连接MQ失败的情况。通过配置我们可以开启连接失败后的重连机制:注意：当网络,稳定的时候，利用重试机制可以有效提高消息发送的成功率。不过SpringAMQP提供的重试机制是阻塞式的重试，也就是说多次重试等待的过程中，当前线程是被阻塞的，会影响业务性能。如果对于业务性能有要求，建议禁用重试机制。如果一定要使用，请合理配置等待时长和重试次数，
原创
精选
2024-07-19 15:45:07
611阅读
