Redis怎么查那些藏着的老数据，挖掘过去信息其实没那么难

说到查Redis里的老数据,很多人可能会觉得头疼，觉得Redis就是个快进快出的缓存，数据一会儿就没了，上哪去找过去的记录？其实不然，只要用对方法，把Redis当成一个轻量的时序数据库或者键值档案库来用，挖掘历史信息并没有想象中那么难，关键在于，你不能等到需要的时候才想起来去找，而是得提前做些准备，下面这几种方法，就是一些实际应用中人们常用来“考古”Redis数据的路子。

最直接的一招,就是去翻Redis的持久化文件，Redis为了怕断电丢数据，自己有个机制叫RDB，你可以把它理解成给内存里的数据拍一张快照，然后存到硬盘上一个叫dump.rdb的文件里，这个文件里面就是某个时间点Redis里所有数据的样子，当你需要查看过去的数据，比如想看看昨天凌晨系统某个状态值时，你就可以找到昨天备份的那个dump.rdb文件，RDB文件是二进制的，人眼没法直接看，你得用一些专门的工具来解析它，网上能找到一些开源的RDB文件解析工具，比如用Python写的redis-rdb-tools（来源：GitHub上的开源项目redis-rdb-tools），它能把这个二进制文件解析成可读的格式，比如直接转换成CSV表格，或者生成一份报告，告诉你里面都有哪些类型的键，占多大空间，你甚至可以用它把RDB文件里的数据一点点“回放”出来，慢慢检查，这个方法的好处是，它能让你看到一份非常“原始”的数据档案，但缺点也很明显，就是不够灵活，你只能看到你拍快照那个瞬间的数据，快照之后发生的变化就完全不知道了，通常为了不影响性能，快照不会拍得太频繁，所以用这个方法只能看到一些时间点上的“切片”，而不是连续的历史。

如果你需要更连续、更细致地追踪数据的变化，那就得用上Redis的另一个功能，叫做AOF（Append Only File），这个AOF的思路和RDB拍快照不一样，它不记录结果，而是记录过程，Redis执行的所有写命令，比如SET、HSET、LPUSH这些，它都会按顺序记到这个AOF文件里，这个文件就是个纯文本文件，你可以把它想象成Redis的“操作日志”，当你想追溯一个键是怎么一步步变成现在这个样子的时候，AOF文件就是你的宝藏，你可以用任何文本编辑器打开这个文件（如果文件很大的话，需要用less、tail这种命令行工具），然后像查日志一样去搜索你关心的那个键的名字，你会看到关于这个键的所有历史操作命令和当时设置的值，这个方法非常强大，因为它记录了每一个细节的变化，它的缺点就是文件可能会长得吓人，而且里面记录了所有操作，如果你只想看某一个键的历史，需要自己从海量日志里把它筛出来，比较费劲，Redis本身提供了AOF重写机制来压缩文件，但即便重写后，它保存的也是能重建当前数据集的最小命令集合，对于很久以前的历史，如果重写过，可能就找不到了。

除了直接翻看持久化文件这种“离线”方式，更聪明一点的做法是“在线”处理，也就是在数据产生的同时，就为追溯历史做好准备，一个常见的做法是借助Redis本身的数据结构，你不光用一个普通的字符串键来存当前的最新值，同时再用一个列表（List）或者有序集合（Sorted Set）来给这个键做一个“历史记录簿”，每次更新这个键的值时，除了执行SET命令，你还执行一条命令，比如LPUSH，把旧的值或者新的值连同时间戳一起，塞到对应的列表里，这样，这个列表里就按时间顺序保存了这个键的历次变更记录，你想查历史的时候，直接用LRANGE命令从这个列表里取出一段时间范围内的记录就行了，有序集合则更强大，你可以把时间戳作为分数（score），把数据作为成员（member）存进去，这样查询某个时间段的变更就非常方便和高效，这种做法把历史数据的管理集成到了业务逻辑里，查询起来最快最直接，但需要你在设计应用代码的时候就考虑到这点，稍微多写几行代码。

还有一种思路,是把这个记录变更的活儿交给Redis的发布订阅（Pub/Sub）或者更强大的流（Stream）数据结构来做，尤其是Stream，它是Redis 5.0之后加入的，天生就是为了处理时序数据流，你可以把每个数据的变更都当作一个事件写入一个Stream中，这个事件里可以包含丰富的信息，比如旧值、新值、变更时间、操作者等，你可以建立多个消费者组来消费这些流，其中一个消费者组就可以专门负责把事件归档到其他地方（比如数据库或文件）做长期存储，这样，Redis本身主要负责接收和暂存最近的变更流，而查询深厚历史的任务就交给了更擅长做这个的数据库，这相当于构建了一个小型的、基于Redis的数据管道。（来源：Redis官方文档对Stream数据结构的介绍）

你看,Redis查老数据并不是无计可施，从最简单的解析备份文件，到翻阅操作日志，再到主动用数据结构记录历史，乃至利用流构建数据管道，方法有很多种，各有各的适用场景，选哪种，主要看你对历史数据的需求有多细致，以及你愿意为此付出多少提前的设计和存储成本，核心思想就一个：想要挖掘过去，最好在当下就埋下线索。