进击30K的专栏

正文回到顶部一、背景RocketMQ的分布式事务可以称为“半消息事务”。回到顶部二、原理2.1原理RocketMQ是靠半消息机制实现分布式事务：事务消息：MQ 提供类似 X/Open XA 的分布事务功能，通过 MQ 事务消息能达到分布式事务的最终一致。半消息：暂不能投递的消息，发送方已经将消息成功发送到了 MQ 服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半消息。半消息回查：由于网络闪断、生产者应用重

写在前面在我们日常的开发中，经常会遇到这样"在一段时间之后，触发某一个事件"的业务场景。如：电商平台下单后30分钟不支付订单自动取消 红包24小时不领取自动退还常见的解决方案1.定时扫描事先记录事件的触发时间点，定时任务不停查数据库对比触发时间。这种方式不实时，随着定时任务的执行频率变高，触发实时性会有所提升，但是频繁地扫描增加了数据库的压力，也是最简单的做法。2.jdk的解决方案jdk为我们提供的定时器Timer，延时队列DelayQueue。这种方式在单机，对可靠性要

一：确认种类RabbitMQ的消息确认有两种。一种是消息发送确认。这种是用来确认生产者将消息发送给交换器，交换器传递给队列的过程中，消息是否成功投递。发送确认分为两步，一是确认是否到达交换器，二是确认是否到达队列。第二种是消费接收确认。这种是确认消费者是否成功消费了队列中的消息。二：消息发送确认（1）ConfirmCallback通过实现ConfirmCallBack接口，消息发送到交换器Exchange后触发回调。使用该功能需要开启确认，spring-boot中...

消息队列面试题要点 复习要点本文主要围绕如下几点进行阐述：为什么使用消息队列？ 使用消息队列有什么缺点？ 消息队列如何选型？ 如何保证消息队列是高可用的？ 如何保证消息不被重复消费？ 如何保证消费的可靠性传输？ 如何保证消息的顺序性？下面围绕以上七点进行阐述。需要说明一下，本文不是《消息队列从入门到精通》这种教程，因此只是提供一个复习思路，而不是去教你们怎么调用消息队列的API。建议对消息队列不了解的人，去找点消息队列的博客看看，再看本文，收货更新。正文1.为什么要使用消息

下面是RabbitMQ的消息确认机bai制：“为了确保消息不会丢du失zhi，RabbitMQ支持消息确认机制。客户端在接受到dao消息并处理完后，可以发送一个ack消息给RabbitMQ，告诉它该消息可以安全的删除了。假如客户端在发送ack之前意外死掉了，那么RabbitMQ会将消息投递到下一个consumer客户端。如果有多个consumer客户端，RabbitMQ在投递消息时是轮询的。RabbitMQ如何判断客户端死掉了？唯一根据是客户端连接是否断开。这里没有超时机制，也就是说客户端可以处理一个消息很

消息服务中如何确保消息至少被消费一次本章讨论主题如何确保消息至少消费一次，确保消费者最大程度消费成功消费者消费消息有2中方式：1. push方式消息服务接收到消息之后，主动将消息推送给消费者消费2. pull方式消费者定时从消息服务中拉取消息进行消费下面我们将讨论2中方式中如何确保消息至少被消费一次。push模式消费的过程：消息服务查询待消费的消息列表 轮询待消息列表 调用消费者 消费者收到消费请求，执行业务处理，将处理结果返回给消息服务 消息服务接收.

聊聊mq中消息消费的几种方式本章内容从消费者的角度出发，分析一下消息消费的两种方式：push方式 pull方式push方式消息消费的过程： mq接收到消息 mq主动将消息推送给消费者（消费者需提供一个消费接口） mq属于主动方，消费者属于一种被动消费，一旦有消息到达mq，会触发mq推送机制，将消息推送给消费者，不管消费者处于何种状态。优点： 消费者代码较少：对于消费者来说，只需提供一个消费接口给mq即可；mq将接收到的消息，随即推送到指定的消费接口

聊聊业务系统中投递消息到mq的几种方式背景电商中有这样的一个场景：下单成功之后送积分的操作，我们使用mq来实现 下单成功之后，投递一条消息到mq，积分系统消费消息，给用户增加积分我们主要讨论一下，下单及投递消息到mq的操作，如何实现？每种方式优缺点？方式一step1：start transactionstep2：生成订单step3：投递消息到mqstep4：commit transaction这种方式是将发送消息放在了事务提交之前，可能存在的问题：step3发生异常