rocketmq部署

下图是从官网摘过来的RocketMQ架构图 RocketMQ架构分为四个部分：NameServer，Broker，Producer，Consumer。其中每一部分都可以水平扩展以避免单点故障。 NameServer ：NameServer集群的每一个节点都会记录完整的路由信息，提供可靠的读写服务，并支持存储扩展。NameServer负责管理以下两个部分： Broker Management：Broker集群的启动需要向NameServer注册，NameServer与Broker会建立心跳连接，随时检查一个Broker是否存活 Routing Management：NameServer集群的每一个节点都会记录整个Broker集群完整的路由信息，与客户端（客户端指Producer和Consumer，下文同义）查询的queue信息 客户端可能需要从NameServer查询相关的路由信息，但是客户端怎么知道NameServer的地址？有以下四种方式进行配置： 在代码中使用如 producer.setNamesrvAddr("ip:port") 此类代码 在配置中配置 rocketmq.namesrv.addr 配置环境变量 NAMESRV_ADDR 直接使用HTTP Endpoint 如果以上四种方式都使用了，会有一个生效优先级： 编程方式 > 配置 > 环境变量 > HTTP

RocketMQ简介 1.RocketMQ是一款分布式、队列模型的消息中间件，是阿里巴巴集团自主研发的专业消息中间件，借鉴参考了JMS规范的MQ实现，更参考了优秀的开源消息中间件KAFKA,实现了业务消峰、分布式事务的优秀框架。 2.其底层代码编写清晰优秀，采用 Netty NIO 框架进行数据通信 3.摒弃了Zookeeper,内部使用更轻量级的NameServer进行网络路由，提高服务性能，并且 支持消息失败重试 机制。 4.天然支持集群模型，消费者负载均衡、水平扩展能力，支持广播模式和集群模式。 5.采用零拷贝的原理、顺序写盘、支持亿级消息堆积能力。 6.提供丰富的消息机制，如顺序消息、事务消息等 MQ基本概念： Message :消息，消息队列中信息传递的载体。 Message ID :消息的全局唯一标识，由 MQ 系统自动生成，唯一标识某条消息。 Message Key :消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。 Topic :消息主题，一级消息类型，通过 Topic 对消息进行分类。 Tag :消息标签，二级消息类型，用来进一步区分某个 Topic 下的消息分类。 Producer :消息生产者，也称为消息发布者，负责生产并发送消息。 Producer ID ：一类 Producer 的标识，这类 Producer

消息轨迹 1. 消息轨迹数据关键属性 Producer端 Consumer端 Broker端 生产实例信息 消费实例信息 消息的Topic 发送消息时间 投递时间,投递轮次 消息存储位置 消息是否发送成功 消息是否消费成功 消息的Key值 发送耗时 消费耗时 消息的Tag值 2. 支持消息轨迹集群部署 2.1 Broker端配置文件 这里贴出Broker端开启消息轨迹特性的properties配置文件内容： brokerClusterName=DefaultCluster brokerName=broker-a brokerId=0 deleteWhen=04 fileReservedTime=48 brokerRole=ASYNC_MASTER flushDiskType=ASYNC_FLUSH storePathRootDir=/data/rocketmq/rootdir-a-m storePathCommitLog=/data/rocketmq/commitlog-a-m autoCreateSubscriptionGroup=true ## if msg tracing is open,the flag will be true traceTopicEnable=true listenPort=10911 brokerIP1=XX.XX.XX.XX1 namesrvAddr

前言 这篇文章以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

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建立连接

RocketMQ初步应用架构理论 写给RocketMQ架构应用入门，内容涉及它的设计机理以及推到出来的应用注意事项，入门人员请看。 稍微涉及技术细节，留以我设计中间件时参考，将来整理深度文档时会抽取走，入门人员可以无视。 以下RocketMQ简称为RQ，理论部分采用版本为3.2.4，测试部分采用版本为3.2.6。 MQ的需求 我们对MQ的需求，相比JMS标准有几点要求更高： 1. 必须优美灵活地支持集群消费。 2. 尽量支持消息堆积。 3. 服务高可用性和消息可靠性。 4. 有起码的运维工具做集群管理和服务调整。 其他 提供顺序消息、事务、回溯等面向特别场景的功能更好，目前暂不需要。 RQ架构 RQ的基本组成包括nameserver、broker、producer、consumer四种节点，前两种构成服务端，后两种在客户端上。 还有其他辅助的进程，不提。 NameServer的基本概念 在没有NameServer的中间件中，服务端集群就由干活的broker组成 ，其中的实例分主从两种角色。那么客户端就要知道，需要连接到哪个地址的broker上去做事情，于是客户端就需要配置服务端机器的IP地址，如果服务端部署结构复杂，客户端的配置结构也挺复杂，更讨厌的是甚至可能需要客户端也得更新地址配置。由于有了两种思路的方案： 一是引入NameServer，负责提供地址

假如有一个文章审核，通过后加积分的需求，审核是这个方法的主体，而加积分并不需要实时同步，这时，我们就可以将加积分的功能变为异步执行。 Spring实现异步的方法 1.AsyncRestTemplate https://blog.csdn.net/jiangchao858/article/details/86709750 2.@Async注解 https://spring.io/guides/gs/async-method/ 3.WebClient(Spring 5.0引入) https://docs.spring.io/spring/docs/5.1.8.RELEASE/spring-framework-reference/web-reactive.html#webflux-client 4.MQ 引入MQ后，生产者生产消息，然后将消息发送给MQ，消费者监听这个消息所属的topic，一旦接收到消息，就进行相关的处理。 MQ的适用场景 1.异步处理：不解释 2.流量削峰填谷：例如秒杀活动，可以用MQ控制参加人数，人数一旦达到阈值，就丢弃请求或跳转到错误页。防止应用被流量洪峰打死。 3.解耦微服务：假如A调用B，B挂了，虽然有sentinel可以保护A不被B拖死，但是依然无法正常返回，用MQ以后，A把消息发给MQ，就算B挂了也没事，后面B恢复正常会从MQ中拿消息处理，AB也解耦了。

安装 安装maven： 1、wget http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo -O /etc/yum.repos.d/epel-apache-maven.repo 获取yum源 2、sed -i s/\$releasever/6/g /etc/yum.repos.d/epel-apache-maven.repo 修改yum源文件，$releasever替换成6 3、yum install -y apache-maven 安装jdk1.8 （yum install java-1.8.0-openjdk*） 安装RocketMQ：(4G内存+1.5G虚存)512M虚存不够 安装时间25-30min左右 1、wget https://archive.apache.org/dist/rocketmq/4.6.0/rocketmq-all-4.6.0-source-release.zip 2、unzip rocketmq-all-4.6.0-source-release.zip 3、cd rocketmq-all-4.6.0-source-release 4、mvn -Prelease-all -DskipTests clean install -U 启动 环境变量 1、vim

转载自：http://www.coin163.com/good/blog/mq.html 几种MQ产品说明： ZeroMQ : 扩展性好，开发比较灵活，采用C语言实现，实际上他只是一个socket库的重新封装，如果我们做为消息队列使用，需要开发大量的代码 RabbitMQ :结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护 ActiveMQ : 历史悠久的开源项目，已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多）.，支持持久化到数据库，对队列数较多的情况支持不好，不过我们的项目中并不会建很多的队列. Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展 RocketMQ : 阿里巴巴的MQ中间件，在其多个产品下使用，并能够撑住双十一的大流量，他并没有实现JMS规范，使用起来很简单。部署由一个 命名服务（nameserver）和一个代理（broker）组成，nameserver和broker以及producer都支持集群，队列的容量受机器硬盘的限制，队列满后可以支持持久化到硬盘（也可以自己适配代码，将其持久化到NOSQL数据库中），队列满后会影响吞吐量，可以采用主备来保证稳定性，支持回溯消费

一、rocketMQ是什么 rocketmq是一款低延迟、高可靠、可伸缩、已使用的消息中间件。具有以下特性： 1、支持发布/订阅、点对点（p2p）消息模型 2、同一个队列中支持先进先出（FIFO）和严格的顺序传递 3、支持拉（pull）和推（push）两种消息模式 4、单一队列百万消息的堆积能力 5、支持多种消息协议，比如： JMS 、MQTT 6、分布式高可用的不是架构，满足至少一次消息传递语义 7、提供docker 镜像用于隔离测试和云集群部署 8、提供配置、指标和监控功能丰富的Dashboard 二、专业术语 1、producer 　　生产者、作用是将消息发送到MQ 2、producer group 　　生产者组，多个发送同一类消息的生成者简称为一个生产者组 3、consumer 　　消费者、消费MQ上的消息 4、consumer group 　　消费者组，消费同一类型消息的多个consumer简称一个消费者组 5、topic 　　是一种消息的逻辑分类，比如：订单相关的消息存储在一个topic中、库存相关的消息存储在同一个topic中 6、message 　　是消息的载体，一个message必须指定topic，相当于寄信地址。message还可以设置一个tag 比便于消费者可以基于tag进行过滤消息 7、tag 　　标签，可以被认为是对topic的进一步细化