用Redis咋快速拿到最新加进来的数据，感觉挺实用的办法

Redis官方文档、博客文章《Redis patterns for real-time data》以及技术社区讨论）

想要快速拿到Redis最新加入的数据，关键在于利用Redis天然适合处理实时数据的特性，这里直接说几个接地气的办法,完全避开复杂概念。

最直接的玩法：利用列表（List）的天然顺序 Redis的列表结构就像个只进不出的管道（当然也可以弹出），新数据从一边推进去，老数据在另一边排队，当你用LPUSH命令把新数据塞进列表头部时，它永远在最前面，这时候，如果你想要最新加入的，直接用LINDEX key 0就能瞬间拿到刚塞进去的那条，如果想持续监控，可以用BLPOP命令卡着列表的尾部（如果数据是从左边推进去的，尾部就是最老的数据），但这样拿的是最旧的，不过反过来想，如果你把新数据总是用RPUSH放到列表尾部，然后用BRPOP阻塞等待，一旦有新数据进来，客户端就能立刻拿到这个最新的条目。（来源：Redis命令手册）

但列表有个麻烦：数据可能重复，而且如果只是要“最新”而不是顺序消费，可能有点重，这时候可以考虑流（Stream）——这是Redis 5.0后专门为实时数据设计的结构。（来源：Redis博客《Introducing Redis Streams》）它就像个消息队列，每条数据带个唯一ID（默认用时间戳生成），你往流里用XADD添加数据时，ID自动递增，要拿最新的？直接用XREVRANGE key + - COUNT 1，其中表示最大ID，表示最小ID（这里反着查），COUNT 1就只要最后一条，这个操作是O(log N)的,数据再多也几乎瞬间返回。

更省事的懒人方案：直接用有序集合（Sorted Set）绑时间戳 如果你每条数据都有个时间戳（比如毫秒时间），可以把它当分数塞进有序集合，新数据进来时，用ZADD key 分数值 数据，分数用当前时间戳（比如表示毫秒时间），要拿最新的？直接ZREVRANGE key 0 0 WITHSCORES，从大到小排序取第一个，就是最新加入的，因为有序集合底层是跳表，查最大最小值快得离谱。（来源：Redis数据结构的内部实现文档）

但上面这些都要主动去查，如果想实现“数据一来就推给我”的效果，就得用发布订阅（Pub/Sub）模式。（来源：Redis实战案例分享）比如多个客户端订阅一个频道，只要有发布者用PUBLISH发送新数据，所有订阅者同时收到，这招适合实时通知，比如弹幕、聊天室，但注意，Pub/Sub不存历史数据，如果客户端掉线了,期间的消息就丢了。

组合拳：流+消费者组（Consumer Group）保稳 如果既要实时又要可靠，可以用流的消费者组功能。（来源：Redis模式设计指南）比如你启动一个消费者组，用XREADGROUP阻塞等待新消息，新数据一到，自动分配给空闲的消费者，而且已读的数据会记录消费位移，就算客户端重启也能从上次的位置继续拿，这招在电商秒杀、实时监控里常用，既能秒级响应,又不怕丢数据。

极端情况下的土方法：用字符串（String）存最新值 如果数据特别简单，比如只是个数字或短字符串，直接SET key new_value覆盖更新，然后GET key拿到的永远是最新的，虽然听起来糙，但Redis单线程保证原子性，不会读到中间状态，比如统计在线人数，每秒更新一次，别的客户端随时GET都是最新数。（来源：Redis应用小技巧汇总）

性能注意点 这些方法之所以快，是因为Redis所有数据放内存，操作基本是O(1)或O(log N)，但别往里面塞大对象，比如几MB的JSON，网络传输反而成瓶颈，建议压缩数据，或只存ID再去数据库查详情。（来源：Redis性能优化实践）

如果数据量爆炸，记得设过期时间（EXPIRE），不然内存撑爆了再快的操作也白搭，实际选方案时，根据你是要“实时推送”还是“主动查询”，要不要持久化，来决定用流、Pub/Sub还是列表。