消息队列概述
- 在分布式系统和微服务架构中，消息队列（Message Queue）是一个核心组件，用于在不同的应用程序或服务之间异步传递消息
- 在 Go 语言中，有多种实现消息队列的方式，包括使用开源的消息队列服务（如 RabbitMQ、Kafka、RocketMQ）和 基于 Go 语言的消息队列库
消息队列的基本概念
- 消息队列允许生产者（Producer）将消息发送到队列中，而消费者（Consumer）则可以从队列中获取消息进行处理
- 消息队列具有以下特性：
- 异步处理：生产者和消费者无需实时连接，允许异步地处理和分发消息。
- 解耦：通过消息队列，服务之间可以解耦，降低系统间的耦合度。
- 流量削峰：在高峰时段，消息队列可以缓存消息，避免系统过载。
- 可靠性：消息队列通常具有持久化机制，确保消息不会丢失。
常用消息队列的对比
1 ）RocketMQ、 kafka、 RabbitMQ
|-------|------------------|------------------|-------------------|
| | RocketMQ | kafka | RabbitMQ |
| 时效性 | ms级别 | 在ms级以内 | 微妙级 |
| 单机吞吐量 | 10万级 | 10万级 | 万级别，比前面2个小一个量级 |
| | 几百，几千的级别 | 几百，几千的级别 | |
| 可用性 | 非常高 分布式架构(大多数保证) | 非常高 分布式架构(大多数保证) | 高 (主从架构实现高可用) |
| 消息可考证 | 待优化后保证 | 待优化后保证 | |
| 支持 | 较完善，分布式，扩展好 | 实时计算，日志采集 | erlang并发强 性能好 低延时 |
- 选择：kafka 和 rocketmq 都是 java 生态，rabbitmq 是 erlang 生态，所以 后者被排除，遇到问题，怕很难解决
- kafka 偏 日志 和 实时计算，所以现在 还剩 rocketmq
- 选择合适自己的消息队列，在生产环境，独立部署一套
- 可以先在一台单独的机器上测试
- 现在选择并部署，在生产环境压一下，整个全链路压测多少时间，这样就可以推断出在每一个节点需要多少资源
- 做活动的时候，按照基础评估，增加主从集群配置
- MQ的缺点
- 稳定性：宕机，业务就挂了，要保证高可用
- 复杂性：原来一个服务器内搞定的事情，现在要异步调用，消息丢失怎么办？消息顺序如何保证？重复消费怎么办？
- 一致性: 分布式系统中，多个系统，如果一个系统挂了，如何保证消息处理的一致性，这里涉及到分布式事务，后续继续深入学习
- 所以，MQ 是需要做集群的，如果单点挂了，就挂了...
2 ）使用 Go 语言的消息队列库
- NSQ
- NSQ 是一个基于 Go 语言的实时分布式消息队列。它设计用于大规模分布式系统，如实时分析、日志聚合和流数据传递
- NSQ 提供了简单的 API 和丰富的功能，如发布/订阅、持久化、分布式和可扩展
- NATS
- NATS 是一个高性能、轻量级的云原生消息传递系统。
- 它使用发布/订阅模型，支持多种编程语言和平台，包括 Go。NATS 特别适用于微服务架构中的事件驱动通信。
- Go Channel
- 虽然 Go Channel 不是一个完整的消息队列服务，但它为 Go 语言中的并发编程提供了强大的支持
- 在简单的场景下，可以使用 Go Channel 来实现消息队列的功能
- 然而，对于复杂的分布式系统，使用专门的消息队列服务可能更为合适
3 ) 如何选择消息队列
- 在选择消息队列时，需要考虑以下因素：
- 性能：确保消息队列能够满足系统的性能需求。
- 可靠性：确保消息队列的可靠性，以避免数据丢失。
- 可伸缩性：随着业务的发展，系统可能需要处理更多的消息。因此，消息队列需要具有良好的可伸缩性。
- 易用性：选择易于使用和集成的消息队列服务或库。
- 成本：考虑消息队列的部署和维护成本。
RocketMQ的选择与使用
- 消息模型(Message Model)
- RocketMQ主要由Producer、 Broker、Consumer三部分组成，其中Producer负责生产消息，Consumer负责消费消息，Broker负责存储消息
- Broker 在实际部署过程中对应一台服务器，每个Broker可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的Broker
- Message Queue用于存储消息的物理地址，每个Topic中的消息地址存储于多个Message Queue中
- ConsumerGroup 由多个Consumer实例构成
1 ) 消息生产者(Producer)
- 负责生产消息，一般由业务系统负责生产消息
- 一个消息生产者会把业务应用系统里产生的消息发送到broker服务器
- RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送
- 同步和异步方式均需要Broker返回确认信息，单向发送不需要
2 ) 消息消费者(Consumer)
- 负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序
- 从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费
3 ) 主题(Topic)
- 表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位
4 ) 代理服务器(Broker Server)
- 消息中转角色，负责存储消息、转发消息
- 代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备
- 代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等
- 可以理解为 仓库
5 ) 名字服务(Name Server)
- 名称服务充当路由消息的提供者
- 生产者或消费者能够通过名字服务查找各主题相应的BrokerIP列表
- 多个Namesrv实例组成集群，但相互独立，没有信息交换
6 ) 拉取式消费(Pull Consumer)
- Consumer消费的一种类型，应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制
- 一旦获取了批量消息，应用就会启动消费过程
7 ) 推动式消费(Push Consumer)
- Consumer消费的一种类型，该模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高
8 ) 生产者组(Producer Group)
- 同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致
- 如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费
9 ) 消费者组(Consumer Group)
- 同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致
- 消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易
- 要注意的是，消费者组的消费者实例必须订阅完全相同的Topic
- RocketMQ支持两种消息模式：集群消费(Clustering)和广播消费(Broadcasting)
10 ) 集群消费(Clustering)
- 集群消费模式下，相同Consumer Group的每个Consumer实例平均分摊消息
11 ) 广播消费(Broadcasting)
- 广播消费模式下，相同Consumer Group的每个Consumer实例都接收全量的消息
12 ) 普通顺序消息(Normal Ordered Message)
- 普通顺序消费模式下，消费者通过同一个消息队列(Topic分区，称作Message Queue)收到的消息是有顺序的
- 不同消息队列收到的消息则可能是无顺序的
14 ) 严格顺序消息(Strictly Ordered Message)
- 严格顺序消息模式下，消费者收到的所有消息均是有顺序的
15 ) 消息(Message)
- 消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题
- RocketMQ中每个消息拥有唯一的MessagelD,且可以携带具有业务标识的Key
- 系统提供了通过Message ID和Key查询消息的功能
16 ) 标签(Tag)
- 为消息设置的标志，用于同一主题下区分不同类型的消息
- 来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签
- 标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统
- 消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性
消息队列类型
1 ）按照发送方式分
-
同步：发送并阻塞
-
异步：指定回调函数，发送后立即返回即可，不阻塞，在回调中起一个线程执行
-
单向：发送后不返回，只管发，性能高，不可靠，发消息级别在ms级别，大多场景不适用，视频通话可用，但为何用mq呢, 这里不适用视频通话
-
主要关注：同步 和异步
2 ）按消息类型分
- 普通消息：日常最多，生产者发送，消费者消费，无需保证消息顺序
- 顺序消息：全局顺序(先进先出，开销大)和分区顺序(开销较小，无需严格先进先出)
- 延迟消息：订单超时，库存归还，防止友商下单不支付
- 事务消息：分布式和微服务相关
MQ 使用场景
- 场景：订单新建完成之后，给用户发送一条短信，(下订单成功通知)，还要给用户增加积分
- 单体服务，发送完短信，就发送积分增加信息
- 短信是第三方服务，不稳定，体现在第三方服务可能会崩溃，短信发送频率要符合短信平台的规定(限制)
- 短信欠费被停，这样短信发不出去，积分是没法增加
- 1 ) 解决方案
- 异步发送短信，中间加一层 redis, 但要保证 redis 不能挂
- 这也会造成一些问题
- 2 ）解决方案升级：
- 把 中间的 redis 替换成 MQ
- mq 是队列，先进先出, 谁先来，消费谁
- 这样，积分服务无需关心订单服务，只需要关心 MQ 中的订阅
- 销峰：订单量大了，直接把消息发送到 MQ 里就算成功，后续订阅MQ的系统可以根据自身情况慢慢消化消费