rocketmq

一、RocketMQ4.X 消费者核心配置 consumeFromWhere 配置（某些情况失效：参考 https://blog.csdn.net/a417930422/article/details/83585397 ） 这个配置基本不用改，采用默认配置即可。 CONSUME_FROM_FIRST_OFFSET： 初次从消息队列头部开始消费，即历史消息（还储存在 broker 的）全部消费一遍，后续再启动接着上次消费的进度开始消费。 CONSUME_FROM_LAST_OFFSET： 默认策略，初次从该队列最尾开始消费，即跳过历史消息，后续再启动接着上次消费的进度开始消费。 CONSUME_FROM_TIMESTAMP：从某个时间点开始消费，默认是半个小时以前，后续再启动接着上次消费的进度开始消费。 allocateMessageQueueStrategy：负载均衡策略算法，即消费者分配到 queue 的算法 默认值是 AllocateMessageQueueAveragely 即取模平均分配 offsetStore：消息消费进度存储器 offsetStore 有两个策略：LocalFileOffsetStore 和 RemoteBrokerOffsetStore 广播模式默认使用 LocalFileOffsetStore， 集群模式默认使用

为什么使用消息中间件？ 消息队列核心使用场景<优点>： 解耦、异步、削峰 (1)解耦 传统模式: 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的优点： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的缺点： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的优点： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 消息中间件缺点有哪些？ 系统可用性降低 系统引入的外部依赖越多，越容易挂掉，需要保证消息队列的高可用。 系统复杂度提高 多一个 MQ 组件，那就需要面对 消息没有重复消费，处理消息丢失的情况，保证消息传递的顺序性等等系统级别问题。 一致性问题 多个消费者消费某一个消息就可能出现个别消费失败的情况，会出现数据不一致。 ActiveMQ、RabbitMQ、RocketMQ、Kafka

重试机制 　　由于MQ经常处于复杂的分布式系统中，考虑网络波动，服务宕机，程序异常因素，很有可能出现消息发送或者消费失败的问题。因此，消息的重试就是所有MQ中间件必须考虑到的一个关键点。如果没有消息重试，就可能产生消息丢失的问题，可能对系统产生很大的影响。所以，秉承宁可多发消息，也不可丢失消息的原则，大部分MQ都对消息重试提供了很好的支持。 　　MQ 消费者的消费逻辑失败时，可以通过设置返回状态达到消息重试的结果。 　　MQ 消息重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。 模拟异常 消费者 /** * RocketMQ重试机制消费者 */ public class RetryConsumer { public static void main(String[] args) throws MQClientException { //创建消费者 DefaultMQPushConsumer consumer=new DefaultMQPushConsumer("rmq-group"); //设置NameServer地址 consumer.setNamesrvAddr("192.168.33.135:9876;192.168.33.136:9876"); //设置实例名称 consumer.setInstanceName(

一. 什么是消息中间件 利用高效可靠的消息传递机制进行平台无关的数据交流； 并给予数据通信来进行分布式系统的集成； 通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。 二.消息中间件应用场景 1.跨系统数据传递 2.高并发流量的削峰， 3.数据的异步处理。 三.常用消息中间件 ActiveMQ：由Apache纯用java进行开发的消息中间件，存在的时间久远，完全遵循JMS进行开发。 RabbitMQ：支持的消息分发机制最全，使用Erlang语言进行开发的 Kafka：使用scala和java进行开发的语言，为了弥补Activemq的吞吐量低而进行开发的语言。具有高吞吐量的特点，可以和Hadoop结合。进行大数据的开发。 RocketMQ：由阿里使用java开发的一个高性能分布式，经受了双十一的考验。 四.消息中间件核心设计及各部分概述 本质：一种具有接受请求，保存数据，发送数据等功能的网络应用和一般网络应用程序的区别是它主要负责数据的接受和传递，所以性能优于普通程序。 1.协议（语法，语义，同步） ： OpenWire :ActiveMQ专属 AMQP :事务支持，持久化支持，出生于金融，可靠性高（RabbitMQ，ACTIVEMQ） MQTT :即时通讯协议，主要用去物联网，轻量级，结构简单，传输快，不支持事务，没有持久化相关设计。适用于计算能力有限低带宽

一.导入依赖 <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>4.1.0-incubating</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.1.1</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>1.1.1</version> </dependency> 二:生产者 import org.apache.rocketmq.client.exception.MQClientException; import org.apache.rocketmq.client.producer.DefaultMQProducer; import org.apache.rocketmq.client.producer.SendResult; import org

在什么情况下会发生RocketMQ的消息重复消费 　　1.当系统的调用链路比较长的时候，比如系统A调用系统B，系统B再把消息发送到RocketMQ中，在系统A调用系统B的时候，如果系统B处理成功，但是迟迟没有将调用成功的结果返回给系统A的时候，系统A就会尝试重新发起请求给系统B，造成系统B重复处理，发起多条消息给RocketMQ造成重复消费； 　　2.在系统B发送给RocketMQ的时候，也有可能会发生和上面一样的问题，消息发送超时，节骨系统B重试，导致RocketMQ接收到了重读消息； 　　3.当RocketMQ成功接收到消息，并将消息交给消费者处理，如果消费者消费完成后还没来得及提交offset给RocketMQ，自己宕机或者重启了，那么RocketMQ没有接收到offset，就会认为消费失败了，会重发消息给消费者再次消费； 如何解决消息的重复消费 　　通过 幂等性 来保证，只要保证重复消息不对结果产生影响，就完美地解决这个问题。 在生产者端保证幂等性，一下两种方式： 　　1.RocketMQ支持消息查询的功能，只要去RocketMQ查询一下是否已经发送过该条消息就可以了，不存在则发送，存在则不发送； 　　2.引入Redis，在发送消息到RocketMQ成功之后，向Redis中插入一条数据，如果发送重试，则先去Redis查询一个该条消息是否已经发送过了

从关注开源，到使用开源，再到参与开源贡献，越来越多的国内开发者通过开源技术来构建业务。 截止目前，Arthas / Dubbo / ChaosBalde / Nacos / RocketMQ / Seata / Sentinel / Spring Cloud Alibaba / Tengine 等微服务领域的开源项目在 GitHub 上已获得近 8w 的 star，contributor 数量达738位，以一种社区协作的方式，来提升项目的生产效率和分发效率。 这里面，大家既是项目的开发者，也是项目的使用者，作为项目的需求方一同参与到项目的迭代过程中，使得项目能以更快的响应速度来满足实际需求，快速迭代出「好」的产品，这似乎是其他协作方式难以达到的。 通常，我们都会通过在 GitHub 上订阅邮件列表，来了解社区动态。这一次，我们联合以上各开源项目的负责人，发布「微服务开源生态报告」，汇集各个开源项目近期的社区动态，帮助开发者们更高效的了解到各开源项目的最新进展。 社区动态包括，但不限于： 版本发布 人员动态 项目动态和规划 培训和活动 非常欢迎国内其他微服务领域的开源项目将近期的社区动态，投递给我们，我们将一同发布。点击 这里 ，在公众号后台给我们留言，我们会第一时间与您取得联系。 以下是第一期「微服务开源生态报告」的内容。 一、Apache Dubbo 1. 人员动态：

RocketMQ入门及部署 RocketMQ整体架构 如上图所示，整体可以分成4个角色，分别是：Producer，Consumer，Broker以及NameServer； 1.NameServer 可以理解为是消息队列的协调者，Broker向它注册路由信息，同时Client向其获取路由信息，如果使用过Zookeeper，就比较容易理解了，但是功能比Zookeeper弱； NameServer本身是没有状态的，并且多个NameServer直接并没有通信，可以横向扩展多台，Broker会和每一台NameServer建立长连接； 2.Broker Broker是RocketMQ的核心，提供了消息的接收，存储，拉取等功能，一般都需要保证Broker的高可用，所以会配置Broker Slave，当Master挂掉之后，Consumer然后可以消费Slave； Broker分为Master和Slave，一个Master可以对应多个Slave，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave； 3.Producer 消息队列的生产者，需要与NameServer建立连接，从NameServer获取Topic路由信息，并向提供Topic服务的Broker Master建立连接

1.1、RocketMQ简介 Apache RocketMQ是一个采用Java语言开发的分布式的消息系统，由阿里巴巴团队开发，与2016年底贡献给 Apache，成为了Apache的一个顶级项目。 在阿里内部，RocketMQ 很好地服务了 集 团大大小小上千个应用，在每年的双十一当天，更有不可思议的万亿级 消息通过 RocketMQ 流转(在 2017 年的双十一当天，整个阿里巴巴集团通过 RocketMQ 流转的线上消息达到了 万 亿级，峰值 TPS 达到 5600 万)，在阿里大中台策略上发挥着举足轻重的作用 。 地址：http://rocketmq.apache.org/ 1.2、RocketMQ的历史发展 阿里巴巴消息中间件起源 于 2001 年的五彩石项目， Notify 在这期间应运而生，用于交易核心消息的流转 。 2010 年， B2B 开始大规模使用 ActiveMQ 作为消息内核，随着阿里业务 的快速发展，急需一款支持顺序消 息，拥有海量消息堆积能力的消息中间件， MetaQ 1.0 在 2011 年诞生 。 2012年， MetaQ已经发展到了3.0版本，并抽象出了通用的消息引擎 RocketMQ。 随后，对 RocketMQ 进行 了开源 ， 阿里的消息中间件正式走人了 公众视野 。 2015年， RocketMQ已经经历了多年双十一的洗礼，在可用性、

由于消息的消费方式有两种，所以两种方式也有不同的API： 1. PushConsumer的配置 　　1. consumerGroup： 默认值为DEFAULT_CONSUMER，Consumer组名，多个Consumer如果属于一个应用，订阅同样的消息，且消费逻辑一致，则应该将它们归为同一组 　　2. messageModel： 消息模型，默认值为CLUSTERING，支持集群消费，广播消费两种模型 　　3. consumeFromWhere： 默认值为CONSUME_FROM_LAST_OFFSET，Consumer启动后，默认从什么位置开始消费 　　4. allocateMessageQueueStrategy： 默认值AllocateMessageQueueAveragely，Rebalance（轮询）算法实现策略 　　5. subscription： 默认值{}，订阅关系 　　6. messageListener： 消息监听器 　　7. offsetStore： 消息进度存储 　　8. consumeThreadMin： 默认10，消费线程池数量 　　9. consumeThreadMax： 默认20， 消费线程数量 　　10. consumeConcurrentlyMaxSpan： 默认值2000， 单队列并行消费允许的最大跨度 　　11.