这是我参与「第五届青训营 」伴学笔记创作活动的第10天。
使用消息队列的四个案例
-
系统崩溃： 记录存储程序的数据库崩溃，使用消息队列解耦。
-
服务能力有限： 大量请求被发起，但订单服务只能同时处理10个订单请求，使用消息队列削峰。
-
链路耗时长尾： 提交订单后，某一步耗时过长，使用消息队列异步处理。
-
日志存储： 服务器突然坏掉，本地日志丢失，使用消息队列交给日志处理组件。
什么是消息队列？
消息队列(MQ) ，指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，井且高可用。
RocketMQ
使用场景
例如，针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等；同时，也会涉及许多业务峰值时刻，如秒杀活动、周年庆、定期特惠等。
RocketMQ架构
先说数据流也是通过Producer发送给Broker集群，再由Consumer进行消费，Broker节点有Master和Slave的概念，NameServer为集群提供轻量级服务发现和路由。
对于一个Broker来 说所有的消息的会append到一个CommitLog 上面，然后按照不同的Queue,重Dispatch到不同的Consumer中，这样Consumer就可以按照Queue进行拉取消费，但需要注意的是，这里ConsumerQueue所存储的并不是真实的数据，真实的数据其实只存在CommitLog中，这里存的仅仅是这个Queue所有消息在CommitLog上面的位置，相当于是这个Queue的一个密集索引。
RocketMQ高级特性
先看一下我们最开始说的这个场景，正常情况下， 这个下单的流程应该是这个样子，首先我保证库存足够能够顺利-1,这个时候再消息队列让我其他系统来处理，比如订单系统和商家系统，但这里有个比较重要的点，我库存服务和消息队列必须要是在同一个事务内的，事务的基本特性是ACID, 这里库存记录和往消息队列里面发的消息这两个事情，是需要有事务保证的，这样不至于发生，库存已经-1了，但我的订单没有增加，或者商家也没有收到通知要发货。因此RocketMQ提供事务消息来保证类似的场景。
- 事务场景
- 事务消息
- 延迟发送
- 处理失败
- 消费重试和死信队列
