rocketmq

特性(features) 1 订阅与发布 消息的发布是指某个生产者向某个topic发送消息；消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息，进而从该topic消费数据。 2 消息顺序 消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了三条消息分别是订单创建、订单付款、订单完成。消费时要按照这个顺序消费才能有意义，但是同时订单之间是可以并行消费的。RocketMQ可以严格的保证消息有序。 顺序消息分为全局顺序消息与分区顺序消息，全局顺序是指某个Topic下的所有消息都要保证顺序；部分顺序消息只要保证每一组消息被顺序消费即可。 全局顺序 对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。 适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景 分区顺序 对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。 适用场景：性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。 3 消息过滤

安装 rocketmq-spring-boot-starter 在服务器,安装jar到maven mvn install -Dmaven.skip.test=true 关闭防火墙,确保producer连接到nameserver systemctl stop firewalld.service 检查broker是否连接上nameserver bin目录下执行命令sh mqadmin clusterList -n localhost:9876 如果看到 #Cluster Name #Broker Name #BID #Addr #Version #InTPS(LOAD) #OutTPS(LOAD) #PCWait(ms) #Hour #SPACE DefaultCluster DEFAULT_BROKER 0 192.168.192.129:10911 V4_2_0_SNAPSHOT 0.00(0,0ms) 0.00(0,0ms) 0 422168.55 -1.0000 也是证明broker已经连接到nameserver上。 异步发送成功 和springboot整合的方式发送 来源： CSDN 作者： wenxi2367 链接： https://blog.csdn.net/wenxi2367/article/details/104570865

为了实现分布式系统可扩展、可伸缩性的关键组件，需要具有高吞吐量、高可用等特点。我们很多时候都会考虑将消息系统纳入我们的选择中；比如我一个登录事件，有可能我登录之后需要做很多东西，比如日志，比如发布消息，比如推送，再比如发送代金券等等；这些事件与登录息息相关，但是本质上它们与登录这个事件没有直接的关系，只是在登录事件后，系统按照需求需要去初始化一些东西，或者去记录一些东西等等；如果把所有的东西都纳入到登录这个事件中（同一个事物中），那登录的事件内处理的逻辑更多，会造成什么后果？登录时间很长，让用户无法忍受，另外，假如登录过程中出现了未发现异常，那是不是导致用户直接无法登录？为了解决这样的问题，我们引入了消息系统，比如我这台机登录过后，我将登录的一些信息，通过远程方式发送到另外一台机器上（或者同一台机），让它们去处理相应的后续逻辑实现； 目的是：1、用户登录更快，体验上更好， 2、只要保证登录部分完整，即便后续出错，并不影响用户正常使用，即容错性更强！ 谈到消息系统，首先想到的第一个问题肯定会是： 消息的顺序性 本来很想说一下关于消息顺序性的一些问题，不过由于我也是借鉴了一些其他的帖子，以及官方的文档，所以这里就不会去赘述这些了，稍后我会分享一些很不错的链接，留给自己以后看，也希望可以给一些刚好要入门rocketmq的网友提供一些资料； rocketmq是阿里云的一套开源产品

RocketMQ（4）—SpringBoot整合RocketMQ 来源： CSDN 作者： 武林是大腿 链接： https://blog.csdn.net/qq_35854212/article/details/104557231

RocketMQ（5）—RocketMQ重试机制 来源： CSDN 作者： 武林是大腿 链接： https://blog.csdn.net/qq_35854212/article/details/104557252

rocketmq运行时提示 No route info of this topic 异常产生的原因可能是 ①Broker禁止自动创建Topic，且用户没有通过手工方式创建Topic ②Broker没有正确连接到Name Server ③Producer没有正确连接到Name Server 首先解决①这种情况，启动顺序要先启动nameserver，再启动broker，启动broker时加上autoCreateTopicEnable=true 例如 nohup sh mqbroker -n localhost:9876 autoCreateTopicEnable=true & 启动没有异常检查下nameserver中是否成功注册了broker，有两种方式 第一种、看broker的日志 如果出现形如 2018-02-28 16:21:35 INFO BrokerControllerScheduledThread1 - register broker to name server 192.168.192.129:9876 OK 2018-02-28 16:22:05 INFO BrokerControllerScheduledThread1 - register broker to name server 192.168.192.129:9876 OK 证明已经连接到nameserver上

什么是RocketMQ 阿里消息队列 RocketMQ版既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性，同时是收费的产品。 应用场景 削峰填谷 诸如秒杀、抢红包、企业开门红等大型活动时皆会带来较高的流量脉冲，或因没做相应的保护而导致系统超负荷甚至崩溃，或因限制太过导致请求大量失败而影响用户体验，消息队列 RocketMQ 版可提供削峰填谷的服务来解决该问题。 异步解耦 交易系统作为淘宝/天猫主站最核心的系统，每笔交易订单数据的产生会引起几百个下游业务系统的关注，包括物流、购物车、积分、流计算分析等等，整体业务系统庞大而且复杂，消息队列 RocketMQ 版可实现异步通信和应用解耦，确保主站业务的连续性。 顺序收发 细数日常中需要保证顺序的应用场景非常多，例如证券交易过程时间优先原则，交易系统中的订单创建、支付、退款等流程，航班中的旅客登机消息处理等等。与先进先出（First In First Out，缩写 FIFO）原理类似，消息队列 RocketMQ 版提供的顺序消息即保证消息 FIFO。 分布式事务一致性 交易系统、支付红包等场景需要确保数据的最终一致性，大量引入消息队列 RocketMQ 版的分布式事务，既可以实现系统之间的解耦，又可以保证最终的数据一致性。 大数据分析 数据在“流动”中产生价值

 这节介绍Producer发送消息的流程。  接上一节开头的Demo，发送消息的写法如下： 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 sendResult = producer.send (msg); //

面试官心理分析 只要聊到你做了分布式系统，必问分布式事务，你对分布式事务一无所知的话，确实会很坑，你起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。 现在面试，分布式系统成了标配，而分布式系统带来的分布式事务也成了标配了。因为你做系统肯定要用事务吧，如果是分布式系统，肯定要用分布式事务吧。先不说你搞过没有，起码你得明白有哪几种方案，每种方案可能有啥坑？比如 TCC 方案的网络问题、XA 方案的一致性问题。 面试题剖析 分布式事务的实现主要有以下 5 种方案： XA 方案 TCC 方案 本地消息表 可靠消息最终一致性方案 最大努力通知方案 两阶段提交方案/XA方案 所谓的 XA 方案，即：两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。 这种分布式事务方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩儿，那么基于 Spring + JTA 就可以搞定，自己随便搜个 demo 看看就知道了。 这个方案，我们很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。我可以给大家介绍一下，

前言 这篇文章以4.3.0版本为标准进行讲述在linux下部署RocketMQ单机实例,在此之前需要已配置JAVA环境。 apache RocketMQ 是阿里巴巴在2016年11月捐赠给了apache基金会并于2017年9月顺利毕业成为apache顶级项目。 下载程序包 直接使用一般就 下载 已经编译好的二进制文件就好了,下载好以后 <code>> unzip rocketmq-all-4.3.0-bin-release.zip > cd rocketmq-all-4.3.0-bin-release/ </code> 启动name server <code>> nohup sh bin/mqnamesrv & </code> tail一下日志看看是否已经启动成功 <code>> tail -f ~/logs/rocketmqlogs/namesrv.log The Name Server boot success... </code> 启动Broker <code>> nohup sh bin/mqbroker -n localhost:9876 & </code> tail一下日志看看是否已经启动成功 <code>> tail -f ~/logs/rocketmqlogs/broker.log The broker[%s, 172.30.30.233:10911] boot