Redis Key 设计原则

Redis 是 K-V 数据库，良好的 KEY 的设计对于一个 K-V 数据库来说也是至关重要的。本文主要根据网上流传较多的一种方案进行简单总结，如你有更好的方案或者不同的方案，欢迎来稿。

可以参考关系型数据库的表来设计，设计原则如下：

1. 表名转换为 KEY 前缀
2. 第 2 段放置用于区分 KEY 的字段，对应 MySQL 中主键的列名
3. 第 3 段放置主键的值或者唯一键的值
4. 第 4 段写要存储的列名

例如：User 表 ，userid 是主键，系统出了根据 userid 查询之外，还经常根据 username 进行查询。

set user:userid:10:username zhangsan
set user:userid:10:email    aa@126.com
set user:userid:10:age      20

1. 根据主键查询用户信息

使用 keys user:userid:10* 即可查询到用户的信息。如果是集群环境 user:userid:10 的信息一般只会在一台服务器上，这样在查询某个用户信息时，就不需要多次切换 Redis 服务器了。根据主键查询没有问题了，但是如果是根据用户名查询呢？

2. 根据用户名查询

如果要根据用户名查询，那只能再使用用户名进行存储一遍，具体如下：

set user:username:lisi:userid 10

注意，此处是存储如上一条数据即可，不需要再存储 email 和 age 了，如果需要查询 email 或者 age 的值时，则先根据用户名查询到 userid = 10，然后再根据 userid 查询其他属性的值。

假如还要按照 email 进行查询呢？那只能再对 email 进行冗余，方法同根据用户名查询类似。

是的，这的的确确浪费了很多内存，这其实就是空间与实践取舍的问题，就像鱼与熊掌不可兼得。其实 MySQL 也是一样的道理，如果经常使用某列做为条件查询时，一般会对该列添加索引，同样会增加存储空间。