Apache RocketMQ

配置环境变量 ROCKETMQ_HOME 环境Path变量 追加 %ROCKETMQ_HOME%\bin 启动 namaserver D:\shanju\rocketmq\bin> .\mqnamesrv.cmd 启动broker D:\shanju\rocketmq\bin> .\mqbroker.cmd -n 127.0.0.1:9876 使用自带工具类进行测试 启动生产者 D:\shanju\rocketmq>set NAMESRV_ADDR=127.0.0.1:9876 D:\shanju\rocketmq\bin>tools.cmd org.apache.rocketmq.example.quickstart.Producer 启动消费者 D:\shanju\rocketmq>set NAMESRV_ADDR=127.0.0.1:9876 D:\shanju\rocketmq>tools.cmd org.apache.rocketmq.example.quickstart.Consumer 看到消息发送和接收成功则表示环境搭建成功 来源： oschina 链接： https://my.oschina.net/zhongwenhao/blog/4305718

简介 本文主要介绍clusterList和clusterRT命令 命令 clusterList：查看集群列表 clusterRT：测试集群的响应耗时 例子 clusterList 1）帮助 ./mqadmin clusterList -h 2）查看集群基本信息 ./mqadmin clusterList -n nameserver1:9876 3) 查看集群更多信息 ./mqadmin clusterList -n nameserver1:9876 -m 4) 查询集群信息，间隔10秒刷新当前信息。 ./mqadmin clusterList -n nameserver1:9876 -m -i 10 clusterRT bug: -s参数必须制定，不指定命令无法执行 1）帮助 ./mqadmin clusterRT -h 2）查看指定cluster的的响应时间（每次发一条消息，单条消息大小为10Bytes） #RT为响应时间（单位为ms)，successCount为发送成功的，failCount为发送失败的。 ./mqadmin clusterRT -n nameserver1:9876 -c CLUSTERNAME -s 10 -a 1 3）查看指定cluster的的响应时间（每次发5条消息，单条消息大小为100Bytes） #RT为响应时间（单位为ms)

简介 本文主要介绍updateBrokerConfig、brokerStatus，wipeWritePerm和getBrokerConfig 命令 updateBrokerConfig ：动态更新broker的配置（重启broker后会配置失效） brokerStatus ：获取broker的运行时状态数据 wipeWritePerm：设置某broker为只读 getBrokerConfig：获取broker的配置信息 例子 getBrokerConfig 1）帮助 ./mqadmin getBrokerConfig -h 2) 查看指定集群的所有broker信息 ./mqadmin getBrokerConfig -c CLUSTERNAME -n nameserver1:9876 3）查看指定集群的某broker信息 ./mqadmin getBrokerConfig -c CLUSTERNAME -n nameserver1:9876 -b 192.168.2.11:10911 updateBrokerConfig 1）帮助 ./mqadmin updateBrokerConfig -h 2) 更新集群中所有broker的fileReservedTime为48 ./mqadmin updateBrokerConfig -n nameserver1:9876 -c

什么是消息队列 MQ全称为Message Queue 消息队列（MQ）是一种应用程序对应用程序的通信方法。MQ是消费-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取队列中的消息。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。 你可以想想在生活中的一种场景：当你把信件的投进邮筒，邮递员肯定最终会将信件送给收件人。我们可以把MQ比作 邮局和邮递员。 MQ和邮局的主要区别是,它不处理消息,但是,它会接受数据、存储消息数据、转发消息 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 如果有人问你这个问题，期望的一个回答 是说，你们公司有个什么业务场景 ，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个： 解耦 、 异步 、 削峰 。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... 在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合

https://mp.weixin.qq.com/s/XknegP66mnYboiBx556Kzw 分布式事务 收录于话题 #程序员 1558 #程序人生 664 #分布式事务 25 因为之前版本图有丢失和乱序，出了这个修订版本 前言 上一篇文章已经讲完分布式了，那暖男说要讲分布式事务那就一定会讲，只是我估计大家没料到暖男这么快就肝好了吧？ 事务想必大家并不陌生，至于什么是 ACID，也是老生常谈了。不过暖男为了保证文章的完整性确保所有人都听得懂，我还是得先说说 ACID，然后再来介绍下什么是分布式事务和常见的分布式事务包括 2PC、3PC、TCC、本地消息表、消息事务、最大努力通知。 事务 严格意义上的事务实现应该是 具备原子性、一致性、隔离性和持久性 ，简称 ACID。 原子性（Atomicity），可以理解为一个事务内的所有操作要么都执行，要么都不执行。 一致性（Consistency），可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是300，不会存在我账上钱加了，你账上钱没扣的 中间状态 。 隔离性（Isolation），指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。 持久性（Durability）

本文是作者原创,版权归作者所有.若要转载,请注明出处. 本文RocketMQ版本为rocketmq-all-4.7.0,系统为win10.请各位去官网下载,也可以留言, 我发安装包 RocketMQ安装 (前置条件为已安装java并配置JAVA_HOME) 1.配置环境变量 2.切换到安装目录的bin文件夹下,启动mqnamesrv.cmd,如下图 命令 start mqnamesrv.cmd 看到如下窗口表示启动成功 3.启动bin目录下的mqbroker.cmd 命令: start mqbroker.cmd -n 127.0.0.1:9876 -c ../conf/broker.conf 看到如下窗口表示启动成功 4.RocketMQ管理控制台部署(非必须,可跳过) 下载地址 https: // github.com/apache/rocketmq-externals.git 下载完成之后，进入‘rocketmq-externals\rocketmq-console\src\main\resources’文件夹，打开‘application.properties’进行配置,如下 这里将启动端口改成8081,并填配置rocketmq的端口 127.0.0.1.9876 编译该控制台源码 进入‘\rocketmq-externals\rocketmq-console’文件夹，

一、为什么要使用消息队列？ 1、 削峰 当有大并发产生的时候，数据会堆积在MQ中，消费端保持平稳的消费能力，不会给后端服务造成太大压力； 2、解耦 传统模式: 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 3、异步 异步可以大大提高响应的速度； 二、使用消息队列的缺点？ 1、一定程度上降低了系统的可用性 在不使用第三方组件的情况下，只有部署服务的机器挂了，进程才会出问题； 但是使用第三方消息队列，增加了一种宕机的可能，就是消息队列服务挂了也会导致进程出问题； 2、系统复杂性增加 代码复杂：需要引入第三方服务相关代码；本来只是一个方法调用而已。 需要考虑消息队列服务的一些问题， 如何保证消息不被重复消费？如何保证保证消息可靠传输？ 三、消息队列的选型 来一个对比表： 特性 ActiveMQ RabbitMQ RocketMQ kafka 开发语言 java erlang java scala 单机吞吐量 万级 万级 10万级 10万级 时效性 ms级 us级 ms级 ms级以内 可用性 高(主从架构) 高(主从架构) 非常高(分布式架构) 非常高(分布式架构)

提升技术能力 当我们阅读完一个开源框架的源码之后，我们的技术能力会有很大的提升。 比如说我们阅读RocketMQ 消息队列源码之后，我们就会对消息队列的架构设计思想都有很清楚的了解，然后再去看其他开源消息队列框架源码的时候，我们会发现他们很多的设计思想都有共同之处。我们把这些开源框架的设计思想都吸收之后，再应用到我们自己的系统上去，这样我们的系统也会设计的越来越合理。学以致用，我们的技术能力会越来越强，系统设计能力也会越来越得心应手。 提升职场竞争力 假设你公司生产上使用的RocketMQ了消息队列，有一天出现了一个技术问题，精通RocketMQ源码的你从源码角度分析定位问题，然后提出了解决方案，解决了这个技术问题。这样领导和同事都会非常认可你，把你当作技术大牛，有技术上问题就会去请教你。 提升面试通过率 你阅读过某个技术的源码，对这个技术的架构和设计思想都了如指掌。在求职面试的时候，你和面试官聊这个技术的时候说的头头是道，而且面试官提的问题你都能从源码角度去解答，这样面试官也会认可你的技术能力，那面试成功率比没阅读过源码的，自然要高。 总结 如果我们没有阅读过源码，只停留在CRUD的水平，技术能力很难得到提升，随着工作年限的增长，我们慢慢就会被这个行业淘汰。 来源： oschina 链接： https://my.oschina.net/u/4361024/blog/4660687

using org.apache.rocketmq.client.consumer; using org.apache.rocketmq.client.consumer.listener; using org.apache.rocketmq.client.producer; using org.apache.rocketmq.common.consumer; using org.apache.rocketmq.common.protocol.heartbeat; using System; using System.Collections.Generic; using System.Configuration; using System.Linq; namespace SqlBulkCopyData.消息中间件 { public class RocketMqHelper { private static readonly string namesrvAddr = null; private static IList<DefaultMQProducer> producers = new List<DefaultMQProducer>(); private static IList<DefaultMQPushConsumer> consumers = new List

目录 为什么需要消息队列 1.异步 ：一个下单流程，你需要扣积分，扣优惠卷，发短信等，有些耗时又不需要立即处理的事，可以丢到队列里异步处理。 2.削峰 ：按平常的流量，服务器刚好可以正常负载。偶尔推出一个优惠活动时，请求量极速上升。由于服务器 Redis，MySQL 承受能力不一样，如果请求全部接收，服务器负载不了会导致宕机。加机器嘛，需要去调整配置，活动结束后用不到了，即麻烦又浪费。这时可以将请求放到队列里，按照服务器的能力去消费。 3.解耦 ：一个订单流程，需要扣积分，优惠券，发短信等调用多个接口，出现问题时不好排查。像发短信有很多地方需要用到， 如果哪天修改了短信接口参数，用到的地方都得修改。这时可以将要发送的内容放到队列里，起一个服务去消费， 统一发送短信。 高吞吐、高可用 MQ 对比分析 看了几个招聘网站，提到较多的消息队列有：RabbitMQ、RocketMQ、Kafka 以及 Redis 的消息队列和发布订阅模式。 Redis 队列是用 List 数据结构模拟的，指定一端 Push，另一端 Pop，一条消息只能被一个程序所消费。如果要一对多消费的，可以用 Redis 的发布订阅模式。Redis 发布订阅是实时消费的，服务端不会保存生产的消息，也不会记录客户端消费到哪一条。在消费的时候如果客户端宕机了，消息就会丢失。这时就需要用到高级的消息队列，如 RocketMQ