这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
一、案例介绍
案例一: 系统崩溃
案例一解决方案:
案例二: 服务能力有限
案例二解决方案:
案例三: 链路耗时较长
案例三解决方案:
案例四: 日志存储
日志处理
案例四解决方案:
二、消息队列的前世今生
什么是消息队列 消息队列(MQ), 只保存消息的一个容器,本质是一个队列. 但这个队列支持高吞吐,高并发,并且高可用
消息队列的发展历程
消息中间件其实诞生的很早，早在1983年互联网应用还是一片荒芜的年代，有个在美国的印度小哥Vivek就设想了一种通用软件总线，世界上第一个现代消息队列软件The Information Bus(TIB)，他 TIB受到了企业的欢迎，这家公司的业务发展引起了当时最牛气的IT公司IBM的注意，于是他们一开始研发了自己消息队列软件，于是才有了后来的wesphere mq，再后来微软也加入了战团。接近2000年的时候，互联网时代已经初见曙光，全球的应用程序得到了极大地丰富，对于程序之间互联互通的需求越来越强烈，但是各大IT公司之间还是牢牢建立着各种技术壁垒，以此来保证自己的商业利益，所以消息中间件在那个时候是大型企业才能够用的起的高级玩意。 但是时代的洪流不可逆转，有壁垒就有打破壁垒的后来者，2001年sun发布了jms技术，试图在各大厂商的层面上再包装一层统一的java规范。java程序只需要针对jms api编程就可以了，不需要再关注使用了什么样的消息中间件，但是jms仅仅适用于java。2004年AMQP（高级消息队列协议）诞生了，才是真正促进了消息队列的繁荣发展，任何人都可以针对AMQP的标准进行编码。有好的协议指导，再加上互联网分布式应用的迅猛发展成为了消息中间件一飞冲天的最大动力，程序应用的互联互通，发布订阅，最大契合了消息中间件的最初的设计初衷。除了刚才介绍过的收费中间件，后来开源消息中间件开始层出不穷，常见比较流行的有ActiveMQ、RabbitMQ 、Kafak、阿里的RocketMQ，以及目前存算分离的Pulsar，在目前互联网应用中消息队列中间件基本上成为标配。
业内消息队列对比
以下几个消息队列是业内比较流行的几种
三、消息队列 -- RocketMQ
使用场景
- 削峰填谷: 应对如秒杀等大型活动时带来较高的流量冲击，如果没做相应的保护，将导致系统超负荷甚至崩溃。如果接口限制太过导致大量请求失败而影响用户体验，利用MQ 超高性能的消息处理能力来解决此类问题。如果redis是针对分布式缓解大量读，那么rocketmq是应对大量写场景的利器
- 异步解耦: 通过mq完成上、下游业务系统的松耦合设计，服务部分节点异常都不会影响到核心交易系统的正常运转，还可以通过mq重试队列实现异常重试处理。
- 顺序消息: MQ提供的顺序消息（分区有序）即保证消息的先进先出，可以应用于交易系统中的订单创建、支付、退款等流程。
- 分布式事务消息: 分布式业务场景需要引入 MQ 的分布式事务，既实现了系统之间的解耦，又可以保证最终的数据一致性。将大事务拆分成多个小事务，减少系统间的交互，既高性能又可靠。再利用MQ 的Ack确认机制保证可靠传输与多副本技术确保消息不丢最终确保数据的最终一致性。
- 订单通知发货: 重试队列可以重试16次，可以减少频繁访问数据库
- 订单超时取消: 延时队列
- 定时消息: 延时队列实现指定时间开启活动通知
- 异常处理告警: 订单发货通知重试超过上限进入到死信队列短信微信通知人工处理
基本概念
Kafka和RocketMQ对比:
基本架构
存储模型
RocketMQ的高级特性
- 事务场景
在这个下单场景正常情况下，这个下单的流程应该是这个样子，首先我保证库存足够能够顺利-1，这个时候再消息队列让我其他系统来处理，比如订单系统和商家系统，但这里有个比较重要的点，我库存服务和消息队列必须要是在同一个事务内的，事务的基本特性是ACID，这里库存记录和往消息队列里面发的消息这两个事情，是需要有事务保证的，这样不至于发生，库存已经-1了，但我的订单没有增加，或者商家也没有收到通知要发货。因此RocketMQ提供事务消息来保证类似的场景
- 事务消息
RocketMQ支持事务消息,原理图如下:
- 延迟发送
- 延迟消息
- 消费重试和死信队列
