前言

“已读/未读”是职场 IM的标配功能。它让沟通变得确定——但也让“假装没看到”变得不可能。

单聊和群聊的已读回执，在技术难度上有着天壤之别。如果设计不当，一个 5000 人的大群。发一条消息就能让数据库瞬间写入 5000 条记录并发 ACK 请求能把服务器打崩。

说到第一部分，基础篇——单聊与群聊的主要模型

功能差异速览

单聊实现

A 发消息 → B 读消息 → B 告诉服务器“我读了” → 服务器通知 A。

表结构设计：

CREATE TABLE single_msgs (
msg_id BIGINT AUTO_INCREMENT PRIMARY KEY,from_uid BIGINT NOT NULL。to_uid BIGINT NOT NULL,content TEXT,send_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,is_read BOOLEAN DEFAULT FALSE,-- 是否已读
read_time TIMESTAMP NULL -- 已读时间
);老实说，

客户端流程：

• 接收方进入聊天页。调用 alertConversationRead → 批量更新所有未读消息的 is_read = TRUE
• A 方通过长连接回调 onMessageRead，将 UI 状态从“已送达”刷新为“已读”。

群聊基础模型

主要痛点： 群消息只有一份，但每个成员的阅读进度各不相同。

If group has 200 members and message ID = 10086。some users may have read up to 10090 while ors only up to 10050.

最朴素的设计——每条消息为每个成员存一条回执明细：

-- ⚠️ 低并发可用的基础表，高并发会崩溃！说起来，CREATE TABLE msg_read_detail (
id BIGINT AUTO_INCREMENT PRIMARY KEY,msg_id BIGINT NOT NULL。-- 群消息 ID
user_id BIGINT NOT NULL,-- 群成员 ID
is_read BOOLEAN DEFAULT FALSE,read_time TIMESTAMP NULL,UNIQUE KEY uk_msg_user
);

Pseudo‑SQL 查询示例：

SELECT COUNT FROM msg_read_detail WHERE msg_id =?AND is_read = TRUE;SELECT user_id FROM msg_read_detail WHERE msg_id =?AND is_read = FALSE;

This design works fine for groups under ~100 people,but it explodes under high concurrency.

第二部分这方面，高并发下的三大“核爆”痛点 🚀

💥 痛点1：写扩散爆炸

If we keep detail table。sending a single @all message in a 2000‑person group creates 1999 new rows.. Ten such messages per day → ~40k rows daily →>1.5 M rows per year. MySQL will choke quickly.

💥 痛点2：热点行锁竞争

A burst of 2000 concurrent reads tries to update same “read count” row or each user's watermark simultaneously. Row‑level lock contention pushes average latency from ~10 ms to>3 s – a classic avalanche.

💥 痛点3：ACK 信令风暴

The feedback loop becomes: 2000 users × . WebSocket / 长连接带宽瞬间被占满。

第三部分的观点是，高并发架构演进——工业级方法 🏭

说到存储模型革命，摒弃明细，只存“水位线”

The key idea is to store **one value per user per group** – maximum message ID that user has read . Message IDs are monotonically increasing,so checking if a particular message has been read reduces to a simple numeric comparison.

The Redis hash schema:

# Key pattern: group:read:{groupId}
# Field: {userId} Value: {maxReadMsgId}
HSET group:read:12345 45678 10086 # 使用者456 在群123 已读到 msgId=10086
HGET group:read:12345 45678 # → 10086
HINCRBY ... # 用于计数器时另建键
TTL 设置为30天左右。以自动淘汰历史数据

The MySQL backup table mirrors this structure:

CREATE TABLE group_read_watermark (
group_id BIGINT NOT NULL,user_id BIGINT NOT NULL,max_read_msg_id BIGINT NOT NULL DEFAULT 0,update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY
);-- 每个使用者在每个群仅一行记录

说到原子更新。Lua 脚本防止 ID 回退

-- Redis Lua 脚本
local key = KEYS -- group:read:{groupId}
local uid = ARGV
local newMsgId = tonumber
local cur = redis.call
if not cur or newMsgId> tonumber n
redis.call
return 1 -- 更新成功
end
return 0 -- 忽略旧 ID

高并发写入链路：异步削峰 + MQ

1. User ACK → Redis 原子更新，立即返回成功。
投递至 Kafka / RocketMQ。 /  落库至 MySQL。
2. The DB serves only offline analytics and disaster recovery – never sits in hot path.

解决 ACK 风暴：客户端聚合 + 服务端限流

• 客户端聚合： If a client reads multiple messages within a short window,it sends **one** packet:

  { "groupId": "..."。"maxReadMsgId": latestId }

  .
• 服务端限流： A per‑user token bucket allows at most **2 reports/sec**. Excess requests are silently dropped with a `200 OK` response because eventual consistency tolerates a few seconds delay.

查询“已读人数”：原子计数器 O 获取

• Create a counter when message is sent:

  # SET readcount:{msgId} 0;EXPIRE readcount:{msgId} ${TTL}

  .

# INCR read_count:{msgId}

# GET read_count:{msgId}

// 示例代码：上报已读时原子计数器 + 水位线更新
public void reportRead {
String watermarkKey = "group:read:" + groupId;boolean updated = redisTemplate.execute conn -> {
Object result = conn.eval(
// Lua script defined earlier …luaScript,ReturnType.INTEGER,new byte{ watermarkKey.getBytes }。userId.getBytes,String.valueOf.getBytes
);其实，return Long.valueOf.equals;})，if {
String countKey = "readcount:" + msgId;redisTemplate.opsForValue.increment;redisTemplate.expire);kafkaTemplate.send("topicread_binlog",groupId + "|" + userId + "|" + msgId);其实，}
}

群聊分级策略