拒绝“大宽表”进阶篇：如何设计十亿级 IM 消息系统的“会话架构”？

引言：数据接进来了，然后呢？

在上一篇文章中，我们聊到了利用“三层漏斗模型”解决了微信、抖音、QQ 等多渠道数据的接入问题。

解决了“写”的问题，紧接着就是更棘手的“读”的问题。

你是否遇到过这些场景：

私聊与群聊逻辑分裂：查私聊要 WHERE sender = A AND receiver = B，查群聊要 WHERE group_id = X，代码里到处是 if-else。
列表页加载慢：为了获取首页列表显示的最新消息信息，都要去几千万行的消息表中做聚合查询 (GROUP BY)，数据库 CPU 直接飙升。
分库分表困难：当数据量达到亿级时，发现当初表设计得太随意，根本没法做数据分片。

今天，我们深入数据库底层，聊聊如何通过**“会话归一化”和“写扩散”**策略，设计一个能抗住十亿级数据的 IM 架构。

一、核心痛点：分裂的收发逻辑

在传统设计中，最容易踩的坑就是把“私聊”和“群聊”看作两个完全不同的物种。

私聊：是“人对人”。
群聊：是“人对群”。

如果你设计了 private_message 和 group_message 两张表，或者在同一张表里用复杂的 receiver_id 逻辑，查询历史记录时就会非常痛苦：

-- 痛苦的查询：需要判断方向，还要处理群聊逻辑
SELECT * FROM wx_message 
WHERE (sender_id = '我' AND receiver_id = '他') 
   OR (sender_id = '他' AND receiver_id = '我')
   OR (group_id = '某群')
ORDER BY time DESC;

这种 SQL 不仅写起来累，而且极难利用索引，是性能杀手。

二、破局策略：全局 ID 与会话归一化

要解决这个问题，我们需要引入一个核心概念：会话 (Session)。

无论对方是一个“人”还是一个“群”，对系统来说，都只是一个**“聊天对象”**。我们需要把它们抽象统一。

1. 全局 ID 策略 (The Global ID)

我们放弃传统的数据库自增 ID，改用 Snowflake (雪花算法) 的变体。我们在 ID 的比特位中，预留 3-4 位来标识 “实体类型”。

Contact ID (联系人)：生成的 ID 必定带有 Type=1 的基因。
Group ID (群组)：生成的 ID 必定带有 Type=2 的基因。

收益： 任何一个 ID，不需要查库，后端一看就知道它是人还是群。且保证了 Contact 表和 Group 表的 ID 绝对不重复。

2. 消息表设计：抛弃 Receiver，拥抱 Session

基于全局 ID，我们可以将消息表简化到极致。不再区分发送者和接收者，统一使用 session_id。

CREATE TABLE wx_message (
    id BIGINT NOT NULL COMMENT '消息全局唯一ID',
    
    -- 【关键设计】分片键 (Sharding Key)
    -- 即使 session_id 已经能定位数据，我们依然冗余 account_id
    -- 也就是为了让同一个接入账户的数据落在同一个库，方便管理和清理
    account_id BIGINT NOT NULL COMMENT '所属账户ID',
    
    -- 【核心设计】统一会话ID
    -- 无论是私聊还是群聊，只存这一个 ID
    -- 如果是私聊 session_id 为
    session_id BIGINT NOT NULL COMMENT '全局唯一会话ID (Contact/Group)',
    
    sender_id BIGINT NOT NULL COMMENT '发送者ID',
    
    -- 消息内容
    payload JSON COMMENT '消息内容',
    
    time_stamp BIGINT NOT NULL,
    
    PRIMARY KEY (id),
    -- 【黄金索引】单索引解决所有历史记录查询
    INDEX idx_history (account_id, session_id, time_stamp DESC)
);

现在，查询历史记录变得异常简单：

-- 无论是查群还是查人，SQL 只有这一句
SELECT * FROM wx_message 
WHERE account_id = 101 AND session_id = 888888 
ORDER BY time_stamp DESC;

三、性能优化：列表页的“写扩散”

解决了历史记录查询，最大的 BOSS 来了：首页列表显示的最新消息信息怎么查？

很多初学者会这样做：
SELECT * FROM wx_message GROUP BY session_id ORDER BY MAX(time) DESC

在数据量少时没问题，但当消息表有 1 亿行数据时，这个聚合查询会让数据库直接宕机。

解决方案：引入会话快照表 (`wx_session`)

我们采用**“空间换时间”**的策略，维护一张“只有最新状态”的表。

设计哲学：写扩散 (Write Amplification)。
每当 wx_message 写入一条新消息时，同步更新 wx_session 表。

✅ 表结构设计

CREATE TABLE wx_session (
    id BIGINT NOT NULL,
    account_id BIGINT NOT NULL,
    session_id BIGINT NOT NULL,
    
    -- 【预览优化】不要存原始 JSON，只存用于列表展示的文本
    -- 例如："[图片]"、"张三: 晚上吃啥？"
    last_message_digest VARCHAR(500) DEFAULT '',
    
    -- 用于列表排序
    last_msg_time BIGINT NOT NULL,
    unread_count INT DEFAULT 0,
    
    PRIMARY KEY (id),
    UNIQUE KEY uk_acc_sess (account_id, session_id), -- 物理防重
    INDEX idx_list (account_id, last_msg_time DESC)   -- 列表查询专用索引
);

收益：
查询会话列表时，不再需要去亿级消息海里捞针，而是直接查这张只有几万行数据的快照表：

-- 极速响应的列表查询（复杂度 O(1)）
SELECT * FROM wx_session 
WHERE account_id = 101 
ORDER BY last_msg_time DESC 
LIMIT 20;

总结

构建一个高可用、可扩展的 IM 消息系统，数据库设计是基石。通过今天的实战演练，我们总结出这套架构的三大核心策略：

统一 ID：利用全局 ID 策略消除“类型”字段，简化逻辑，让 ID 自解释。
会话归一：放弃 receiver_id，使用 session_id 统一私聊与群聊，让消息查询变成简单的单表查询。
读写分离：通过 wx_session 快照表，利用写扩散策略，将获取首页列表显示的最新消息信息这一高频操作的复杂度从 O(N) 降为 O(1)。
分片预留：始终冗余 account_id，为未来的分库分表留好后路。

不要让业务的复杂性污染了你的架构。好的设计，应该像乐高积木一样，模块清晰，插拔自如。

本文由mdnice多平台发布

拒绝“大宽表”进阶篇：如何设计十亿级 IM 消息系统的“会话架构”？