为何选用Redis有序集合而非列表？存文章场景的技术疑问

其实这俩的核心区别在于设计目标完全不同——List是个“有序队列”，Sorted Set是个“可排序的唯一集合”，看似都能存有序数据，但实际用起来差远了，咱们结合你的文章存储场景拆解：

1. 排序逻辑的灵活性：动态有序 vs 固定插入顺序 #

• List的有序是死的：你用LPUSH/RPUSH只能在头尾加元素，顺序完全由插入时间决定。如果用List存文章，新文章RPUSH确实能放最后（按时间戳从旧到新），但如果某篇文章更新了时间（比如编辑后），你想调整它的位置？得先LINDEX遍历找元素，再LREM删掉，最后重新插入，数据量大的时候这复杂度O(N)，完全没法用。
• Sorted Set的有序是活的：它靠你指定的score（这里就是Unix时间戳）自动排序。新文章直接ZADD，Redis会把它放到对应时间戳的位置，复杂度O(logN)；要更新文章时间？直接ZADD同一个文章ID+新时间戳，旧记录自动覆盖，同样高效。

2. 文章场景的刚需能力：快速范围查询+自动去重 #

• 范围查询秒杀List：比如你要取“最近7天的文章”，Sorted Set直接用ZRANGEBYSCORE，传入当前时间戳减604800的数值，一秒就能拿到结果；List呢？你得从头遍历每个元素，一个个判断时间戳，数据多的时候这就是性能灾难。
• 自动去重省麻烦：Sorted Set里的member是唯一的，就算你重复添加同一篇文章（比如系统重试），Redis会自动用新的时间戳覆盖旧的，不会出现重复数据；List可不管这个，你推多少次就存多少条，还得自己在应用层做去重，额外增加代码量和出错概率。

3. 你提到的集合操作：隐藏的扩展潜力 #

这才是Sorted Set最厉害的地方，也是List完全做不到的。比如：

• 你有「所有用户发布的文章」（按时间戳排序的Sorted Set），还有「我关注的作者列表」（Set），可以用ZINTERSTORE直接算出“我关注的作者最近发布的文章”，还能保留时间戳排序；
• 甚至可以和其他Sorted Set做交集、并集，比如“最近一周点赞量Top10的文章”+“我关注的作者文章”，直接算出我关注的作者里的热门内容。

换成List的话，你得把两个List的所有数据拉到应用层，自己写代码做交集、排序，不仅占用大量带宽和内存，性能还极差，后续扩展功能也会越来越难。

最后总结 #

如果只是简单的“先进先出”场景（比如消息队列），List足够用，但如果你的场景需要基于数值动态排序、快速范围查询、自动去重，或者后续要做集合运算，Sorted Set绝对是最优解——这也是很多内容平台用它存文章、动态流的核心原因。

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