IM踩坑：聊天消息ID怎么设计？一个UUID搞不定，我用双ID解决

本文作者蝎子莱莱爱打怪，即时通讯网有修订和排版。

一、引言

微信的消息 ID 是什么结构？微信技术团队公开分享过：消息 ID（Message ID）做全局唯一标识 + 序列号（Sequence）做严格递增同步游标，两者职责分离。Telegram 的消息 ID 按聊天维度递增。Twitter（Snowflake 本家）的消息 ID 就是用雪花算法生成的。

你会发现一个规律：所有成熟的 IM 系统没有一个用单一 ID 方案。

IM 系统里消息 ID 看似简单，实际上它是消息可靠性的根基。去重要靠它、排序要靠它、分页查询要靠它、离线消息同步还要靠它。一个 ID 想同时干这些事？干不了。

本篇分享如何用 clientMsgId+ msgId的双 ID 体系，彻底解耦IM中聊天消息的去重和排序两个维度的需求（本文所有内容均基于真实项目源码）。

二、为什么一个 ID 不够

先想清楚 IM 系统对消息 ID 有哪些要求：


一个 ID 想同时满足这五个条件？

1）UUID：全局唯一、去重、分布式。但不可排序——UUID v4 是随机的，无法按时间排序。而且 36 字符太长，做索引和分页查询都是灾难。

2）数据库自增：趋势递增、排序。但不能分布式——单点瓶颈，7 个微服务怎么共享一个自增序列？

3）时间戳：趋势递增。但不唯一——同一毫秒内有多条消息，简单时间戳会重复。

所以答案是：一个 ID 确实不够！

我的系统用了两个 ID，各管各的：




两个 ID 在消息流转的每一步都有明确的分工，互不干扰。

三、为什么 UUID v7 不能替代双 ID

有人可能会问：UUID v7 是时间排序的（RFC 9562，2024 年正式标准），一个 ID 既能去重又能排序，不就能替代双 ID 了吗？

UUID v7 的结构是 48 位毫秒时间戳 + 4 位版本 + 12 位随机 + 2 位变体 + 62 位随机。理论上，先发的消息 UUID v7 一定比后发的小。

但实际用在 IM 系统里，有三个致命问题：

1）排序精度不够：UUID v7 的时间戳是毫秒级。同一毫秒内的多条消息，后面的 62 位是随机的，顺序不可控。IM 系统里同一毫秒可能产生几十上百条消息（群聊场景），这些消息的相对顺序会乱。

2）做不了范围查询：UUID v7 是 36 字符的字符串（或 16 字节二进制）。用 UUID 做 MongoDB 的范围查询（"查某个会话内 msgId > X 的所有消息"），性能远不如 8 字节 fixed64 的整数比较。B+ 树索引对递增整数的范围查询是最优的，对 UUID 的范围查询要额外比较字节前缀。

3）索引膨胀：36 字符的 UUID 索引，和 19 位数字的雪花 ID 索引，存储差距是 2-3 倍。IM 系统的消息量动辄上亿条，索引大小直接影响内存使用和查询速度。

所以结论是：UUID v7 在"不太需要精确排序、数据量不大"的场景下可以用，但在 IM 这种高频+严格有序+海量数据的场景下，双 ID 体系仍然是更优解。

四、分布式 ID 方案全览

在确定用雪花算法之前，我对比过业界主流的分布式 ID 方案：


IM 消息 ID 的核心要求是：分布式 + 有序 + 高性能，只有雪花算法同时满足这三个条件。Leaf-segment 依赖数据库，在 IM 的峰值场景下会成为瓶颈。ULID 的随机尾部不适合做分页查询。Redis INCR 的网络往返开销在高并发下不可接受。

业界大厂的选择也验证了这一点：Twitter 发明了雪花算法（可详读《什么是Snowflake算法？》），Discord、Instagram 的分布式 ID 都基于雪花算法的思想。微信虽然没有公开具体方案（详见《微信的海量IM聊天消息序列号生成实践（算法原理篇）》），但从其技术分享可以看出，消息 ID 也是时间戳 + 序列号的思路。

PS：主流大厂的消息ID生成方案可进一步阅读以下资料：

• 《微信的海量IM聊天消息序列号生成实践（算法原理篇）》
• 《微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
• 《解密融云IM产品的聊天消息ID生成策略》
• 《深度解密美团的分布式ID生成算法》
• 《开源分布式ID生成器UidGenerator的技术实现》
• 《深度解密滴滴的高性能ID生成器(Tinyid)》
• 《深度解密vivo的自研分布式ID服务(鲁班)》
  

五、clientMsgId：UUID、客户端生成、管去重

5.1、为什么让客户端生成 ID

IM 系统有个特殊需求：用户发消息的时候，不能等服务端返回 ID 再显示。你发一条"你好"，聊天气泡要立刻出现，不能转圈等 200ms 等服务端生成 ID 再显示。

这意味着消息的临时 ID 必须在客户端生成。UUID 是最简单的方案——不需要和服务端通信，本地就能生成，碰撞概率可以忽略不计。

SDK 端的 UUID 生成：

// uuid_generator.dart
class UuidGenerator {
  static final Uuid _uuid = const Uuid();

  static String generateClientMsgId() {
    return _uuid.v4(); // 标准 UUID v4
  }
}

发送消息时的调用：

// xzll_im_client.dart - sendTextMessage()

final effectiveClientMsgId = clientMsgId?.trim().isNotEmpty == true
    ? clientMsgId!.trim()
    : UuidGenerator.generateClientMsgId();

如果调用方没指定 clientMsgId，SDK 自动生成一个。这样保证了每条消息在发送前就有一个唯一标识。

5.2、clientMsgId 在去重中的作用

IM 系统有大量的重试场景：

1）SDK 离线重试：断网期间消息存入 _pendingSends 队列，重连后逐条 flush。如果重连时网络抖动导致同一条消息发了两次，服务端需要识别。

2）服务端重试队列：消息写入 Redis ZSet 重试队列，5s → 30s → 5min 三级重试。重试消费时可能并发处理同一条消息。

3）用户手动重发：用户看到消息发送失败，点了"重发"按钮。

这三个场景的核心问题都是：怎么判断"这条消息我已经处理过了"？

答案就是 clientMsgId。

服务端用 Lua 脚本做原子去重：

-- 先判断 clientMsgId 是否已存在
if redis.call('HEXISTS', msgKey, clientMsgId) == 1 then
    return 0  -- 已存在，跳过（去重）
end
-- 不存在，正常处理
redis.call('HSET', msgKey, clientMsgId, msgData)
return 1

clientMsgId 是客户端生成的，同一条消息不管重试多少次，clientMsgId 不变。服务端只需要看"这个 clientMsgId 我见过没有"。

5.3、clientMsgId 在 ACK 关联中的作用

发消息是异步的。客户端发出消息后，怎么知道服务端收到了？

服务端的 ACK（ServerAckPush）携带的就是 clientMsgId：

// C2CSendMsgHandler.java
ServerAckPush ackPush = ServerAckPush.newBuilder()
    .setClientMsgId(ProtoConverterUtil.uuidStringToBytes(dto.getClientMsgId()))
    .setMsgId(ProtoConverterUtil.snowflakeStringToLong(dto.getMsgId()))
    .setToUserId(ProtoConverterUtil.snowflakeStringToLong(dto.getFromUserId()))
    .build();

客户端收到 ACK 后，通过 clientMsgId 找到本地的消息记录，更新状态从"发送中"变为"已发送"。这里的 clientMsgId 是客户端和服务端之间的关联键——客户端用它找到本地消息，服务端用它确认是哪条消息收到了。

这个角色 msgId 承担不了——因为 msgId 是服务端生成的，客户端发消息的时候还不知道 msgId 是什么。

六、msgId：雪花算法、服务端生成、管排序

6.1、为什么用雪花算法

clientMsgId 解决了去重问题，但排序问题它搞不定。UUID v4 是随机的，先发的消息 UUID 可能比后发的大也可能小，完全没法排序。

IM 系统对排序的要求非常严格：

• 1）消息列表分页：聊天记录要按时间顺序展示，最早的在上面；
• 2）未读消息计数：要精确知道哪些消息是新的（msgId > lastReadMsgId）；
• 3）离线消息同步：上线后拉取"最后一条消息之后的所有新消息"，需要基于 msgId 做范围查询；
• 4）MongoDB 存储：消息文档的 _id = chatId_msgId，msgId 的递增性直接影响索引效率。
  

雪花算法（Snowflake）完美满足这些需求：

• 1）全局唯一：时间戳 + 数据中心 ID + 机器 ID + 序列号，64 位整数，碰撞概率为零；
• 2）趋势递增：高位是时间戳，同一毫秒内序列号递增，后发的 ID 一定更大；
• 3）分布式友好：每台机器独立生成，不需要中心化协调；
• 4）可反解析：从 ID 里能还原出生成时间、机器编号，排查问题非常有用。
  

6.2、雪花算法的位布局

我的实现是标准 Twitter Snowflake，64 位布局：


关键参数：

// SnowflakeIdService.java
private final long twepoch = 1288834974657L; // 起始时间戳（和 Twitter 一样）
private final long workerIdBits = 5L;        // 机器 ID 占 5 位（0-31）
private final long datacenterIdBits = 5L;    // 数据中心 ID 占 5 位（0-31）
private final long sequenceBits = 12L;       // 序列号占 12 位（0-4095）

单毫秒内最多生成 4096 个 ID，对 IM 系统来说绰绰有余（绝大多数 IM 系统单节点 QPS 达不到 400 万）。

6.3、时钟回拨：雪花算法的阿喀琉斯之踵

雪花算法有一个众所周知的脆弱点——依赖系统时钟单调递增。如果时钟回拨（当前时间比上次生成 ID 的时间还早），就可能生成重复 ID。

我的实现选择了最保守的策略——直接报错：

if (timestamp < lastTimestamp) {
    throw new RuntimeException("Clock moved backwards. Refusing to generate id");
}

宁可服务不可用，也不能生成重复 ID。这是正确的 trade-off——消息 ID 重复的后果（消息混乱、覆盖、丢失）远比短暂不可用严重。

时钟回拨的常见原因：

• 1）NTP 校时：NTP 守护进程定期同步系统时钟，如果本地时钟偏快，同步时会往回拨。这是最常见的回拨来源。
• 2）闰秒调整：极少数情况，但确实存在。
• 3）虚拟机迁移：云环境的虚拟机热迁移可能导致时钟跳变。
• 4）人工误操作：运维手动修改系统时间。
  

我的应对策略：

1）部署层面：im-connect 和 im-business 的 JVM 配置了 -XX:+UseNTPTime 参数，NTP 守护进程使用 tinker panic 0 配置（允许大步长调整），但关键是把 NTP 的校准频率从默认的 64 秒提高到 16 秒，这样每次校准的偏差极小（通常 < 1ms），几乎不会触发回拨。

2）监控层面：lastTimestamp 被暴露为 Prometheus 指标，如果检测到时钟回拨，会立即触发告警。

3）架构层面：消息 ID 只在 im-business 服务生成（不是在 im-connect 生成），im-connect 只负责路由和转发。这把 ID 生成的故障域限制在一个服务里，不会影响长连接层的稳定性。

业界更复杂的方案（我目前没用到，但了解一下有好处）：

1）百度 UidGenerator：用 RingBuffer 预生成一圈 ID，回拨时从 buffer 里取旧 ID，容忍几十毫秒的回拨；

2）美团 Leaf：用 Zookeeper 做双重检测，回拨时等待追平，超时再报错；

3）MyCAT-Atlas：用 Thread.sleep() 等待时钟追上（不推荐，会阻塞线程）。

对于我的系统规模（单节点 QPS 远小于 400 万/秒），直接报错 + NTP 预防已经足够。如果你在更大的规模下做，建议用 RingBuffer 方案。

ID 的计算方式：

public synchronized long nextId() {
    long timestamp = System.currentTimeMillis();

    // 时钟回拨检测——宁可报错也不能生成重复 ID
    if (timestamp < lastTimestamp) {
        throw new RuntimeException("Clock moved backwards. Refusing to generate id");
    }

    // 同一毫秒内，序列号递增
    if (lastTimestamp == timestamp) {
        long seq = (sequence.incrementAndGet()) & sequenceMask; // sequenceMask = 4095
        if (seq == 0) {
            // 序列号溢出，等到下一毫秒
            timestamp = tilNextMillis(lastTimestamp);
        }
    } else {
        // 新的一毫秒，序列号归零
        sequence.set(0);
    }

    lastTimestamp = timestamp;

    // 组装 64 位 ID
    return ((timestamp - twepoch) << timestampLeftShift)  // 时间戳左移 22 位
         | (datacenterId << datacenterIdShift)             // 数据中心 ID 左移 17 位
         | (workerId << workerIdShift)                     // 机器 ID 左移 12 位
         | sequence.get();                                 // 序列号
}

6.4、workerId 分配策略：不同环境不同方案

雪花算法最关键的配置是 workerId（机器 ID）和 datacenterId（数据中心 ID）。这两个值必须保证每台机器不同，否则可能生成重复 ID。

我的系统用了三种 workerId 分配策略，根据部署环境自动选择。

1）策略一：MAC 地址（物理机部署）

// MacAddressWorkerIdStrategy.java
public long getWorkerId() {
    Enumeration<NetworkInterface> networkInterfaces = NetworkInterface.getNetworkInterfaces();
    while (networkInterfaces.hasMoreElements()) {
        NetworkInterface ni = networkInterfaces.nextElement();
        if (!ni.isLoopback() && ni.getHardwareAddress() != null) {
            byte[] mac = ni.getHardwareAddress();
            // 取 MAC 地址后两字节，右移 6 位，对 32 取模
            long macAddress = ((0xFF & mac[mac.length - 1]) | (0xFF00 & (mac[mac.length - 2] << 8))) >> 6;
            return macAddress % 32;
        }
    }
    throw new RuntimeException("No suitable MAC address found");
}

MAC 地址是机器的唯一标识，取后两字节再对 32 取模，映射到 0-31 的 workerId 范围。

2）策略二：Docker 容器 ID（容器化部署）

// DockerWorkerIdStrategy.java
public long getWorkerId() {
    String dockerId = new String(Files.readAllBytes(Paths.get("/proc/self/cgroup")))
                       .split("/")[1].substring(0, 12);
    return Long.parseLong(dockerId.substring(dockerId.length() - 5), 16) % 32;
}

从 /proc/self/cgroup 读 Docker 容器 ID，取后 5 位十六进制转数字，对 32 取模。

3）策略三：Zookeeper（大规模集群）

// ZookeeperWorkerIdStrategy.java（预留）
public long getWorkerId() {
    return 111; // TODO: 从 ZK 获取自增序号
}

目前还是 stub。如果将来节点数超过 32 台，会接入 Zookeeper 做自增序号分配。

datacenterId 的分配更简单——用集群名的 CRC32 哈希：

private long generateDatacenterId(String groupName) {
    CRC32 crc = new CRC32();
    crc.update(groupName.getBytes(StandardCharsets.UTF_8));
    return crc.getValue() % (maxDatacenterId + 1); // % 32
}

同一个集群里所有节点用相同的集群名，datacenterId 自然一样。不同集群（比如生产环境和测试环境）用不同名字，datacenterId 就不同。

6.5、workerId 碰撞概率分析

MAC 地址对 32 取模，意味着最多只有 32 个不同的 workerId。如果两台机器的 MAC 地址取模后恰好相同，就会生成重复的 ID。

这是一个经典的生日问题（Birthday Problem）——N 台机器分配 32 个 workerId，至少两台碰撞的概率。

P(碰撞) ≈ 1 - (32! / (32^N × (32-N)!))

2 台机器：P ≈ 3.1%
5 台机器：P ≈ 31%
10 台机器：P ≈ 79%

5 台机器就有 31% 的碰撞概率！

看起来很吓人，但实际不用担心：

1）碰撞不等于 ID 重复：workerId 相同只是必要条件，不是充分条件。两个相同的 workerId 还要在同一毫秒内生成 ID，且序列号恰好相同（概率 1/4096），才会真正冲突。综合概率极低。

2）datacenterId 是第二道防线：即使 workerId 碰撞，如果 datacenterId 不同（不同集群），ID 仍然唯一。

3）实际部署中可以手动指定：我的 docker-compose.yml 里可以通过环境变量覆盖 workerId，确保每台机器唯一。

4）32 台机器的上限足够：IM 系统的 im-business 服务通常 3-5 个实例。32 个 workerId 绰绰有余。如果将来规模超过 32 台，切换到 Zookeeper 策略做精确分配。

6.6、预生成池：一次批量 1000 个，用完再补

直接调 nextId() 每次都要 synchronized 加锁，高并发下会成为瓶颈。

我的解决方案是预生成 ID 池：

// SnowflakeIdService.java

public static final int ONCE_BATCH_COUNT = 1000;
private final List<Long> idPool = new ArrayList<>();
private final AtomicInteger poolIndex = new AtomicInteger(0);

// 对外暴露的方法——从池子里取
public String generateSimpleMessageId() {
    long id = getNextIdFromPool();
    return String.valueOf(id);
}

private long getNextIdFromPool() {
    synchronized (idPool) {
        if (poolIndex.get() >= idPool.size()) {
            refillIdPool(); // 池子用完了，重新填
        }
        return idPool.get(poolIndex.getAndIncrement());
    }
}

private void refillIdPool() {
    idPool.clear();
    poolIndex.set(0);
    for (int i = 0; i < ONCE_BATCH_COUNT; i++) {
        idPool.add(nextId()); // 批量生成 1000 个
    }
}

工作原理：

• 1）启动时生成 1000 个 ID 放进池子；
• 2）每次生成消息 ID 直接从池子里取，AtomicInteger 无锁递增；
• 3）池子用完了，再一次性加锁生成 1000 个。
  

性能提升分析：原来每生成一个 ID 要加一次 synchronized 锁，现在是 1000 次 ID 生成只加一次锁，锁竞争频率降低了 1000 倍。

这个优化在实际压测中效果明显——消息写入吞吐量提升了约 30%（ID 生成不再是瓶颈，瓶颈转移到了 MongoDB 写入）。

6.7、ID 格式演进：从三段式到纯数字

我的 msgId 格式经历过一次演进。

旧格式（已废弃）：

type-userId-snowflakeId
1-12345-1988484031183061064

在雪花 ID 前面拼了消息类型和用户 ID。当时觉得这样能直接从 ID 里看出消息类型和发送者。

后来发现完全是过度设计：

• 1）消息类型和用户 ID 在消息体里已经有了，ID 里再存一份纯属冗余；
• 2）三段式格式比纯数字长 10+ 字节，MongoDB 的 _id 字段变大，索引膨胀；
• 3）分页查询时需要解析 ID 格式，增加了不必要的复杂度。
  

新格式（当前使用）：

1988484031183061064

就是纯雪花 ID，19 位数字。简单、紧凑、递增、可排序。完美。

// 旧方法标记为 @Deprecated
@Deprecated
public String generateMessageId(long userId, boolean isGroupChat) {
    long id = getNextIdFromPool();
    Integer type = isGroupChat ? 2 : 1;
    return String.format("%d-%d-%d", type, userId, id);
}

// 新方法——推荐使用
public String generateSimpleMessageId() {
    long id = getNextIdFromPool();
    return String.valueOf(id);
}

七、chatId：会话 ID、不传输、本地计算

严格来说 chatId 不属于"消息 ID"，但它是 IM 系统里第三个重要的 ID，和 clientMsgId、msgId 一起构成 ID 体系的三角。

7.1、chatId 的作用

chatId 标识一个会话（聊天窗口）。

它的用途：

• 1）消息存储分区：MongoDB 按 chatId 做哈希分片，同一个会话的消息落在同一个分片上；
• 2）未读计数：Redis 里 unread:{userId} 的 Hash field 就是 chatId；
• 3）消息查询：拉取聊天记录时，先按 chatId 过滤，再按 msgId 排序；
• 4）会话列表：最近聊天列表按 chatId 组织。
  

7.2、chatId 的生成规则

C2C（单聊）：bizType-chatType-smallUserId-bigUserId
群聊：bizType-chatType-groupId

解释一下：

• 1）bizType：业务类型，默认 100
• 2）chatType：1 = 单聊，2 = 群聊
• 3）smallUserId / bigUserId：两个用户 ID 比大小，小的在前
  

示例：

A (ID:1966479049087913984) 给 B (ID:1966369607918948352) 发消息
→ chatId = 100-1-1966369607918948352-1966479049087913984
→ B 的 ID 更小，所以 B 在前

关键点：小 ID 在前。不管谁给谁发，两个用户之间的 chatId 永远一样。这个确定性是系统正确运转的基础。

服务端生成逻辑：

// ChatIdUtils.java
public static String buildC2CChatId(Integer bizType, Long fromUserId, Long toUserId) {
    Long smallUserId, bigUserId;
    if (fromUserId < toUserId) {
        smallUserId = fromUserId;
        bigUserId = toUserId;
    } else {
        smallUserId = toUserId;
        bigUserId = fromUserId;
    }
    return String.format("%d-%s-%d-%d", bizType, "1", smallUserId, bigUserId);
}
SDK 端同样的逻辑：

// chat_id_utils.dart
static String generateC2CChatId(String userId1, String userId2) {
  int userId1Int = int.parse(userId1);
  int userId2Int = int.parse(userId2);
  String smallUserId = userId1Int < userId2Int ? userId1 : userId2;
  String bigUserId = userId1Int < userId2Int ? userId2 : userId1;
  return '$bizTypeIM-$chatTypeC2C-$smallUserId-$bigUserId';
}

7.3、chatId 不在网络传输

上一篇讲过，chatId 已经从 Protobuf 协议中完全删除了。客户端和服务端各自根据 from + to 动态计算，省掉了每条消息 33 字节的传输开销。

proto 文件里的注释：

// chatId 已删除！服务端/客户端根据 from + to 动态拼接（节省 31+2=33 字节）

这是"能算就不传"的设计哲学——只要输入相同、输出确定，就应该是本地计算而不是网络传输。

八、三个 ID 在消息流转中的协作

理论讲完了，来看三个 ID 在真实消息流转中是怎么配合的。

8.1、发送一条消息的完整 ID 旅程

1. 用户点击发送
   ↓
2. SDK 生成 clientMsgId (UUID)     ← 客户端
   消息 msgId = 0（占位）            ← 客户端
   计算 chatId (from + to)           ← 客户端
   ↓
3. Protobuf 传输                     ← 网络
   clientMsgId: 16 字节 (bytes)
   msgId: 8 字节 (fixed64, 值=0)
   ↓
4. 服务端生成 msgId (Snowflake)      ← 服务端
   服务端计算 chatId (from + to)     ← 服务端
   ↓
5. 存储到 MongoDB
   _id = chatId_msgId               ← 主键
   clientMsgId 字段单独存             ← 用于去重查询
   ↓
6. 服务端返回 ACK
   携带 clientMsgId + msgId          ← 客户端用 clientMsgId 关联本地消息
   ↓
7. 客户端收到 ACK
   通过 clientMsgId 找到本地消息      ← 更新发送状态
   用服务端返回的 msgId 替换本地占位   ← 后续操作用 msgId

8.2、服务端的双 ID 处理

C2CMsgSendProtoStrategyImpl 是处理 C2C 消息发送的核心策略类。

它同时处理两个 ID：

// C2CMsgSendProtoStrategyImpl.java - convertToAO()

// clientMsgId: 从 Protobuf bytes 还原为 UUID 字符串
String clientMsgId = ProtoConverterUtil.bytesToUuidString(req.getClientMsgId());

// msgId: 客户端传 0，服务端生成
String msgId;
if (req.getMsgId() > 0) {
    msgId = ProtoConverterUtil.longToSnowflakeString(req.getMsgId());
} else {
    msgId = snowflakeIdService.generateSimpleMessageId(); // 从预生成池取
}

// chatId: 不从协议里读，本地算
String chatId = ChatIdUtils.buildC2CChatId(ImConstant.DEFAULT_BIZ_TYPE, fromUserId, toUserId);

注意 msgId 的判断逻辑：如果客户端传的值 > 0 就用客户端的（兼容 gRPC 转发场景，转发时 msgId 已有值），否则服务端新生成。

8.3、MongoDB 存储中的 ID 使用

消息在 MongoDB 里的存储结构：

// ImC2CMsgRecordMongo.java

public void buildId() {
    this.id = this.chatId + "_" + this.msgId;
    // 例如：100-1-1966369607918948352-1966479049087913984_1988484031183061064
}

_id 用 chatId + msgId 拼接，好处：

• 1）天然分区：同一个会话的消息，_id 前缀相同，MongoDB 哈希分片后落在同一分片；
• 2）范围查询高效：按 chatId 前缀 + msgId 范围，可以精准查询某个会话的一段时间内的消息；
• 3）全局唯一：chatId 保证会话唯一，msgId 保证消息唯一，组合一定唯一。
  

8.4、ACK 流程中的双 ID 协作

服务端 ACK：

// ServerAckPush 同时携带两个 ID
ServerAckPush ackPush = ServerAckPush.newBuilder()
    .setClientMsgId(ProtoConverterUtil.uuidStringToBytes(dto.getClientMsgId()))
    .setMsgId(ProtoConverterUtil.snowflakeStringToLong(dto.getMsgId()))
    .build();

解释一下：

• 1）clientMsgId：客户端用它定位本地消息记录；
• 2）msgId：客户端用它更新本地消息的 ID（从临时 ID 升级为正式 ID）。
  

客户端 ACK（SDK 回复服务端）：

// SDK 发送 ClientACK
final ackReq = C2CAckReq(
  clientMsgId: ProtoConverterUtil.uuidStringToBytes(clientMsgId),
  msgId: ProtoConverterUtil.snowflakeStringToInt64(serverMsgId),
  from: ProtoConverterUtil.snowflakeStringToInt64(_currentUserId),
  to: ProtoConverterUtil.snowflakeStringToInt64(toUserId),
  status: status,
);

gRPC 跨节点转发时也同时携带两个 ID：

// MessageServiceGrpcImpl.java
// 双轨制：包含 clientMsgId 和 serverMsgId
C2CAckReq ackReq = C2CAckReq.newBuilder()
    .setClientMsgId(request.getClientMsgId())
    .setMsgId(request.getMsgId())
    .build();

源码注释里写得很清楚：双轨制。两个 ID 各跑各的轨道，互不干扰。

8.5、双 ID 如何实现消息的精确一次投递

分布式系统有个经典难题——Exactly-Once 语义：

• 1）消息不能丢（at-least-once）；
• 2）不能重复（at-most-once）；
• 3）恰好一次（exactly-once）。
  

在 IM 系统里，我通过双 ID 组合实现了这一目标：

clientMsgId 保证幂等性（去重） + msgId 保证有序性（排序）  = Exactly-Once 投递

幂等性（Idempotency）：同一条消息处理多次和一次的结果相同。服务端收到消息后，先用 clientMsgId 查 Redis："这个 ID 我处理过没有？"处理过就直接跳过。这样即使消息因为重试被消费了 3 次，也只会入库 1 次。

有序性（Ordering）：消息按 msgId 严格递增。客户端拉取离线消息时，用 lastMsgId 做游标：SELECT * FROM msg WHERE chatId = ? AND msgId > lastMsgId ORDER BY msgId ASC。这个查询保证消息的展示顺序和发送顺序一致。

这两个维度是正交的——去重不需要知道顺序，排序不需要知道是否重复。分开处理，逻辑清晰，互不干扰。如果只用一个 ID 试图同时解决两个问题，去重逻辑和排序逻辑会纠缠在一起，改一个另一个出 bug。

这也是 Kafka 为什么有 offset（排序）+ key（分区/去重）两个概念，数据库为什么有 primary key（唯一）+ timestamp（排序）两个维度的原因。双标识符模式是分布式系统的通用范式。

九、雪花算法的变体（压缩用户ID）

除了消息 ID，我的系统还有第三种 ID 需求——用户 ID。用户 ID 也是雪花算法，但参数完全不同。

9.1、为什么用户 ID 需要单独设计

消息 ID 是 19 位数字（标准雪花算法，毫秒级精度）。用户 ID 如果也用 19 位，对于用户注册这种低频操作来说太浪费了——用户 ID 不需要毫秒级精度，不需要单毫秒 4096 个的容量。

所以我设计了一个压缩雪花算法，专门用于用户 ID：


总计 42 位 → 10-12 位数字（比标准雪花的 19 位短了约 40%）。

关键区别：


用户注册每秒 64 个 ID 对绝大多数系统绰绰有余，而 ID 长度从 19 位缩减到 10-12 位，直接减少了约 40% 的存储和索引开销。

9.2、压缩用户 ID 的生成

// SnowflakeIdService.java - generateCompactUserId()

public synchronized String generateCompactUserId() {
    // 秒级时间戳，从 2022-01-01 起算
    long timestamp = System.currentTimeMillis() / 1000 - USER_ID_START_TIME;

    if (timestamp == userIdLastTimestamp) {
        userIdSequence = (userIdSequence + 1) & MAX_USER_SEQUENCE; // 0-63
        if (userIdSequence == 0) {
            timestamp = waitForNextSecond(userIdLastTimestamp);
        }
    } else {
        userIdSequence = 0L;
    }

    userIdLastTimestamp = timestamp;

    // 组装：[32位时间戳][4位机器ID][6位序列号] = 42位
    long compactId = (timestamp << USER_TIMESTAMP_SHIFT) 
                   | (userMachineId << USER_MACHINE_SHIFT) 
                   | userIdSequence;

    return String.valueOf(compactId);
}

9.3、从用户 ID 反查注册时间

压缩雪花算法保留了时间信息，可以从 ID 反查注册时间：

public static long extractUserRegistrationTime(String compactUserId) {
    long id = Long.parseLong(compactUserId);
    long timestamp = id >> USER_TIMESTAMP_SHIFT;
    return (timestamp + USER_ID_START_TIME) * 1000; // 秒 → 毫秒
}

排查用户问题的时候，看到用户 ID 就能算出注册时间，不需要查数据库。这是雪花算法的一个隐藏福利。

十、ID方案的设计原则

回顾三个 ID 的分工，可以提炼出几条 ID 设计的通用原则。

☞ 原则一：一个 ID 只干一件事。clientMsgId 管去重，不管排序。msgId 管排序，不管去重。chatId 管会话隔离，不管其他。不要让一个 ID 承担多个职责。一旦 ID 职责交叉，去重逻辑和排序逻辑就会互相干扰，改一个另一个跟着出 bug。

☞ 原则二：谁创建谁负责。clientMsgId 由客户端创建，客户端保证唯一。msgId 由服务端创建，服务端保证唯一。各自信任对方的结果，不交叉生成。如果让服务端生成 clientMsgId，客户端离线时就无法创建消息。如果让客户端生成 msgId，分布式环境下无法保证递增。

☞ 原则三：能算就不传。chatId 不在网络上传。客户端和服务端各自根据 from + to 计算，输入确定、输出确定，不需要额外传输。省带宽、省序列化开销、还天然一致。

☞ 原则四：ID 格式要考虑存储和索引。msgId 从三段式（type-userId-snowflakeId）简化为纯数字，直接原因是 MongoDB 的索引效率。ID 是数据库里最高频查询的字段，格式设计的优劣直接影响系统性能。

☞ 原则五：预生成优化是值得的。ID 池（一次批量 1000 个）的实现很简单，但效果显著——锁竞争频率降低 1000 倍。这种"空间换时间、批量换实时"的思路在 IM 系统里随处可见（心跳预生成、消息 ID 预分配、连接池……）。

十一、参考资料

[1] 微信的海量IM聊天消息序列号生成实践（算法原理篇）
[2] 解密融云IM产品的聊天消息ID生成策略
[3] 深度解密美团的分布式ID生成算法
[4] 开源分布式ID生成器UidGenerator的技术实现
[5] 深度解密滴滴的高性能ID生成器(Tinyid)
[6] 深度解密vivo的自研分布式ID服务(鲁班)
[7] 如何保证IM实时消息的“时序性”与“一致性”？
[8] 一个低成本确保IM消息时序的方法探讨
[9] 如何保证IM实时消息的“时序性”与“一致性”？
[10] 一个低成本确保IM消息时序的方法探讨
[11] IM群聊消息如此复杂，如何保证不丢不重？
[12] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等
[13] 理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨
[14] 如何保障分布式IM聊天系统的消息有序性（即消息不乱）
[15] 深度剖析IM消息乱序的根本原因及优化方法
[16] 什么是IM聊天系统的消息时序一致性？