RocketMQ

踩坑

多端口监听（broker.conf）

在RocketMQ中，可以通过 broker.conf 配置文件中指定 listenPort 配置项来指定 Broker 监听客户端请求的端口，如果不指定，默认监听 10911 端口

在 Broker 启动时，实际上会监听 3 个端口：10909、10911、10912

延时消息样例

比如12306买高铁票时，延时支付

事务型消息

异步消息

• 
  两阶段提交
• 
  回查机制
• 
  保证最终一致性
• 
  MQ Server 就是 Broker

1. MQ Producer 发送一个 half 消息给 Broker，相当于一个动作预告消息
2. Broker 收到 half 消息后，返回一个确认信息给 MQ producer
3. MQ producer 访问 MySQL，本地执行事务
4. 若事务提交成功，MQ Producer 则 commit 消息，若事务提交失败，则 rollback 消息
5. 如果 MQ Producer 丢失消息，Broker 就会执行回查机制，会对 MQ Producer 进行 check
6. MQ Producer 会 check MySQL，检查 MySQL 事务是否提交成功
7. 检查无误后，MQ Producer 会重新 commit / rollback 消息
   • 若回查消息继续丢失，只要 Broker 中收到的是 half 消息，就会一直进行回查机制
   • 如果回查次数过多，或者时间过久，那么该消息会进入死信队列

1. Broker 会根据 MQ Producer 发送的 commit / rollback 消息，来通知 MQ Consumer 是否进行消费

秒杀业务（异步扣减）

1. 走缓存判断是否命中
2. 判断商品是否售罄
3. 生成库存流水、消息体
4. MQ Producer发送消息给Broker
5. 本地MySQL开始执行事务 -> @RocketMQTransactionListener
6. 缓存预减库存，生成订单，更新流水
7. 异步发送销量更新消息给MQ Consumer
8. 本地事务提交成功，Broker通知MQ Consumer进行消费（更新销量、扣减库存）
9. MQ Consumer消费成功（扣减库存成功、更新销量成功）

消息可靠性

RocketMQ 支持消息的可靠性，影响消息可靠性的几种情况：

1. Broker 非正常关闭
2. Broker 异常 宕机
3. OS 宕机
4. 机器掉电，但是能立刻恢复供电情况
5. 机器无法开机
6. 磁盘设备损坏

削峰限流

验证码

请求之前，增加验证码验证，增加输入点击时间，平滑流量

大闸

增加大闸，限制令牌的数量，即限制入围秒杀的人数

限流器

限流器是为了保证服务器的稳定，一次性只放入服务器能够承受的访问量

令牌桶算法

令牌桶算法可以处理突发大量请求（突发流量）

1. 限流器初始化令牌桶
2. 令牌生成器每秒生成 N 个令牌到令牌桶中，桶满则弃多余令牌
3. 业务通过限流器获取令牌，令牌桶中的令牌数 -1

漏桶算法

漏桶算法的话，可以保证服务器持续稳定

队列（线程池）

增加服务器缓冲能力