消息队列
介绍
在并发编程中，有一种特殊的队列叫阻塞队列，一般可以用来实现生产者-消费者模型。生产者生产数据到队列中，消费者取出数据进行处理。它存在诸多好处：
- 解耦合 支持开发 支持忙闲不均 削峰填谷
举个例子：食堂托盘架
1、后厨=>生产者 2、同学=>消费者 3、托盘架最多10个->有界容量
4、后厨看到架子满了->阻塞（休息），等同学拿走一个才被叫醒
5、同学发现架子空了->阻塞（休息），等后厨放新托盘才被叫醒
整个过程中：
- 没有人原地转圈（cpu 0%空转）
- 不会出现"发现架子空了"或"空架子却硬拿的错乱->这就是阻塞队列要干的全部事情
在实际后台开发中，尤其是分布式系统里，跨主机之间使用生产者-消费者模型，是非常普遍的需求。因此，我们通常会把阻塞队列封装成一个独立的服务器，并且赋予其丰富的功能。这样的服务器程序称为消息队列（Message Queue,MQ）。例如常见的消息队列：RabblitMQ Kafka RocketMQ ActiveMQ
开发环境
- Linux(Ubuntu-22.04)
- vscode/vim
- g++/gdb
- Makefile
技术支持
- 开发诸语言：C++
- 序列化框架：protobuf二进制序列化
- 网络通信：
自定义应用层协议+muduo库：对tcp长连接的封装，并且使用epoll事件驱动模式，实现高并发服务器与客户端 - 源数据信息数据库：SQLite3
- 单元测试框架：Gtest
安装
安装wget
sudo apt install wget补充介绍
消息队列概念
日常学习中，消息队列是分布式系统里解耦的核心工具。通俗来讲，消息队列就是一个"中转站"，专门用来存储和传递不同系统和模块之间的"消息"，避免他们直接依赖。
消息队列的价值体现在解耦、削峰和异步通信三个方面。
1、解耦：让发送消息的"生产者"和接收消息的"消费者"互不认识。生产者只需将"消息"发送给队列，不用管谁来接。消费者只需要从队列拿消息，不用管谁发来。即使一方出故障，另一方也不影响。
2、削峰：应对突发的高流量。例如，秒杀活动时，会有大量的请求，消息队列可以把这些请求存起来，让消费者按照自己的能力慢慢处理，避免直接压跨后端系统。
3、异步：减少接口的响应时间。比如，用户下单后不需要等 "扣库存、发通知、记日志" 这些操作全做完才返回结果，只需要把这些操作对应的消息发给队列，立即告诉用户"下单成功"，后续操作让消费者异步完成。
联系
生产者-消费者模型时消息队列的设计核心思想，消息队列是这个模型工业级实现工具。
例如：
- 没有MQ时：生产者 - 消费者模型就像 "你（生产者）把文件放在公司前台（缓冲区），同事（消费者）自己去前台拿"------ 前台就是简单的 "缓冲区"，但只能本地用、容易丢文件、没人管排队；
- 有了 MQ 后，前台升级成了 "专业快递站（MQ）"------ 不仅能存文件，还能保证不丢、按顺序送、支持异地取，甚至能通知同事 "有新文件"，这就是工业级的封装。
工作流程
以 "用户下单后，扣库存、发通知" 为例，完整流程就是生产者 - 消费者模型的落地：
1、生产者发送消息：用户下单接口（生产者）执行完 "创建订单" 后，不需要同步等扣库存、发通知，直接把 "扣库存""发通知" 两个任务封装成消息，发送到 MQ 的对应队列；
2、MQ存储消息：MQ 接收到消息后，先持久化到磁盘（避免宕机丢失），然后按顺序存放在队列中
3、消费者处理消息：库存服务（消费者 1）、通知服务（消费者 2）分别监听 MQ 的对应队列，各自从队列中获取消息，执行 "扣库存""发通知" 逻辑
4、消息确认和处理：消费者处理完消息后，向 MQ 发送 "确认信号（Ack）"，MQ 收到后删除该消息；如果消费者处理失败，MQ 会重新投递消息，避免丢失。
整个过程中，生产者和消费者完全解耦---哪怕库存服务宕机，下单接口依然能正常返回，MQ 会暂存消息，等库存服务恢复后再投递，这就是生产者 - 消费者模型 "解耦、异步" 的核心价值，而 MQ 让这个价值在分布式系统中稳定落地。