在即时通讯系统中，离线消息的可靠存储与快速下发是影响用户体验的核心环节。当接收方不在线时，发送方发出的消息需要被暂时保存，待对方上线后尽快送达。传统做法是把每条消息直接写入关系型数据库，用户上线时再通过查询接口拉取。这种方式在高并发场景下，数据库的写入和读取压力会急剧上升，消息到达延迟也可能随之增加。
Redis拥有丰富的数据结构，并且所有操作都在内存中完成，单实例可以支撑每秒十万级以上的读写。把离线聊天记录先写入Redis，由Redis充当消息暂存区，再通过异步任务批量落库，可以在保证用户体验的同时，显著降低后端数据库的负载。下面从数据结构选择、具体实现和优化策略三个角度详细展开。
为什么Redis适合作为离线消息的暂存层
Redis的列表（List）和有序集合（Sorted Set）是存储离线消息最常用的两种结构。列表是一个双向链表，支持从左侧或右侧压入和弹出元素，天然符合“先发送的消息先被读取”的队列语义。每个用户的离线消息可以用一个独立的键来保存，键名设计为offline:msg:{userId}。发送方离线消息到达时，通过RPUSH命令把消息ID追加到接收方对应的列表尾部。接收方上线后，通过LRANGE命令一次性拉取全部内容，再用DEL删除该键。
有序集合则适合需要按时间排序或分页拉取的场景。它会给每个成员关联一个分数（score），通常使用消息的发送时间戳。通过ZADD写入，通过ZRANGEBYSCORE按时间范围读取。相比列表，有序集合支持按分数范围删除或查询，便于实现“只拉取最近N条”或“清理过期消息”的需求。不过有序集合底层是跳表加哈希表，内存占用比列表略高，如果离线消息量极大，需要权衡选择。
除了数据结构本身的优势，Redis的持久化机制也为离线消息提供了一定程度的数据安全性。开启AOF（Append Only File）持久化后，每条写入命令都会被记录到磁盘，即使Redis进程重启，也能恢复大部分数据。结合主从复制和哨兵模式，离线消息暂存层可以具备较高的可用性。需要注意，Redis持久化并非实时落盘，极端情况下可能出现少量数据丢失，因此对于可靠性要求极高的系统，仍需配合数据库或消息队列进行最终确认。
离线聊天记录存储的具体实现方案
以列表结构为例，假设聊天消息已经在业务服务中生成并获得了全局唯一的消息ID，发送方调用接口发送消息时，业务层先判断接收方是否在线。如果在线，直接通过长连接推送即可。如果不在线，则执行以下Redis命令：
# 将消息ID追加到接收方的离线队列 RPUSH offline:msg:10086 "msg:20250315:001" # 设置离线消息的过期时间，例如7天 EXPIRE offline:msg:10086 604800
接收方上线后，客户端或网关服务可以向Redis发起读取请求。业务层使用LRANGE获取全部离线消息ID，再根据这些ID去消息详情存储中查询具体内容。读取完成后必须执行DEL命令删除该键，否则消息会重复下发。完整的读取逻辑可以封装为以下伪代码：
import redis
r = redis.Redis(host='127.0.0.1', port=6379, db=0, decode_responses=True)
def get_offline_messages(user_id: int):
key = f"offline:msg:{user_id}"
# 一次性拉取所有离线消息ID
msg_ids = r.lrange(key, 0, -1)
if msg_ids:
# 读取完毕后立即删除，防止重复消费
r.delete(key)
return msg_ids
如果使用有序集合存储，写入时用ZADD，读取时用ZRANGE按时间正序获取，同样在读取后删除整个键。有序集合还支持按分数范围清理过期数据，例如每天定时执行ZREMRANGEBYSCORE删除七天前的消息，比列表的粗暴过期策略更精细。
另一种常见做法是结合Redis发布订阅或Stream。Redis 5.0之后引入的Stream数据结构支持消费者组、消息确认和持久化，非常接近消息队列的语义。将离线消息写入Stream，接收方上线后通过消费者组读取，可以避免“读取即删除”带来的可靠性风险。不过Stream的学习成本和运维复杂度比List略高，适合消息量较大且需要多消费者协作的场景。
离线存储的可靠性与内存优化
单纯依赖Redis保存离线消息，一旦Redis实例宕机且没有正确配置持久化，所有未消费的消息都会丢失。解决这个问题通常采用“双写”策略：消息先写入Redis作为快速下发通道，同时异步写入数据库或消息中间件作为持久化备份。当用户上线从Redis读取时，如果发现Redis中数据缺失或部分丢失，可以从数据库备份中补齐。数据库存储离线消息的表结构通常包含消息ID、发送方、接收方、时间戳和消息体等字段，接收方读取后标记为已读，避免重复推给客户端。
内存优化是另一项需要提前规划的工作。如果离线消息量巨大，所有消息都以字符串形式堆在Redis中，内存会快速耗尽。常见的优化手段包括：只存储消息ID而不是完整消息体，把消息内容放入对象存储或数据库；对消息ID做短编码，例如使用雪花算法生成的64位整数而非长字符串；控制每个用户离线消息的条数上限，超过上限后将最早的消息自动落库并从Redis移除。此外，利用Redis的EXPIRE或定时清理任务，可以定期删除长期未读取的离线消息，防止内存被无效数据占满。
实际生产环境中，还需要考虑多机部署下的一致性。用户在线状态通常由网关服务维护，离线消息的写入和读取可能发生在不同节点。为了确保接收方上线后能及时收到所有离线消息，一般会在用户建立连接的瞬间先触发离线队列的读取，再开始接收实时消息。这个顺序需要严格保证，否则可能出现“先收到实时消息，后收到离线消息”的乱序问题。一个简单的处理方式是：客户端上线后先向服务端发送拉取离线消息的请求，服务端处理完毕并返回结果后，客户端再订阅实时推送通道。
Redis的键命名规范也值得注意。使用offline:msg:{userId}这样的前缀可以方便通过SCAN命令批量扫描和清理。如果系统中同时存在多种缓存数据，建议统一使用冒号分隔的层级结构，并在运维文档中明确各前缀的含义，降低误操作风险。