Redis里怎么能快点拿到Key，读Key值那些事儿聊聊

首先得明白，Redis 本身已经非常快了，因为它把所有数据都放在内存里操作，这比从硬盘上读数据快了几个数量级，我们说的“快点”，往往不是指 Redis 服务本身慢，而是我们使用它的方式可能不够高效，或者数据模型设计得有优化空间,这事儿咱们可以从几个方面来聊。

第一点，也是最根本的：别用那些拖慢速度的命令。

有个命令叫 KEYS，它后面可以跟一个模式，KEYS user:*，就能找出所有以 “user:” 开头的 key，这个命令在测试或者数据量极小的时候用用还行，但绝对不要在生产环境用，为什么？因为 Redis 是单线程的，它执行 KEYS 命令的时候会一次性遍历整个数据库的所有 key，如果库里存了几百万、几千万个 key，这个命令就会阻塞住 Redis，导致其他所有请求都得等着，整个服务就跟卡死了一样,这简直是灾难性的。

那我想找符合某个模式的 key 怎么办？这时候就得用 SCAN 命令。（来源：Redis官方文档对KEYS和SCAN命令的说明）SCAN 命令的好处是它不会一次性遍历所有 key，而是分批进行，每次只返回一小部分 key 和一个游标（cursor），你拿着这个游标再次调用 SCAN，它就从上次停下的地方继续扫描，这样虽然总的扫描时间可能差不多，但它是分多次进行的，每次只阻塞 Redis 极短的时间，不会对服务造成明显的影响，就像一点一点地搬东西,不影响别人过路一样。

第二点，设计 key 的时候要动脑筋，好的设计能省很多事。

有时候我们并不是要“找”key，而是已经知道了 key 的名字，只是想“取”它的值，这种情况下，最快的命令就是 GET，问题的关键就变成了：你怎么能快速地知道这个 key 的全名是什么？

举个例子，比如我们要存储用户信息，一种做法是把用户ID放在 key 里，像 user:10001, user:10002，如果你知道用户ID是10001，那你直接 GET user:10001 就拿到了，速度飞快，但如果你需要通过用户名“张三”来找他的信息怎么办？你不可能用 KEYS user:*张三* 去模糊匹配。

这时候就需要一点“空间换时间”的思路，你可以额外维护一个 key-value 对，key 是 username:张三，value 是他的用户ID “10001”。（来源：常见的Redis数据模型设计实践）这样，你的查询就分成了两步：第一步，GET username:张三，拿到用户ID；第二步，GET user:10001，拿到详细信息，虽然要查询两次，但两次都是极快的精确查找（时间复杂度O(1)），远远快于一次慢速的模糊匹配，这种通过增加一个“索引”来加速查询的方法，在数据库设计中非常普遍，在 Redis 里也同样适用。

第三点，活用 Redis 的数据结构，key 本身不是关键。

我们拿到一个 key，往往是为了拿到它对应的 value，但 value 不一定就是一个简单的字符串，Redis 提供了好几种数据结构，比如哈希（Hash）、列表（List）、集合（Set）等。

比如还是用户信息的例子，如果你把用户的所有信息（姓名、年龄、城市等）都用一个个独立的 key 来存，user:10001:name, user:10001:age，那你就要分别获取好几次，虽然每次也很快，但网络通信的次数多了,总时间就会增加。

更好的办法是使用哈希（Hash）结构，你可以用一个 key，user:10001，它的 value 是一个哈希表，里面包含了 name、age、city 等多个字段，这样，你可以用 HGETALL user:10001 一次就把所有字段和值都取回来，或者，如果你只关心姓名和年龄，可以用 HMGET user:10001 name age 只获取指定的字段，这样既减少了网络往返的次数，也避免了处理多个 key 的麻烦，效率自然就上去了。（来源：Redis官方文档对Hash数据结构的介绍）

第四点，一些锦上添花的技巧。

1. 管道（Pipeline）：如果你确实需要一次性获取多个互不相关的 key 的值，比如既要 GET keyA，又要 GET keyB，那么使用管道（Pipeline）可以把多个请求打包在一起发送给 Redis，Redis 处理完后再一次性返回结果。（来源：Redis官方文档对Pipeline的介绍）这大大减少了网络往返的时间延迟（Round-Trip Time, RTT）,在高并发场景下提升非常明显。
2. 合理的持久化策略：虽然这更影响重启后的恢复速度，但间接也关系到“读”的体验，如果配置了AOF持久化，并且日志文件太大，Redis在启动时需要重放AOF日志来恢复数据，这个时间会很长，导致这段时间服务不可用，根据业务对数据安全性的要求，选择合适的持久化方案和触发条件，保证快速启动，也能让你“想读就读”。
3. 避免大Key：如果一个 key 对应的 value 非常大，比如一个哈希表存了几十万个字段，或者一个字符串值有幾MB大，那么网络传输和解码这个 value 都会消耗较多时间和资源，在设计时就要尽量避免产生这种“大Key”,可以考虑将大数据拆分。

在 Redis 里要想快点拿到 key 的值，核心思路就是：避免使用阻塞命令如 KEYS，改用 SCAN；精心设计 key 和数据结构，多用索引和复合结构如 Hash；在必要时使用管道技术减少网络开销。 归根结底，快慢不仅取决于 Redis 本身,更取决于使用它的人怎么去驾驭它。