RocketMQ架构原理解析（一）：整体架构
RocketMQ架构原理解析（一）：整体架构
RocketMQ架构原理解析（二）：消息存储（CommitLog）
RocketMQ架构原理解析（三）：消息索引（ConsumeQueue & IndexFile）
RocketMQ架构原理解析（四）：消息生产端（Producer）
一、概述
RocketMQ作为一个apache的顶级项目，拥有将近16K的star，它稳定的系统及强悍的性能，无疑在国内已经成为了企业消息队列的首选。接下来的一段时间，鄙人准备出一系列文章，从源码出发，逐一剖析RocketMQ的架构设计原理
本文将仅做概念上的陈述
二、概念及模型
本文中部分概念描述搬运自github官网
RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。其他概念随着行文逐一展开。
图片搬运自官网
2.1 消息生产者（Producer）
负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。
2.2 消息消费者（Consumer）
负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。
2.3 服务器（Broker Server）
消息中转角色，负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等。
2.3 主题（Topic）
表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。
三、部署架构
图片搬运自官网
RocketMQ各模块启动顺序如下：
- 控制中心 启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心
- 服务端 Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系
- 必要环节 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic
- 客户端1-生产消息 Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息
- 客户端2-消费消息 Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息
四、消息存储
后文会逐一展开
最新文章
- python资料
- Lis日常维护
- 微信——获取用户基本信息及openid 、access_token、code
- MarkDown插入图片
- user_jj两条记录改成一条
- 文件上传小技巧/原生态【html篇】
- iOS开发-友盟分享使用（2）
- mysql：on duplicate key update与replace into
- 《JavaScript基础教程（第8版）》PDF
- mvn命令
- Qt HTTP内部构架
- SVN的学习以及使用！
- SpringMVC中Controller的方法返回值
- 基于Java的HashMap和HashSet实现
- Django知识总结(三)
- 6.7 使用show profile 进行sql分析
- css哪些属性可以继承
- Java并发程序设计（一） 基础概念
- PHP-问题处理Fatal error: Uncaught Error: Call to undefined function simplexml_load_file()
- .NET和F#周报第35周-.NET 8月重大更新