rocketmq

快速开始 启动Name Server 在windows下启动Name Server: mqnamesrv.cmd 提示需要设置环境变量： 设置环境变量 ROCKETMQ_HOME=D:\dev\rocketmq-all-4.6.0-bin-release 再次启动name server： Mqnamesrv.cmd 查看name server服务启动前后端口： 启动Broker mqbroker -n localhost:9876 发送接收消息 发送消息 D:\dev\rocketmq-all-4.6.0-bin-release\bin>set NAMESRV_ADDR=localhost:9876 D:\dev\rocketmq-all-4.6.0-bin-release\bin>tools.cmd org.apache.rocketmq.example.quickstart.Producer 接收消息 D:\dev\rocketmq-all-4.6.0-bin-release\bin>tools.cmd org.apache.rocketmq.example.quickstart.Consumer 停止服务 停止broker D:\dev\rocketmq-all-4.6.0-bin-release\bin>mqshutdown.cmd broker 停止namesrv D:

RocketMQ简介 Apache RocketMQ是一个采用Java语言开发的分布式的消息系统，由阿里巴巴团队开发，与2016年底贡献给Apache，成为了Apache的一个顶级项目。 在阿里内部，RocketMQ 很好地服务了 集 团大大小小上千个应用，在每年的双十一当天，更有不可思议的万亿级消息通过 RocketMQ 流转(在 2017 年的双十一当天，整个阿里巴巴集团通过 RocketMQ 流转的线上消息达到了 万亿级，峰值 TPS 达到 5600 万)，在阿里大中台策略上发挥着举足轻重的作用 。 地址：http://rocketmq.apache.org/ 来源： CSDN 作者： Leon_Jinhai_Sun 链接： https://blog.csdn.net/Leon_Jinhai_Sun/article/details/104077402

什么事顺序消息 消息顺序（Message Order）有两种：顺序消费（Orderly）和并行消费（Concurrently）。顺序消费表示消息消费的顺序同生产者为每个消息队列发送的顺序一致，所以如果正在处理全局顺序是强制性的场景，需要确保使用的主题只有一个消息队列。并行消费不再保证消息顺序，消费的最大并行数量受每个消费者客户端指定的线程池限制。 要保证顺序消息，需满足以下三点： 生产者写入有序 消息中间件内部有序 消费者消费有序 与kafka类似，rocketmq内部同一个topic有多个queue，默认4个，每个queue中的数据是有序的。 首先我们要保证顺序写入，就要使用单线程有序的写入到topic的某个queue中。rocketmq提供了 MessageQueueSelector 来根据业务规则选择queue，比如根据用户id，相同用户的数据写入到同一个队列中，保证单一用户有序。 默认有 SelectMessageQueueByHash , SelectMessageQueueByRandom , SelectMessageQueueByMachineRoom 三种实现。但是如上述需求默认的选择权无法满足，我们可以自定义选择器。 再来说消费者有序消费，在生产者有序生产消息并且写入到queue中以后，消费者只需要保证单线程消费

1.RocketMQ简介 RocketMQ是Apache RocketMQ֢作为阿里开源的一款高性能、高吞吐量的分布式消息中间件 特点： 支持Broker和Consumer端消息过滤 支持发布订阅模型，和点对点 支持拉pull和推push两种消息模式 单一队列百万消息、亿级消息堆积 支持单master节点，多master节点，多master多slave节点 任意一点都是高可用，水平拓展，producer，consumer，队列都可以分布式 消息失败重试机制、支持特点level的定时消息 新版本底层采用Netty 4.3.X支持分布式事务 适合金融类业务，高可用性跟踪和审计功能 概念： Producer：消息生成者 Producer Group：消息生产者组，发送同类消息的一个消息生成组 Consumer：消费者 Consumer Group：消息同类消息的多个实例 Tag：标签，子主题(二级分类)对topic的进一步细化，用于区分同一个主题下的不同业务的消息 Topic：主题，如订单类消息，queue是消息的物理管理单位，而topic是逻辑管理单位。一个topic下可以有多个queue, 默认自动创建是4个，手动创建是8个 Message：消息，每个Message必须指定一个Topic Broker：MQ程序，接收生产的消息，提供给消费者消息的程序 Name Server

 这节介绍RocketMQ客户端的启动流程，即Consumer和Producer的启动流程。 1. 客户端demo  首先先看下客户端的demo Producer: public class SyncProducer { public static void main (String[] args) throws Exception { // 实例化消息生产者Producer DefaultMQProducer producer = new DefaultMQProducer ("GroupTest"); // 设置NameServer的地址 producer.setNamesrvAddr ("localhost:9876"); // 启动Producer实例 producer.start (); for (int i = 0; i < 100; i++) { // 创建消息，并指定Topic，Tag和消息体 Message msg = new Message ("TopicTest" /* Topic */, "TagA" /* Tag */, ("Hello RocketMQ " + i).getBytes (RemotingHelper.DEFAULT_CHARSET) /* Message body */ ); // 发送消息到一个Broker SendResult

消息生产者启动之后，我们就可以按照需要发送消息了，消息发送之前，首先需要获取主题的路由信息，只有获取了这些信息我们才知道消息要发送到具体的Broker节点。 查找主题的路由信息 tryToFindTopicPublishlnfo 是查找主题的路由信息的方法。如果生产者中缓存了 topic 的路由信息，如果该路由信息中包含了消息队列，则直接返回该路由信息，如果没有缓存 或没有包含消息队列， 则向 NameServer 查询该 topic 的路由信息。如果最终未找到路由信息，则抛出异常： 无法找到主题相关路由信息异常。 Private TopicPublishInfo tryToFindTopicPublishInfo(final Stringtopic){ TopicPublishInfo topicPublishInfo = this.topicPublishInfoTable.get(topic); if(null == topicPublishInfo || !topicPublishInfo.ok()){ this.topicPublishInfoTable.putIfAbsent(topic,newTopicPublishInfo()); this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic);

brokerClusterName=rocketmq-cluster # broker名字,注意此处不同的配置文件填写的不一样 brokerName=broker-a # 0 表示Master,>0 表示Slave brokerId=0 # nameServer地址,分号分割 namesrvAddr=rocketmq-nameserver1:9876 # 在发送消息时,自动创建服务器不存在的Topic,默认创建的队列数 defaultTopicQueueNums=4 # 是否允许Broker 自动创建Topic, 建议线下开启, 线上关闭 autoCreateTopicEnable=true # 是否允许Broker 自动创建订阅组, 建议线下开启, 线上关闭 autoCreateSubscriptionGroup=true # Broker 对外服务的监听端口 listenPort=10911 # 删除文件时间点,默认是凌晨4点 deleteWhen=04 # 文件保留时间,默认是48小时 fileReservedTime=48 # commitLog每个文件的大小默认1G mapedFileSizeCommitLog=1073741824 # ConsumeQueue每个文件默认存30w条, 根据业务情况调整 mapedFileSizeConsumeQueue=30000 #

1、什么是Rocketmq 消息队列 RocketMQ 是阿里巴巴集团自主研发的专业消息中间件，基于高可用分布式集群技术，提供消息订阅和发布、消息轨迹查询以及定时（延时）消息、资源统计、监控报警等一系列消息云服务，是企业级互联网架构的核心产品。 消息队列 RocketMQ 历史超过9年，为分布式应用系统提供异步解耦、削峰填谷的能力，同时具备海量消息堆积、高吞吐、可靠重试等互联网应用所需的特性，是阿里巴巴双11使用的核心产品。 2012年开源，2017年成为apache顶级项目。 2、名词解释 以下主要对消息队列 RocketMQ 涉及的专有名词及术语进行定义和解析。 Topic 消息主题，一级消息类型，通过 Topic 对消息进行分类。 Message 消息，消息队列中信息传递的载体。 Message ID 消息的全局唯一标识，由消息队列 RocketMQ 系统自动生成，唯一标识某条消息。 Message Key 消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。 Tag 消息标签，二级消息类型，用来进一步区分某个 Topic 下的消息分类。 Producer 消息生产者，也称为消息发布者，负责生产并发送消息。 Producer 实例 Producer 的一个对象实例，不同的 Producer 实例可以运行在不同进程内或者不同机器上。Producer

分布式事务 通过MQ解决分布式事务的思路 1) 业务和消息生成耦合在一起 2) 业务和消息解耦 RocketMQ 中的事务消息 1) 目前RMQ3.2.6中事务消息的实现原理及存在的问题 2) 问题解决思路 本文介绍RocketMQ提供的第三种类型的消息——Transaction Message(事务消息)。在说事务消息之前，我们先来说说分布式事务的那些事！ 分布式事务 什么是分布式事务，我的理解是一半事务。怎么说，比如有2个异构系统，A异构系统要做T1，B异构系统要做T2，要么都成功，要么都失败。 要知道异构系统，很显然，不在一个数据库实例上，它们往往分布在不同物理节点上，本地事务已经失效 2阶段提交 2阶段提交协议，Two-Phase Commit，是处理分布式事务的一种常见手段。2PC，存在2个重要角色：事务协调器（TC），事务执行者。 2PC，可以看到节点之间的通信次数太多了，时间很长！时间变长了，从而导致，事务锁定的资源时间也变长了，造成资源等待时间变长！在高并发场景下，存在严重的性能问题！ 通过MQ解决分布式事务的思路 下面，我们来看看MQ在高并发场景下，是如何解决分布式事务的。 考虑生活中的场景： 我们去北京庆丰包子铺吃炒肝，先去营业员那里付款（Action1），拿到小票（Ticket），然后去取餐窗口排队拿炒肝（Action2）。思考2个问题：第一

1、为什么要使用消息队列? 主要有三个原因: 解耦、异步、削峰 (1)解耦 传统模式: 传统模式的 缺点 ： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的 优点 ： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的 缺点 ： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的 优点 ： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的 缺点 ： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的 优点 ： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2、使用了消息队列会有什么缺点? 分析 :一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。 要记住，不要给公司挖坑！ 回答 :回答也很容易，从以下两个个角度来答 系统可用性降低 :你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去