- 1.RocketMQ的物理架构
- 1.1 NameServer
- 1.2 Broker
- 1.3 Producer
- 1.4 Consumer
- 1.5 Message
- 2.Rocket概念模型
- 2.1 Group
- 2.2 Topic
- 2.3 Tag
- 2.4 Message Queue
- 2.5 Offset
- 3.Rocket支持的各种消息
- 3.1 消息发送的方式
- 3.2 消息的消费方式
- 3.3 普通消息
- 3.4 顺序消息
- 3.5 延时消息
- 3.6 批量消息
- 3.7 事务消息
RocketMQ是阿里巴巴的一款开源产品，性能可以和kafka相媲美，在业务开发领域非常好用。RocketMQ基于发布订阅模型，提供了丰富的功能和多功能消息。
NameServer是RocketMQ的元数据管理中心、注册中心。所以RocketMQ需要首先启动NameServer，再启动其它的Broker节点。
Broker在启动的时候向所有的NameServer节点注册，Producer在发送消息之前首先向NameServer获取Broker服务地址列表，然后通过一定的负载算法进行消息发送。Consumer消费逻辑也一样。
NameServer与每台Broker服务保持长链接，每30S检查Broker是否存活，如果检测到Broker宕机，则从路由表中踢出。
RocketMQ暂存、持久化、传输消息的节点。
1.3 Producer生产者，负责消息的产生和发送。
1.4 Consumer消费者，负责对消息的接收和消费。
1.5 Message消息本身，对于RocketMQ而言，底层就是一个字节数组。
2.Rocket概念模型 2.1 Group对于生产者而言，分组用来标识同一类消息的Producer，仅做标识使用，没有特别的意义，RocketMQ的生产者Group更多是在事务消息会用到(Broker回查，遇到Producer宕机可以选择Producer同一个组的生产者回查消息是否提交or回滚。)
对于消费者而言，标识一类Consumer的集合。同一个Consumer Group的各个实例将共同消费Topic的消息，可以起到负载均衡的作用。组间共享，组内竞争。
消费进度是以Consumer Group为单元管理，不同的消费者组的消费进度彼此不受影响。
标识一类消息的逻辑标识，无论生产者和消费者都要指定Topic。
2.3 Tag消息的二级分类。
2.4 Message Queue管理消息的物理单元，一个Topic主题有若干个消息队列，如果一个Topic创建在不同的Broker上，则不同的Broker上都有若干个消息队列。每一个消息队列都对应了一个文件，该文件提供了存储实际消息索引的信息。
Message Queue是一个逻辑无限长的数组，
偏移量的概念在RocketMQ中很多，但是一般特Message Queue中的消费偏移量。
3.Rocket支持的各种消息 3.1 消息发送的方式 - 同步发送：可靠的一种发送方式，需等待消息同步响应后才能成功。
- 异步发送：异步方式进行消息发送，可通过回调函数来处理失败的业务。
- 单向发送：Producer只负责发送消息，不负责服务器响应和回调。
3.2 消息的消费方式
- 集群消费：同一个消息只会分给一个Group消费者组的某一台客户端进行消费。
- 广播消费：同一个消息会给消费者组里面每一个客户端都投递消息进行消费。
3.3 普通消息
3.4 顺序消息
RocketMQ本身没有提供顺序消息的功能，但是可以借助一个方式来实现消息的顺序性。消息的顺序性分为：全局顺序、局部顺序。
全局顺序：如果生产者和消费者参与的Message Queue只有一个，就能够保证全局顺序性。
局部顺序：如果生产者和消费者参与的Message Queue有多个，只能保证每一个队列里的消息能够顺序消费。
生产者发送某个消息，但是希望一段时间后消费者才能进行消费的情况。RocketMQ开源版只提供了一部分延时时间level选项，ONS商业版支持任意毫秒的延迟消息。
3.6 批量消息批量发送普通消息，能够提高整体的传输效率，但是最大也不能大于4MB。
3.7 事务消息事务消息一共有3个状态：已提交、回滚、中间态(未知)。
RocketMQ的事务消息一般用在分布式事务的最终一致性场景中。
