rocketMq-Topic创建过程

rocketMq概念介绍

rocketMq-namesrv介绍

rocketMq-Topic创建过程

rocketMq-producer介绍

rocketMq-consumer介绍

rocketMq - rebalance介绍

rocketMq - 并发消费过程

rocketMq - 串行消费过程

rocketMq-broker介绍

rocketMq-broker消息存储介绍

rocketMq - commitLog

rocketMq - index介绍

rocketMq-延迟消息介绍

rocketMq-事务消息介绍

rocketMq消息查询

rocketMq和kafka的架构区别

rocketMq - master/slave同步

Topic可以理解为在rocketMq体系当中作为一个逻辑消息组织形式，一般情况下一类业务消息会申请一个topic来实现业务之间隔离。

说明：

    该图分享自：  RocketMQ概念模型

    Topic是一个逻辑上的概念，实际上在每个broker上以queue的形式保存，也就是说每个topic在broker上会划分成几个逻辑队列，每个逻辑队列保存一部分消息数据，但是保存的消息数据实际上不是真正的消息数据，而是指向commit log的消息索引。

    Topic创建的时候可以用集群模式去创建（这样集群里面每个broker的queue的数量相同），也可以用单个broker模式去创建（这样每个broker的queue数量可以不一致）。

    每个broker上的角色是等同的，也就是说每个broker上面的queue保存了该topic下一部分消息，注意是一部分而不是全量消息。

说明：

    在rocketMq编译后的bin目录下有一个mqadmin的工具，该工具作为rocketMq的CLI工具对外提供，使用时候可以通过sh mqadmin -h 或者sh mqadmin command -h查看用法。

    updateTopic和deleteTopic是实际中 *** 作topic的命令。

说明：

    创建topic需要指定的参数，

    -b 指定broker上创建topic

    -c 指定cluster创建topic

    -n 指定namesrv地址，cluster模式下必须从namesrv获取broker地址

    -t topic的名字标志

    -r/w 读写队列的个数，建议相等

    -p queue的读写权限

    -o 待研究不确定是不是保证全局有序消息的配置

说明：

    topic的创建过程涉及到3个组件，分别是mqadmin、broker、namesrv。

    整个创建过程是mqadmin->broker->namesrv。

    mqadmin通知broker创建topic和对应的queue信息。

    broker转发通知namesrv保存topic和broker的原信息，同时在本地持久化一份topic配置。

    broker在这个时候不真正创建本地的队列信息

说明：

    参见 UpdateTopicSubCommand类

    注册参数和updateTopic显示帮助是一致的

说明：

    支持cluster模式下创建topic和支持broker模式下创建topic

说明：

    通知broker创建topic。

说明：

    集群模式下首先通过namesrv获取所有的broker的master地址，然后通知每个broker去创建topic，每个broker的创建过程跟指定单个broker是一致的。

说明：

    参见AdminBrokerProcessor类

说明：

    broker本地通过updateTopicConfig保存topic的配置信息并持久化

    broker通过registerBrokerAll通知namesrv保存topic信息

说明：

    broker通知namesrv注册该broker下的topic信息，具体的namesrv地址是在registerBrokerAll内部访问namesrv获取的。

说明：

    参见DefaultRequestProcessor类

说明：

    参见DefaultRequestProcessor类

说明：

    参见RouteInfoManager类

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 ：给生产和消费者提供路由信息，提供轻量级的服务发现、路由、元数据信息，可以多个部署，互相独立（比zookeeper更轻量）

Offset : 偏移量，可以理解为消息进度

commit log : 消息存储会写在Commit log文件里面

1、添加maven依赖

2、新建jms包，JMSConfig类，设置配置常量

3、新建生产者PayProducer

4、新建PayController

这个时候，启动应用，访问api/sync路径，会报没有这个topic异常

需要去管控台手工创建topic，或者将SpringBoot依赖的RocketMQ版本与服务端RocketMQ的版本改成一样的，也可以。例如我的pom.xml文件中，依赖的版本是4.3.0，而服务器上部署的RocketMQ版本是4.4.0，就不会自动创建topic。

创建topic之后，再次访问访问api/sync路径，会报下面异常

在conf/broker.conf文件中添加如下配置

然后指定配置文件启动Broker，返回上一级，然后重启Broker

或者使用守护进程方式启动Broker

再次访问api/sync，返回成功

RocketMQ管控台也可查询此消息

新建PayConsumer

访问： http://localhost:8080/api/sync?text=test

控制台打印：

---