Redis固定大小列表（capped list）去重：用户改名致重复条目如何解决？

这问题我之前也帮不少开发者解决过，核心问题在于Redis的List本身允许重复元素，而capped list的逻辑只是帮你截断过长的列表，不会自动去重或更新旧条目。要解决这个问题，核心思路是先基于唯一用户标识去重，再维护访问顺序，下面给你几个实用的方案：

方案一：Hash + Capped List 组合（推荐，直观易维护） #

这种方案用Hash存储用户的最新信息，用List维护最近访问的用户ID（作为capped list），既保证了用户信息的实时性，又能避免重复条目。

具体操作步骤： #

1. 维护用户最新信息：用Hash结构，key设为user:profile，field是用户唯一ID，value是最新的用户信息（包含改名后的名称）。每次用户修改名称或访问页面时，先更新Hash：

   HSET user:profile 1001 '{"user_id":1001,"name":"新昵称","visit_time":"2024-05-20 14:30"}'
   

2. 处理最近访问列表：每次用户访问时，先移除列表中已存在的该用户ID（避免重复），再将ID加到列表头部，最后截断列表到固定大小：

   # 移除列表中所有该用户ID（0代表移除所有匹配项）
   LREM recent_visitors 0 1001
   # 将用户ID加到列表头部
   LPUSH recent_visitors 1001
   # 截断列表，只保留前100条（假设固定大小是100）
   LTRIM recent_visitors 0 99
   

3. 获取最近访问用户信息：先从List中取出用户ID，再批量从Hash中获取最新信息：

   # 获取前10条最近访问的用户ID
   LRANGE recent_visitors 0 9
   # 批量获取用户最新信息
   HMGET user:profile 1001 1002 1003
   

优缺点： #

• 优点：逻辑直观，List的顺序严格对应访问顺序，适合对访问时序要求精确的场景。
• 缺点：LREM命令是O(N)复杂度，当列表很大时（比如超过1000条），性能会有所下降。

方案二：Sorted Set 替代 List（性能更优） #

如果你的访问列表比较大，推荐用Sorted Set，它天然支持去重（member唯一），还能通过score维护访问时间顺序，操作效率更高。

具体操作步骤： #

1. 记录用户访问：用Sorted Set，key设为recent_visitors，member是用户唯一ID，score设为当前时间戳（保证最新访问的排在前面）。每次用户访问或改名时，更新该用户的score：

   # 用当前时间戳作为score，自动去重（同一用户ID重复添加会更新score）
   ZADD recent_visitors 1716196200 1001
   

2. 维持固定大小：每次操作后，截断Sorted Set只保留最近的N条数据（比如100条）：

   # 移除排名在第100名之后的元素（只保留前100条）
   ZREMRANGEBYRANK recent_visitors 0 -101
   

3. 获取最近访问用户信息：按score倒序取用户ID，再从Hash中拿最新信息：

   # 获取前10条最近访问的用户ID（倒序，最新的在前）
   ZREVRANGE recent_visitors 0 9
   # 批量获取用户信息
   HMGET user:profile 1001 1002 1003
   

优缺点： #

• 优点：ZADD和ZREMRANGEBYRANK都是O(logN)复杂度，大列表场景下性能远优于List方案；天然去重，无需手动处理重复ID。
• 缺点：访问顺序是基于时间戳的近似顺序，如果同一时间有多个用户访问，顺序不会像List那样精确到毫秒级的操作顺序（但大多数场景下足够用）。

关键注意事项 #

不管用哪种方案，用户信息里必须包含唯一的用户标识（比如user_id），这是识别同一用户、避免重复的核心依据——不能只靠用户名判断，因为用户名是可变的。

内容的提问来源于stack exchange，提问作者John S