Redis里怎么存列表数据，有啥实用的小技巧分享一下

在Redis里存列表数据，最直接的办法就是用它的List类型，通过LPUSH/RPUSH命令往列表头尾加东西，再用LPOP/RPOP取出来，这听起来很简单，但真想用得好，让它在项目里既快又稳，就得用上一些“小心思”，这些技巧很多来自Redis官方文档的说明、社区的最佳实践讨论,以及一些技术博客里的经验分享。

第一个实用技巧是：用列表当“非实时”的消息队列，但一定要避免队列堵死。

List结构天生就有“先进先出”的特性，所以很多人拿它做简单的消息队列，让生产者用LPUSH把任务塞进一个列表，消费者用RPOP从另一边不停地取任务执行，这个方法很直接，但有个大问题：如果列表是空的，消费者会陷入一个“死循环”，不停地执行RPOP`命令，这既浪费CPU,又给Redis带来无谓的压力。

解决这个问题的“神器”是BRPOP命令，这个B代表“Blocking”（阻塞），你可以让消费者使用BRPOP key timeout，比如BRPOP task_queue 30，它的意思是：去task_queue这个列表里取消息，如果没消息，我就在这等着你，最多等30秒，在这30秒内，一旦有消息进来，我马上拿到并返回；如果超时了还没消息，我再回来，这样，消费者就不会傻傻地空转了，连接也是安静的，这个方法是Redis官方文档里重点推荐的,能极大地提升效率。

第二个技巧是：用列表做“ capped collection”，也就是固定长度的集合，自动踢掉老数据。

我们并不希望一个列表无限制地增长下去，你想存用户最近10次的登录记录，或者一个聊天室里最新的100条消息，这时候，你可以用LPUSH把新数据加进去，然后紧接着执行一个LTRIM key start stop命令。

LTRIM是用来修剪列表的，你执行LPUSH recent_logins "login_info"，然后马上执行LTRIM recent_logins 0 9，这个LTRIM命令的意思是：只保留列表里索引从0到9的这10个元素，其他的全部扔掉，因为LPUSH是把新元素加到左边（头部），所以最新的数据总是在最前面，通过LTRIM一修剪，列表就永远只保持最新的10条记录了，这个“LPUSH + LTRIM”的组合拳，是Redis应用里一个非常经典和高效的模式，在很多开源项目的代码里都能看到,用来管理有限历史记录非常方便。

第三个技巧是：列表不止能存字符串，还能存序列化后的复杂数据。

Redis的列表元素虽然是字符串，但这个字符串的内容可以是任何东西，你可以把PHP的数组、Python的字典、Java的对象，先用JSON序列化一下，变成一串JSON文本，然后存到Redis的列表里，取出来的时候,再反序列化回原来的数据结构。

这样做的好处是，一个列表项就能包含非常丰富的信息，一个消息队列里的任务项，可以不只是任务名，而是一个JSON对象，里面包含了任务ID、执行参数、优先级、创建时间等等，这样消费者拿到一条消息，就能获得执行任务所需的全部信息，不需要再额外去查数据库,这种用法几乎是所有使用Redis做消息队列的项目的标配。

第四个技巧是：小心！列表不适合存特别长的数据。

这是一个重要的提醒，来源于对Redis内部实现的了解（根据Redis官方文档对数据结构的说明），Redis的List在底层实现上，元素数量少的时候用一种叫ziplist的紧凑结构，很省内存，但当元素数量超过某个配置值，或者某个元素体积太大时,它会转成一个标准的双向链表。

双向链表在靠近头尾的地方进行增删操作很快，是O(1)复杂度，如果你要访问列表中间的元素，比如用LINDEX命令找第5000个元素，或者用LRANGE命令取第1000到2000个元素，它的速度是O(N)的，也就是说，会随着列表长度线性下降，如果一个列表有几万、几十万元素，这种操作可能会瞬间阻塞Redis,导致其他请求超时。

经验法则是：把Redis List想象成一个“管道”或者“栈”，只在两端操作它，非常高效，但不要把它当成一个可以随机访问的数组。 如果你的业务场景需要频繁按索引查询长列表的中间部分，那List可能不是最佳选择，可以考虑用Sorted Set（有序集合）或者其他方案。

第五个技巧是：活用多个列表和键名设计来解耦不同状态的数据。

不要把所有的东西都塞进一个列表，比如做一个任务系统,你可以设计三个列表：

1. queue:tasks:pending （待处理任务列表）
2. queue:tasks:processing （处理中任务列表）
3. queue:tasks:failed （失败任务列表）

当一个工作者用BRPOPLPUSH命令（这是一个原子性命令）从pending列表取任务时，可以同时把这个任务塞进processing列表，这样，这个任务就从“待处理”区域移到了“处理中”区域，如果任务处理成功，就从processing列表里删掉；如果失败了，就把它移到failed列表等待重试或人工处理。

这种用多个列表管理不同状态的方法，思路来源于工作流和状态机模型，在Celery等分布式任务队列中也有类似思想，它使得系统的状态非常清晰，你一眼就能看出有多少任务在排队、多少正在处理、多少失败了，便于监控和管理，键名用冒号分隔是一种约定俗成的规范，看起来像路径,比较清晰。

在Redis里用列表，核心思想就是扬长避短，利用它在两端操作的超高速度，通过阻塞命令避免空转，用修剪操作控制长度，用序列化存储复杂数据，并通过合理的键名设计将数据分门别类，只要避开随机访问长列表这个性能陷阱,List就是一个非常强大且实用的工具。