用Redis搞定消息已读未读状态，简单又高效，省心又省力

用Redis来处理消息的已读未读状态，确实是一个既简单又高效的办法，很多做聊天系统或者通知功能的开发者都喜欢用这个方案，因为它速度快，实现起来也不复杂，下面我就详细说说具体怎么搞,以及为什么它这么省心。

你得明白核心思路，我们最需要解决两个问题：第一，怎么记录谁读了哪条消息；第二，怎么快速查出一条消息的已读状态和一个用户的未读消息数，如果用传统的关系型数据库，比如MySQL，频繁地插入和更新“已读记录”这张表，在用户量很大、消息量很大的时候，数据库的压力会非常重，速度也会慢下来，而Redis是内存数据库，所有数据都放在内存里，读写速度极快,特别适合这种需要高频读写的场景。

那具体怎么做呢？一个最直接、最常用的办法就是用Redis的集合（Set）这个数据结构，你可以为每一条消息创建一个独立的Redis集合，这个集合的键名可以用像 message:read:123 这样的格式，其中123是消息的唯一ID，把所有已经读过这条消息的用户ID，当作元素存进这个集合里，当某个用户读了这条消息，你只需要执行一条简单的命令：SADD message:read:123 user_id_456，把用户ID456加到这条消息的已读集合里就行了，这个操作速度非常快，反过来，你想知道这条消息被谁读过，或者判断某个用户是否已读，用 SMEMBERS 或者 SISMEMBER 命令,一下就能查出来。

这是从“消息”的角度来看，从“用户”的角度呢？我们常常需要知道一个用户有多少条未读消息，这个也可以用Redis轻松搞定，一个常见的做法是使用有序集合（Sorted Set），你可以为每一个用户维护一个有序集合，比如键名为 user:unread:456，这个集合里存放的是这个用户还未读的消息ID，而分数（score）可以用消息的发送时间戳来表示，当有新消息产生需要通知给这个用户时，就向他的未读有序集合里 ZADD 一条记录，当用户点开这条消息阅读后，除了上面说的往消息的已读集合里添加用户ID，还要从他自己个人的未读集合中 ZREM 这条消息ID，这样，查询这个用户的未读数，只需要用 ZCARD 命令统计一下他未读集合里还有多少元素,非常高效。

你可能会问，那万一Redis重启，内存数据丢了怎么办？这确实是个需要考虑的问题，Redis本身提供了持久化机制（比如RDB快照和AOF日志），可以根据你对数据安全性的要求进行配置，但对于“已读状态”这种数据，其实有一定的“容错”空间，一种常见的实践是，你可以把它当作一种“缓存”来用，即使Redis数据丢失，也可以从源头的消息记录和用户阅读行为日志里，通过离线计算或批量任务慢慢恢复回来，为了更保险，一些对状态实时性要求不是极端高的场景，也可以定期把Redis里的已读关系同步回MySQL，做个备份，不过在实际中，只要配置好Redis的持久化,丢失的风险是很低的。

用Redis做已读未读，还有一个巨大的好处就是“省心”，它不需要你设计复杂的数据库表结构，不需要频繁地建立和优化索引，像集合运算（求交集、并集）这种在数据库里比较耗时的操作，在Redis里都是原子性的，一条命令搞定，比如你想知道一条消息有哪些人“未读”，理论上你可以把这条消息的所有目标用户ID集合，和已读这条消息的用户ID集合做个差集，就能算出来,这在做群聊消息的已读未读明细时特别有用。

根据一些开发者的实践经验（例如在技术社区如CSDN、博客园中分享的案例），在千万级用户、海量消息的社交或IM场景中，这种基于Redis的方案经受住了考验，它极大地减轻了核心数据库的压力,让消息状态的读写变得轻量而快速。

用Redis搞定已读未读，核心就是活用它的集合和有序集合，通过为每条消息存已读用户集合，为每个用户存未读消息集合，两个维度一结合，就能以很小的代价，实现实时、高效的已读状态查询和未读计数，方案简单直接，性能出色，维护起来也省心省力,确实是应对这类问题的好办法。