这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天
对课程中学到的重要知识点做了笔记，方便后续的回顾
0. 介绍
0.1 情景介绍
晚上到家，打开抖音，准备下单一件商品，中间遇到的许多问题
0.2 实际问题
0.2.1 案例一:系统崩溃
- 搜索直播间
- 搜索行为记录
- 点击商品
- 点击行为记录 在两个记录的操作中，数据库被删除了，整个链路都会卡住
0.2.2 案例二:服务能力有限
每次能同时处理10笔订单，但是实际上有很多的订单同时进来，比如
0.2.3 案例三:链路耗时长尾
- 发起订单 5ms
- 库存记录-1 100ms
- 订单记录+1 100ms
- 通知商家 30s 整个流程十分长，用户下单以后一直在转圈圈
0.2.4 案例四:日志存储
秒杀活动结束了，但是日志都丢了
0.3 解决方案
0.3.1 案例一:解决方案:解耦
将记录都先存到消息队列里面，在活动结束以后再发给存储服务
0.3.2 案例二:解决方案:消峰
先把很多的请求，比如1000笔请求，先放入消息队列中暂存，每次只获取10个请求进行处理
0.3.3 案例三:解决方案:异步
- 发起订单以后就将流程进入了消息队列中，返回下单成功
- 库存记录-1 100ms
- 订单记录+1 100ms
- 通知商家 30s
- 长耗时操作通过消息队列来并行执行
0.3.4 案例四:解决方案:日志处理
日志先打入消息队列，后面慢慢处理
0.4 什么是消息队列?
消息队列(MQ)，指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，并且高可用。
1. 前世今生
1.1 业界消息队列对比
- Kafka:分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
- RocketMQ:低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
- Pulsar:是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计
- BMQ:和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
2. 消息队列-Kafka
3. 消息队列-BMQ
4. 消息队列-RocketMQ
4.1 RocketMQ的基本概念(Queue，Tag)
4.1.1 概述
例如，针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等;同时，也会涉及许多业务峰值时刻，如秒杀活动、周年庆、定期特惠等
4.1.2 和kafka相比不同
- 多了Tag，丰富消费场景
- 多了Producer Group，为了支持事务消息
4.2 RocketMQ的底层原理
4.2.1 架构模型
整体的架构设计主要分为四大部分，分别是：Producer、Consumer、Broker、NameServer
- Producer：就是消息生产者，可以集群部署。
- Consumer：消息消费者，也可以集群部署。Master、Slave上，然后它们建立长连接，支持集群消费和广播消费消息；
- Broker：主要负责消息的存储、查询消费，支持主从部署，一个 Master 可以对应多个 Slave，Master 支持读写Slave 只支持读。Broker 会向集群中的每一台 NameServer 注册自己的路由信息；
- NameServer：是一个很简单的 Topic 路由注册中心，支持 Broker 的动态注册和发现，保存 Topic 和 Borker 之间的关系。
启动流程
先启动 NameServer 集群，各 NameServer 之间无任何数据交互，Broker 启动之后会向所有 NameServer 定期（每 30s）发送心跳包，包括：IP、Port、TopicInfo，NameServer 会定期扫描 Broker 存活列表，如果超过 120s 没有心跳则移除此 Broker 相关信息，代表下线。
4.2.2 存储模型
4.3 RocketMQ-高级特性
事务场景、事务消息、延迟发送、延迟消息、 处理失败、消费重试和死信队列
课后个人总结
- 先了解了消息队列的基本概念，知道了消息队列的主要特征，主要用在什么场景中
- 着重先了解了下RocketMQ，有许多高级的特性，可以应对各种场景
参考资料
[消息队列原理与实战]juejin.cn/post/719632… [RocketMQ 整体架构设计]blog.csdn.net/a646705816/…
