rocketmq

上一篇文章中我们介绍了一下Rocketmq的整体启动流程( https://my.oschina.net/nixi0608/blog/3185450 ),其中第一步是启动nameserver,那么nameserver启动的过程都做了什么事情，现在我们就来看下。 1.程序启动的入口 程序启动的入口,在org.apache.rocketmq.namesrv.NamesrvStartup中 public static void main(String[] args) { main0(args); } public static NamesrvController main0(String[] args) { try { NamesrvController controller = createNamesrvController(args); //2.创建NamesrvController start(controller);//3.启动namesrv String tip = "The Name Server boot success. serializeType=" + RemotingCommand.getSerializeTypeConfigInThisServer(); log.info(tip); System.out.printf("%s%n", tip); return

分布式事物2 基于rocketmq 从rocketmq的官网可以看到，它又以下几种消息类型： 1）发送同步消息 这种可靠性同步地发送方式使用的比较广泛，比如：重要的消息通知，短信通知 2）发送异步消息 异步消息通常用在对响应时间敏感的业务场景，即发送端不能容忍长时间地等待Broker的响应。 3）单向发送消息 这种方式主要用在不特别关心发送结果的场景，例如日志发送。 消息消费： 1)负载均衡模式 消费者采用负载均衡方式消费消息，多个消费者共同消费队列消息，每个消费者处理的消息不同 2）广播模式 消费者采用广播的方式消费消息，每个消费者消费的消息都是相同的 4）顺序消息 消息有序指的是可以按照消息的发送顺序来消费(FIFO)。RocketMQ可以严格的保证消息有序，可以分为分区有序或者全局有序。 顺序消费的原理解析，在默认的情况下消息发送会采取Round Robin轮询方式把消息发送到不同的queue(分区队列)；而消费消息的时候从多个queue上拉取消息，这种情况发送和消费是不能保证顺序。但是如果控制发送的顺序消息只依次发送到同一个queue中，消费的时候只从这个queue上依次拉取，则就保证了顺序。当发送和消费参与的queue只有一个，则是全局有序；如果多个queue参与，则为分区有序，即相对每个queue，消息都是有序的。 5）延时 比如电商里

rocketMQ通过将消息发送给指定的队列来实现顺序发送 Producer package com.wk.test.rocketmqTest.shunxu; import org.apache.rocketmq.client.exception.MQBrokerException; import org.apache.rocketmq.client.exception.MQClientException; import org.apache.rocketmq.client.producer.DefaultMQProducer; import org.apache.rocketmq.client.producer.SendResult; import org.apache.rocketmq.common.message.Message; import org.apache.rocketmq.remoting.exception.RemotingException; import java.util.ArrayList; import java.util.List; import java.util.UUID; public class Producer { public static void main(String[] args) { DefaultMQProducer

公司介绍 广东省安心加科技有限公司是一家专注于地产行业智能化和物联网领域，集研发、销售、咨询、设计、实施、运维于一体的高科技公司，运用物联网、云计算、大数据、人工智能等技术，自主研发核心产品与整合行业资源，通过掌握核心技术，打造安全、便捷、智慧、开放的安心加物联平台，广泛服务于家庭、社区、长租公寓、楼宇、园区、酒店、商业、校园等场景，形成一整套完整的智慧解决方案体系，为地产全业态的营销、管理和运营全面赋能。通过安心加物联平台，解决不同品牌、不同品类、不同协议的互联互通问题，运用统一的标准部署前端设备应用，实现大数据的归集与分析，为客户提供“云+边+端”的一体化全链式智能场景解决方案，为各类不同的用户场景和业务赋能。目前，安心加科技已经成功布局全国7大区域31个省份和4个海外国家，成功实现超1800个项目的智能化落地与升级，超200万智能硬件终端接入安心加平台，并为超130万使用安心加APP的用户提供智慧生活服务 业务痛点 我司业务模块多，而业务模块的访问和协议相对分散，集中管理成本大。 业务数据和设备日志数据指数级增长，自建数据服务和管理成本。 智能终端量大，对于数据交互和响应速度实时性要求高，需要高性能的服务能力。 解决方案 解决方案逻辑图 方案细节： 通过阿里云APIGateway，统一内部系统个业务接口规范，形成一套标准化的AP体系。 借助阿里云低成本、高可靠的oss存储服务

在上一篇文章中,我们说到了Rocketmq的基本概念( https://my.oschina.net/nixi0608/blog/3183063 ),那么今天我们来说下,Rocketmq的启动流程,这也是以后分析整个Rocketmq源码的整体思路 总体启动流程 PS:该图来源于Rocketmq官网 通过上图,我们可以看到Rocketmq的启动流程有以下几个步骤 1.启动NameServer 在上一篇文章中，我们说过Rocketmq中的NameServer类似于一个注册中心,它里面包含基本的路由信息 2.启动Broker 从启动图上可以看出Broker在启动以后,会向NameServer注册一些信息,哪些信息呢?例如broker自己的ip,topice信息等等。 3.创建topic topic 是Rocketmq的最小单元,换句话说,你如果想玩Rocketmq,最起码要把它先搞出来。就像人体有细胞组成,没有细胞哪来的人体 4.启动Producer Producer是为了发送消息，那么在发送消息之前，会先从本地获取对应的路由信息，如果获取不到就从NameServer上拉取，其中有个比较重要点就是怎么规避异常的Broker(Rockermq对这个进行了特别的处理) 5.启动Consumer Consumer向NameServer发送请求，获取当前订阅Topic存在哪些Broker上

基本概念 1 消息模型（Message Model） RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成。 2 消息生产者（Producer） 负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。 3 消息消费者（Consumer） 负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。 4 主题（Topic） 表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题

生产者（Producer） 负责产生消息,Rocketmq提供多种发送方式(同步发送,异步发送,单向发送) 站在生产者的角度来看 同步发送:需要等待发送结果的返回。 异步发送:不需要等待发送结果的返回,完成发送消息以后可以回调本地的方法来做业务逻辑. 单向发送:不需要等待发送结果的返回。 站在Broker的角度来看 无论那种发送消息的方式，最后都是Broker来存储的,在存储的时候,有两个比较关键的处理. 第一:根据配置文件,可以选择全局性的同步刷盘或者异步刷盘 第二:在配置了全局同步刷盘的前提下,又允许每个消息自己设置是否需要同步刷盘 消费者(Consumer) 负责消费消息，RocketMq提供了两种消费形式：拉取式消费、推动式消费。 拉取式消费 应用主动从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。 推动式消费 Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高 主题（Topic） 每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息消费的最小单元（意思就是说消费消息的时候必须根据主题来）。 Broker Server 负责存储消息和以及一些查询消息的功能。 Name Server 提供消息的路由服务,客户端查根据topic能够查询到Broker的地址列表 Producer Group

下图是从官网摘过来的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