用Redis栈玩出花样，性能提升其实没那么难讲究

根据一篇关于Redis List结构多种应用场景的技术博客核心思想整理）

直接用Redis栈玩出花样，性能提升其实没那么难讲究，很多人一提到Redis，就觉得它是缓存神器，但其实它里面一个小功能用好了，能帮你解决大问题，今天不说那些复杂的，就说说这个最像“栈”的结构——List，你别觉得它简单,里面讲究可多了。

先说说它为啥像个“万能胶水”

Redis的List，说白了就是一个字符串列表，你可以从左边放进去，也可以从右边放进去，同样也能从两边取出来，就是这个简单的左右进出，能变出好多花样，你可以把它当栈用，后进先出；也可以当队列用，先进先出；甚至还能当个阻塞队列用，用处特别灵活，这就像一块积木，看着简单,但能搭出各种形状。

第一个讲究：用它搞定消息队列，简单又稳当

（来源：文章中提到Redis List作为轻量级消息队列的应用） 这是最经典的一个用法，比如你的网站有个功能，用户注册成功后要给他发个欢迎邮件，发邮件这个事比较慢，你不能让用户干等着注册页面转圈圈对吧？这时候就可以用上Redis的List了。 具体怎么做呢？当用户注册成功那一刻，你不是直接去调发邮件的接口，而是把这个发邮件的任务（比如用户的邮箱地址、邮件模板ID这些信息打包成一个字符串）从左边“推”进一个叫“task:send_email”的List里面，这步操作非常快，用户的注册流程立马就结束了，体验很流畅。 你后台可以专门开一个或多个“工人”程序，它们啥也不干，就盯着这个List，从右边不停地“拉”出任务来执行，也就是真正去发送邮件，这样就把耗时的操作和主要的业务逻辑分开了，专业点叫“解耦”，就算一瞬间来了很多注册用户，任务也只是在List里排个队，不会把你的主服务器压垮，这种用法，对于不是极端要求百分百可靠消息的场景，比如发通知、更新排行榜等，完全够用了，而且比搭建一套专业的消息队列系统（比如RabbitMQ）要简单太多了。

第二个讲究：玩出花的“阻塞”模式，让工人不白忙活

（来源：文章重点介绍了BLPOP/BRPOP命令的优势） 上面那个方法有个小问题：如果List里暂时没任务了，你的工人程序就会不停地去“拉”，结果每次都是空，这就成了“空轮询”，白白浪费CPU资源，Redis早就替你想好了，它提供了带“B”开头的命令，比如BLPOP（阻塞式左弹出）。 这个命令就讲究了，工人程序执行BLPOP task:send_email 30，意思是：我去List里取任务，如果有任务我立马拿走去处理；如果现在没任务，我就在这儿等着你，最多等30秒，在这30秒内，只要有新任务进来，我马上就能拿到并开始工作；如果30秒到了还没任务，我才返回一个空值，然后可以再次发起等待，这样就避免了无用的空转，让工人程序该休息时就休息，大大节省了系统资源，这个“阻塞”特性,让这个简单的消息队列变得非常高效和环保。

第三个讲究：不只是队列，还是记录历史的“时光机”

（来源：文章列举了利用LRANGE命令实现最新动态展示的例子） List的另一个妙用是当“动态列表”或者“历史记录”，比如很多应用里都有“最新动态”、“最近浏览”这样的功能，你可以把用户的每一个新动态（用户A点赞了文章B”）从左边推入一个叫“user:123:feeds”的List里。 但List长度不能无限增长啊，不然内存受不了，这时候可以用LTRIM命令来限制长度，比如你只保留最新的50条动态，那么每次插入新动态后，就执行一下LTRIM user:123:feeds 0 49，意思是只保留列表里从第0个到第49个的元素，更老的动态自动被丢弃了，当需要展示时，直接用LRANGE命令一次性取出最新的0到N条，非常方便，这个组合拳（LPUSH + LTRIM）实现了的是一个封顶的栈，完美契合了“最新N条”的需求，比如网站的最新100条评论、用户的最近10个搜索记录等，性能比去数据库里ORDER BY time DESC LIMIT N要快得多。

第四个讲究：轻松实现排行榜之外的“最新榜”

（来源：文章对比了Sorted Set和List在不同场景下的适用性） 大家都知道Redis的Sorted Set做排行榜很厉害，因为它能排序，但有时候你不需要复杂的分数排序，你只关心哪个是最新的，比如一个文章的评论列表，默认按时间倒序，最新的在最前面，这时候用List就比用Sorted Set更合适、更轻量。 每一条新评论产生时，用LPUSH把它塞进“article:456:comments”这个List的头部，那么当你用LRANGE取出前20条时，自然就是最新的20条评论，这个操作的时间复杂度是O(1)到O(N)（N是你获取的评论数），效率极高，而如果用Sorted Set，你需要给每条评论设置一个时间戳分数，虽然也能实现，但数据结构更重，操作成本也略高一点，在这种“唯新是图”的场景下,List是性价比更高的选择。

总结一下

你看，就这么一个Redis List，稍微讲究一下用法，就能在消息队列、动态流、历史记录这些常见场景里大显身手，轻松提升应用性能，关键它概念简单，上手快，不需要引入复杂的中间件，它也不是万能的，比如它不能做到消息的严格可靠（如果工人程序在处理任务时崩溃，这个任务可能就丢了），但对于很多一致性要求不是那么极致的场景，用它来做性能优化，绝对是事半功倍的好选择，下次当你遇到需要解耦、缓冲、存最新列表的需求时，先别急着搞复杂的架构，想想这个藏在Redis里的小小栈,说不定它就能给你带来意想不到的惊喜。