RocketMQ

MQ 消息队列中间件，主要解决异步信息，应用解耦，流量削锋；
1、异步处理
例：用户注册后，写入消息队列后进行发送，需发送邮件和短信；
2、应用解耦
例：订单系统写入消息队列，调用库存系统（订阅）；
3、流量削锋
例：用户请求->消息队列<-根据规则进行秒杀 只处理10个请求

JMS模型
1、P2P 点对点模式
消息队列（Queue） 发送者（Sender） 接收者（Receiver）
每个消息发送到特定队列，接收者从队列中获取，队列保留消息，知道被消费或超时；
特点：
1.每个消息只有一个消费者，一旦消费，消息就不在队列中
2.发送者和接收者没有时间依赖
3.接收者在成功接收后向队列应答成功
PS：如果每个消息被成功处理，那么需要P2P。

2、Pub/Sub 发布订阅模式
主题（Topic） 发布者（Pub） 订阅者（Sub）
发布者将消息发送到Topic，系统将这些消息传递给多个订阅者
特点：
1.每个消息可以有多个消费者
2.发布者和订阅者有时间依赖，针对某个主题的订阅者，它必须创建一个订阅之后才能消费发布消息
3.为了消费消息，订阅者必须保持运行状态

RocketMQ

1、专业术语

• Producer
  消息生产者，负责产生消息，一般由业务系统负责产生消息。

• Consumer
  消息消费者，负责消费消息，一般是后台系统负责异步消费。

• Push Consumer
  Consumer 的一种，应用通常向 Consumer对象注册一个 Listener接口，一旦收到消息，Consumer对象立刻回调Listener接口方法。

• Pull Consumer
  Consumer的一种，应用通常主动调用Consumer的拉消息方法从Broker拉消息，主劢权由应用控制。

• Producer Group
  一类Producer的集合名称，这类Producer通常发送一类消息，且发送逻辑一致。

• Consumer Group
  一类Consumer的集合名称，这类Consumer通常消费一类消息，且消费逻辑一致。

• Broker
  消息中转角色，负责存储消息，转发消息，一般也称为Server。在 JMS规范中称为Provider。

• 广播消费
  一条消息被多个Consumer消费，即使返些Consumer属于同一个Consumer Group，消息也会被Consumer Group中的每个Consumer都消费一次，广播消费中的Consumer Group概念可以认为在消息划分方面无意义。 在CORBA Notification规范中，消费方式都属于广播消费。在JMS规范中，相当于JMS publish/subscribe model

• 集群消费
  一个 Consumer Group 中的 Consumer 实例平均分摊消费消息。例如某个 Topic 有 9 条消息，其中一个Consumer Group有3个实例（可能是3个进程，或者3台机器），那么每个实例只消费其中的3条消息。 在CORBA Notification规范中，无此消费方式。 在JMS规范中，JMS point-to-point model与之类似，但是RocketMQ的集群消费功能大等于PTP模型。因为RocketMQ单个Consumer Group内的消费者类似于PTP，但是一个Topic/Queue可以被多个Consumer Group消费。

RocketMQ是什么？

• 是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。
  Producer、Consumer、队列都可以分布式Producer 吐一些队列轮流収送消息，队列集合称为 Topic，Consumer 如果做广播消费，则一个 consumer实例消费返个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费返个topic对应的队列集合。
• 能够保证严格的消息顺序 。
• 实时的消息订阅机制 。

物理部署结构

 Name Server 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
 Broker 部署相对复杂，Broker 分为 Master 和 Slave，一个 Master 可以对应多个 Slave，但是一个 Slave 只能对应一个 Master。
 BrokerId为 o 表示 Master，非 o 表示 Slave。Master 也可以部署多个。每个 Broker 和 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server。
 Producer 和 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 获取 Topic 路由信息，并向提供 Topic 服务Master 建立长连接，定时向 Master 发送心跳。Producer 完全无状态，可集群部署。
 Consumer 不 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的Master、Slave 建立长连接，丏定时吐 Master、Slave 収送心跳。Consumer既可以从 Master 订阅消息，也可以从 Slave 订阅消息，订阅规则由 Broker 配置决定。

数据存储结构

（1）消息主体以及元数据都存储在CommitLog当中
（2）Consume Queue是一个逻辑队列，存储了这个Queue在CommiLog中的 起始offset，log大小 和MessageTag的hashCode。
（3）每次读取消息队列先读取consumer Queue,然后再通过consumerQueue去commitLog中拿到消息主体。
Consume Queue类似于索引，可以通过Consume Queue找到真正的数据。

同步刷盘和异步刷盘：
RocketMQ 的所有消息都是持久化的，先写入系统 PAGECACHE，然后刷盘，可以保证内存和磁盘都有一份数据，访问时，直接从内存读取。
异步刷盘写完 PAGECACHE 直接返回，而同步刷盘需要等待刷盘完成才返回

异步复制和同步双写：
同步双写方式，主备都写成功，向应用返回成功。