文章本身是基于技术：Go+MySQL+Redis来讲解的，但道理都是相通的。
在做网络聊天室项目之前，我对“消息”和“消息队列”的理解非常直观。
我认为消息就是用户发出的聊天内容。
我也认为消息队列的作用，就是保证这些聊天内容按顺序传递。
这个理解在一开始看起来合理，而且实现起来也不难。
但当项目开始变复杂，这个认知很快就不够用了。
问题出现在“异步”这个词上。
我最初完全不知道它和聊天系统有什么关系。
在看这篇文章之前，我希望你能先问一下自己这三个问题。
- 何为消息？
- 何为消息队列？
- 何为异步？
然后我会从我所想的角度来一一讲述，一一纠错，所以这篇文章是我对异步消息队列的部分理解，希望在看完之后你能有所感悟。（以下的图片算是整个流程）
一、什么是消息
一开始，我把消息等同于聊天消息。
这个理解是错误的。
在实际系统中，消息不是内容，而是事件。
它表示一件事情已经发生。
例如：
用户发送了一条聊天内容
用户完成了一次登录
用户断开了连接
系统需要更新一次统计数据
这些都可以是消息。
它们的共同点是：系统需要对它们作出反应。
聊天内容只是其中一种。
它并不是消息的全部。
二、即时消息与非即时消息
在进一步分析后，我开始区分两类消息。
第一类是即时消息。
它们必须在当前请求中完成处理。
用户需要立刻看到结果。
例如：
用户发送聊天内容并等待对方看到
用户登录并等待验证结果
第二类是非即时消息。
它们不要求立刻完成处理。
用户也不需要立刻看到结果。
例如：
更新用户活跃度
记录行为日志
广播“某用户上线或下线”的系统事件
这一步区分非常关键。
它决定了系统的处理方式。
三、异步到底是什么意思
我最初对异步的理解是：
消息可以先存起来，之后再处理。
这样不会阻塞其他操作。
这个理解在工程上是可用的，但并不完整。
更准确的说法是：
异步表示当前流程不必等待最终处理结果，而可以直接返回一些内容。
是否使用消息队列，只是一种实现方式。
异步本身是一种行为语义。
例子：
如果服务端在写入一条事件后立刻返回响应，
而后续处理在另一个流程中完成，
那么这就是异步。
四、消息队列并不是为顺序而生
我曾认为消息队列的主要作用是保证顺序。
这个想法并不准确。
顺序只是队列的一个表现。
但它不是核心价值。
消息队列的核心作用有三个：
让系统模块之间不直接依赖
让主流程更快返回
让重要事件不会因为进程中断而丢失
在聊天室中，
聊天消息本身通常走的是同步路径。
它属于系统的主流程。
而消息队列更多用于处理这些聊天行为带来的“副作用”。
副作用：比如用户因为聊天活跃度增加，存储的聊天记录的更新等。
五、Redis 不应该只被当成聊天记录存储
在项目早期，我把 Redis 当成了一个存储工具。
我用它保存聊天记录。
我也顺手用它当作消息队列。
后来我意识到，这是一个用途混淆。
聊天记录是一种状态。
它是给用户看的数据。
消息队列是一种过程。
它是给系统自己使用的机制。
如果只把队列当成存储容器，
那就失去了它在系统设计中的意义。
六、消费者与消费者组的真实含义
我一开始对消费者的理解并不清楚。
后来才明白，它并不是抽象概念。
在实际系统中：
消费者通常是一个 goroutine 或服务实例
消费者组定义了谁来处理哪一条消息
在 Redis Stream 中，
同一个消费者组内，
一条消息只会被处理一次。
而不同消费者组之间，
可以对同一条消息做不同的事情。
这让系统可以在不修改主流程的情况下，
不断增加新的处理逻辑。
七、关于可靠性
使用 Redis Stream 的一个重要原因，
是它可以在服务重启后继续处理未完成的消息。
但这个能力有前提。
系统必须：
使用消费者组
正确确认消息已处理
能处理未确认的消息
在这些条件下，
系统才能保证事件不会无声消失。
这并不是自动完成的。
它需要明确的设计。
)
