源码消息回执处理逻辑？

访客源码剖析 2026-06-07 22:59:52 1

本文目录导读：

消息回执的核心类型（状态定义）
典型处理流程（时序逻辑）
源码级核心数据结构和接口
关键难点与解决思路
消息回执的状态机（源码安全核心）
源码级实现要点

“源码消息回执处理逻辑”通常指的是在即时通讯（IM）系统、短信服务或消息队列中，当发送方发出消息后，接收方（或服务器）返回一个确认信号（回执/ACK）,表明消息已送达或已读。

由于你的问题比较宽泛，我将从最典型的即时通讯系统源码级实现（以企业微信、微信或自研IM为例）来拆解其核心逻辑，这包括了协议设计、状态机流转、重试机制、并发处理等关键点。

消息回执的核心类型（状态定义）

在源码层面,通常定义如下枚举或状态：

public enum MessageReceiptStatus {
    SENDING(0, "发送中"),     // 客户端发出，未确认
    DELIVERED(1, "已送达"),   // 服务器确认推送到目标设备
    READ(2, "已读"),         // 接收方已打开会话并看到消息
    FAILED(-1, "发送失败")   // 超过重试次数或目标不可达
}

典型处理流程（时序逻辑）

以一个点对点聊天为例，假设 A 给 B 发消息,源码逻辑通常分为三层：

客户端发送 -> 服务器暂存

A客户端 -> (WebSocket/TCP长连接) -> IM Server

事件： A 发送消息。
动作： Server 持久化消息（入库或写入消息队列），状态设为 SENDING。
回执（ACK-1）： Server 立即返回一个“服务器已接收”的回执给 A（异步确认，防止A以为丢了）。

服务器推送 -> 目标客户端

IM Server -> -> B客户端

动作： Server 通过长连接推送给 B。
难点： B 可能离线（App后台、断网）。

目标客户端确认 -> 服务器

B客户端 -> (ACK-2: 已送达回执) -> IM Server

当 B 的客户端接收到消息并存入本地DB后，发送一个 ACK\_DELIVERED 数据包回服务器。
服务器逻辑： 更新消息状态为 DELIVERED，并转发此回执给 A（A看到“对方已送达”）。

已读回执（可选）

B客户端 - (用户打开聊天、点击消息区域) -> READ\_ACK

B 客户端在上滑或点击消息时，发送 ACK\_READ（包含消息ID和会话ID）。
服务器逻辑： 更新状态为 READ，并立刻通知 A（A看到“对方已读”）。

源码级核心数据结构和接口

回执数据包（ProtoBuf/JSON协议）

message Receipt {
    string msg_id = 1;         // 原始消息ID
    string session_id = 2;      // 会话ID
    ReceiptType type = 3;       // 0=送达, 1=已读, 2=撤回
    int64 timestamp = 4;        // 回执产生时间
    string user_id = 5;        // 发送回执的用户
}

核心处理函数（伪代码）

// 处理接收到的回执请求
public void handleReceipt(ReceiptRequest request) {
    // 1. 防重入检查（利用Redis分布式锁或msg_id去重）
    if (duplicateChecker.isDuplicate(request.getMsgId(), request.getType())) {
        return;  // 防止客户端重复发送回执导致状态错乱
    }
    // 2. 根据回执类型更新消息状态
    switch (request.getType()) {
        case DELIVERED:
            messageService.updateStatus(request.getMsgId(), DELIVERED);
            break;
        case READ:
            messageService.updateStatus(request.getMsgId(), READ);
            break;
    }
    // 3. 通知原发送方（异步推送）
    MessageStatusChangeEvent event = new MessageStatusChangeEvent(
        request.getMsgId(),
        originalSenderId, // 需要在消息记录里查到原始发送者
        request.getType()
    );
    eventBus.publish(event);
    // 4. 写回执日志（用于统计、审计、故障排查）
    logReceipt(request);
}

关键难点与解决思路

丢包与重试机制

场景： B 发回的 DELIVERED 回执在传输过程中丢失。
方案：
- 客户端兜底： 若 B 在一定时间内（如10秒）未收到服务器的 ACK\_FOR\_ACK（对回执的回执），则自动重发 DELIVERED 回执。
- 服务器幂等： 服务器必须根据 msg_id + type 判断是否已处理,避免重复通知A。

并发写问题（多设备登录）

场景： B在手机和PC同时登录，两个设备都发回了 READ 回执。
方案： 服务器使用 乐观锁 或 CAS（Compare and Swap） 控制状态流转（状态只能单向演进：SENDING -> DELIVERED -> READ，不能回退）。

离线消息的回执

场景： B 离线，消息投递到离线队列（如MQ）。
方案： 当 B 上线后，拉取离线消息时，服务器会随消息携带一个 need\_ack 标识，B 客户端逐条处理并发送回执,服务器直到收到所有回执后才认为离线消息完全投递。

已读回执的聚合（性能优化）

场景： 群聊中若每个用户都发一次 READ,服务器压力巨大。
方案： 客户端批量提交已读回执（如“该会话所有已读消息的最新一条ID”）,服务器自动查询该ID之前的所有消息并标记为已读。

消息回执的状态机（源码安全核心）

确保状态无法被异常篡改：

                  接收方收到
SENDING ─────────────────────────────────> DELIVERED
   │                                           │
   │                                           │ 接收方点击阅读
   │                                           ▼
   └─────────────────────> ───────────────> READ
                             (不允许从SENDING直接到READ)
                             (不允许回退)

代码实现示例：

public void updateStatus(String msgId, ReceiptStatus newStatus) {
    Message msg = messageRepo.findById(msgId);
    ReceiptStatus old = msg.getReceiptStatus();
    // 只允许顺序前进：SENDING->DELIVERED，SENDING->READ? 不行，必须先DELIVERED
    if (old.ordinal() < newStatus.ordinal() && !(old == SENDING && newStatus == READ)) {
        // 允许更新
        msg.setReceiptStatus(newStatus);
        messageRepo.save(msg);
    } else {
        log.warn("非法状态流转: {} -> {}, 抛弃", old, newStatus);
    }
}

源码级实现要点

要点	具体做法
协议层	消息ID + 回执类型 + 时间戳，推荐使用Protobuf或压缩JSON
存储层	消息状态存储在数据库（MySQL/Redis），索引为 `msg_id`
幂等性	对每个回执请求做去重（利用Redis Set或本地布隆过滤器）
异步通知	使用事件总线（Guava EventBus / MQ）解耦回执接收和通知发送方
离线处理	离线消息携带 `need_ack` 标记，上线后逐条确认
性能优化	群聊只读回执批量提交，定时刷新，避免单条点对点刷库