rocketmq

场景：2 个消费者进程中，创建了 2 个消费者，同属于 1 个消费组，但是订阅了不同的 topic，会因为订阅信息相互覆盖，导致拉不到消息。 原因是 rocketMQ 的订阅关系，是根据 group 来管理的，c1 订阅 t1，c2 订阅 t2，他们同属于 group，当 c1 拉取 t1 的消息时，broker 发现 group 订阅的是 t2，就不会返回消息给 c1。 client 在 MQClientInstance 中发送心跳给所有的 broker，心跳中包含 consumer 的订阅信息， this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { @Override public void run() { try { MQClientInstance.this.cleanOfflineBroker(); MQClientInstance.this.sendHeartbeatToAllBrokerWithLock(); } catch (Exception e) { log.error("ScheduledTask sendHeartbeatToAllBroker exception", e); } } }, 1000, this.clientConfig

consumer 消费失败，会把消息重新发往 %RETRY% + consumerGroup，这个 retry 消息会在一定时间后，真实送到 retry topic。 broker 处理发送到 retry topic 的消息： org.apache.rocketmq.broker.processor.SendMessageProcessor#consumerSendMsgBack 消息消费超过最大次数或者客户端配置了直接发送到死信队列，则把消息发送到死信队列，否则把消息发送 retry topic，虽然看起来是把消息直接写入 %RETRY% + consumerGroup 但其实在 putMessage 的时候，会把消息写入 SCHEDULE_TOPIC_XXXX // org.apache.rocketmq.store.CommitLog#putMessage if (msg.getDelayTimeLevel() > 0) { if (msg.getDelayTimeLevel() > this.defaultMessageStore.getScheduleMessageService().getMaxDelayLevel()) { msg.setDelayTimeLevel(this.defaultMessageStore.getScheduleMessageService(

分布式消息队列中间件作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性，其复杂性可见一斑，作为核心组件，有必要去深入了解学习 前言 分布式消息队列中间件主要具有以下优势： 削峰填谷 （主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题） 系统解耦 （解决不同重要程度、不同能力级别系统之间依赖导致一死全死） 提升性能 （当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统） 蓄流压测 （线上有些链路不好压测，可以通过堆积一定量消息再放开来压测） 笔者为什么要深入rocketmq，一方面是因为公司目前已经在线上使用了rocketmq，另一方面也是因为笔者是主要的维护人员，需要对其有个深入的了解，并且测试环境的集群之前出现了问题，虽然最终解决，但是发生的原因依旧没有找到，感觉还是需要去深入了解下，对架构和源码进行一个整体的学习以应对之后可能出现的问题 rocketmq的相关中文文档在github上应该算非常详细了，初学者应该经常去看一看，每一句思考下，能收获不少，而且其中涉及到不少概念，还是需要去理解的，不明白的话也无法深入的学习下去，地址如下： https://github.com/apache/rocketmq/tree/master/docs/cn 对于与其他中间件的比较和起源发展可参考 阿里中间件博客 了解

1.流程图 步骤： 1.在给mq发送消息的时候，发送一个“半消息”，具有事务的消息 2.实现 实现两个方法 在第一个方法中实现本地事务的提交，提交的同时在数据库中记录一个成功日志，以便二次确认时候判断是否成功，如果没有异常，该方法返回一个具有commit的事务对象，反之回滚 在第二个方法做二次确认，根据transactionid 查询数据库做二次确认。 来源： https://www.cnblogs.com/longsanshi/p/11920937.html

概述 RocketMQ 是一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。 由于本教程整个案例基于 Spring Cloud，故我们采用 Spring Cloud Stream 完成一次发布和订阅 官方教程 # Spring Cloud Stream Spring Cloud Stream 是一个用于构建基于消息的微服务应用框架。它基于 Spring Boot 来创建具有生产级别的单机 Spring 应用，并且使用 Spring Integration 与 Broker 进行连接。 Spring Cloud Stream 提供了消息中间件配置的统一抽象，推出了 publish-subscribe 、 consumer groups 、 partition 这些统一的概念。 Spring Cloud Stream 内部有两个概念： Binder： 跟外部消息中间件集成的组件，用来创建 Binding，各消息中间件都有自己的 Binder 实现。 Binding： 包括 Input Binding 和 Output Binding。 Binding 在消息中间件与应用程序提供的 Provider 和 Consumer 之间提供了一个桥梁，实现了开发者只需使用应用程序的 Provider 或 Consumer 生产或消费数据即可

概述 在实际生产中，我们需要发布和订阅的消息可能不止一种 Topic ，故此时就需要使用自定义 Binding 来帮我们实现多 Topic 的发布和订阅功能 生产者 自定义 Output 接口，代码如下： public interface MySource { @Output("output1") MessageChannel output1(); @Output("output2") MessageChannel output2(); } 发布消息的案例代码如下： @Autowired private MySource source; public void send(String msg) throws Exception { source.output1().send(MessageBuilder.withPayload(msg).build()); } 消费者 自定义 Input 接口，代码如下： public interface MySink { @Input("input1") SubscribableChannel input1(); @Input("input2") SubscribableChannel input2(); @Input("input3") SubscribableChannel input3(); @Input("input4")

POM 主要增加了 org.springframework.cloud:spring-cloud-starter-stream-rocketmq 依赖 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.snake</groupId> <artifactId>hello-spring-cloud-alibaba-dependencies</artifactId> <version>1.0.0-SNAPSHOT</version> <relativePath>../hello-spring-cloud-alibaba-dependencies/pom.xml</relativePath> </parent> <artifactId>hello

docker-compose.yml 注意：启动 RocketMQ Server + Broker + Console 至少需要 2G 内存 version: '3.5' services: rmqnamesrv: image: foxiswho/rocketmq:server container_name: rmqnamesrv ports: - 9876:9876 volumes: - ./data/logs:/opt/logs - ./data/store:/opt/store networks: rmq: aliases: - rmqnamesrv rmqbroker: image: foxiswho/rocketmq:broker container_name: rmqbroker ports: - 10909:10909 - 10911:10911 volumes: - ./data/logs:/opt/logs - ./data/store:/opt/store - ./data/brokerconf/broker.conf:/etc/rocketmq/broker.conf environment: NAMESRV_ADDR: "rmqnamesrv:9876" JAVA_OPTS: " -Duser.home=/opt" JAVA_OPT_EXT: "

概述 消息队列作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。主要具有以下优势： 削峰填谷： 主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题 系统解耦： 解决不同重要程度、不同能力级别系统之间依赖导致一死全死 提升性能： 当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统 蓄流压测： 线上有些链路不好压测，可以通过堆积一定量消息再放开来压测 RocketMQ Apache Alibaba RocketMQ 是一个消息中间件。消息中间件中有两个角色：消息生产者和消息消费者。RocketMQ 里同样有这两个概念，消息生产者负责创建消息并发送到 RocketMQ 服务器，RocketMQ 服务器会将消息持久化到磁盘，消息消费者从 RocketMQ 服务器拉取消息并提交给应用消费。 RocketMQ 特点 RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点： 支持严格的消息顺序 支持 Topic 与 Queue 两种模式 亿级消息堆积能力 比较友好的分布式特性 同时支持 Push 与 Pull 方式消费消息 历经多次天猫双十一海量消息考验 RocketMQ 优势 目前主流的 MQ 主要是 RocketMQ、kafka、RabbitMQ，其主要优势有： 支持事务型消息（消息发送和 DB 操作保持两方的最终一致性

序 本文主要研究一下rocketmq的pullThresholdForQueue pullThresholdForQueue rocketmq-client-4.5.2-sources.jar!/org/apache/rocketmq/client/consumer/DefaultMQPushConsumer.java public class DefaultMQPushConsumer extends ClientConfig implements MQPushConsumer { //...... /** * Flow control threshold on queue level, each message queue will cache at most 1000 messages by default, * Consider the {@code pullBatchSize}, the instantaneous value may exceed the limit */ private int pullThresholdForQueue = 1000; /** * Limit the cached message size on queue level, each message queue will cache at most 100 MiB messages by