从聊天室项目中理解异步消息队列：认知提升

文章本身是基于技术：Go+MySQL+Redis来讲解的，但道理都是相通的。

在做网络聊天室项目之前，我对“消息”和“消息队列”的理解非常直观。
我认为消息就是用户发出的聊天内容。
我也认为消息队列的作用，就是保证这些聊天内容按顺序传递。

这个理解在一开始看起来合理，而且实现起来也不难。
但当项目开始变复杂，这个认知很快就不够用了。

问题出现在“异步”这个词上。
我最初完全不知道它和聊天系统有什么关系。

在看这篇文章之前，我希望你能先问一下自己这三个问题。

• 何为消息？
• 何为消息队列？
• 何为异步？

然后我会从我所想的角度来一一讲述，一一纠错，所以这篇文章是我对异步消息队列的部分理解，希望在看完之后你能有所感悟。（以下的图片算是整个流程）

一、什么是消息

一开始，我把消息等同于聊天消息。
这个理解是错误的。

在实际系统中，消息不是内容，而是事件。
它表示一件事情已经发生。

例如：

• 用户发送了一条聊天内容

• 用户完成了一次登录

• 用户断开了连接

• 系统需要更新一次统计数据

这些都可以是消息。
它们的共同点是：系统需要对它们作出反应。

聊天内容只是其中一种。
它并不是消息的全部。

二、即时消息与非即时消息

在进一步分析后，我开始区分两类消息。

第一类是即时消息。
它们必须在当前请求中完成处理。
用户需要立刻看到结果。

例如：

• 用户发送聊天内容并等待对方看到

• 用户登录并等待验证结果

第二类是非即时消息。
它们不要求立刻完成处理。
用户也不需要立刻看到结果。

例如：

• 更新用户活跃度

• 记录行为日志

• 广播“某用户上线或下线”的系统事件

这一步区分非常关键。
它决定了系统的处理方式。

三、异步到底是什么意思

我最初对异步的理解是：
消息可以先存起来，之后再处理。
这样不会阻塞其他操作。

这个理解在工程上是可用的，但并不完整。

更准确的说法是：
异步表示当前流程不必等待最终处理结果，而可以直接返回一些内容。

是否使用消息队列，只是一种实现方式。
异步本身是一种行为语义。

例子：

如果服务端在写入一条事件后立刻返回响应，
而后续处理在另一个流程中完成，
那么这就是异步。

四、消息队列并不是为顺序而生

我曾认为消息队列的主要作用是保证顺序。
这个想法并不准确。

顺序只是队列的一个表现。
但它不是核心价值。

消息队列的核心作用有三个：

• 让系统模块之间不直接依赖

• 让主流程更快返回

• 让重要事件不会因为进程中断而丢失

在聊天室中，
聊天消息本身通常走的是同步路径。
它属于系统的主流程。

而消息队列更多用于处理这些聊天行为带来的“副作用”。

副作用：比如用户因为聊天活跃度增加，存储的聊天记录的更新等。

五、Redis 不应该只被当成聊天记录存储

在项目早期，我把 Redis 当成了一个存储工具。
我用它保存聊天记录。
我也顺手用它当作消息队列。

后来我意识到，这是一个用途混淆。

聊天记录是一种状态。
它是给用户看的数据。

消息队列是一种过程。
它是给系统自己使用的机制。

如果只把队列当成存储容器，
那就失去了它在系统设计中的意义。

六、消费者与消费者组的真实含义

我一开始对消费者的理解并不清楚。
后来才明白，它并不是抽象概念。

在实际系统中：

• 消费者通常是一个 goroutine 或服务实例

• 消费者组定义了谁来处理哪一条消息

在 Redis Stream 中，
同一个消费者组内，
一条消息只会被处理一次。

而不同消费者组之间，
可以对同一条消息做不同的事情。

这让系统可以在不修改主流程的情况下，
不断增加新的处理逻辑。

七、关于可靠性

使用 Redis Stream 的一个重要原因，
是它可以在服务重启后继续处理未完成的消息。

但这个能力有前提。

系统必须：

• 使用消费者组

• 正确确认消息已处理

• 能处理未确认的消息

在这些条件下，
系统才能保证事件不会无声消失。

这并不是自动完成的。
它需要明确的设计。