学而不思则忘

简介 RocketMQ整体架构设计 Producer：消息生产者 Consumer：消息消费者 NameServer：查询各个Topic对应的Broker IP列表 BrokerServer：存储消息

一、概要 RocketMQ采用了2PC的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息 所以，事务消息大致分两个流程：正常事务消息的发送及提交、事务消息的补偿流程 1.1

概要 消息有序指的是可以按照消息的发送顺序来消费(FIFO)。RocketMQ可以严格的保证消息有序，可以分为分区有序或者全局有序。 顺序消费的原理解析，在默认的情况下消息发送会采取Round Rob

1. 为什么要使用MQ 1.1 流量削峰 使用消息队列做缓冲。假设一个订单系统最多能处理一万个订单，当订单数量超过一万个后，只能限制超过一万后不允许用户下单。这时可以用MQ做缓冲，把一秒内下的订单分散

1. 使用场景 在淘宝购物车下单时，涉及到购物车系统和交易系统，这两个系统之间的数据最终一致性可以通过分布式事务消息的异步处理实现。在这种场景下，交易系统是最为核心的系统，需要最大限度地保证下单成功。

1. 消息发送方式 1.1 同步消息 消息发送进入同步等待状态，保证消息一定到达 1.2 异步消息 1.3 单向消息 只发消息，不等待服务器响应。 通常消息的发送是这样一个过程： 客户端发送请求到服务

在大多数情况下，TAG是一个简单而有用的设计，其可以来选择您想要的消息。例如： 消费者将接收包含TAGA或TAGB或TAGC的消息。但是限制是一个消息只能有一个标签，这对于复杂的场景可能不起作用。在这

发送延时消息 消费消息 验证 消息的消费比存储时间晚10秒。 ####　延时消息的使用场景 比如电商里，提交了一个订单就可以发送一个延时消息，1h后去检查这个订单的状态，如果还是未付款就取消订单释放库

基本通信流程 Broker启动后需要完成一次将自己注册至NameServer的操作；随后每隔30s时间定时向NameServer上报Topic路由信息。 消息生产者Producer作为客户端发送消息时