Redis的键值设计

结构化数据库的特点在于，需要事先严格定义好字段名，字段类型，长度，缺省值，取值范围，约束条件等，而且必须保证所有记录的所有字段都严格按结构设计来保存数据，否则不允许保存。关系型数据库在入库前进行了大量的检查和处理工作，如 SQL Server, Oracle, MySQL, PostgerSQL。

半结构化数据库则没有这些限制，可以较灵活地保存数据，入库时数据库本身不做严格检查，而是到客户端应用程序使用时，再检查数据的正确性和可用性，这样可极大提高数据的读写性能，如 MongoDB, Hbase ,Redis。

非结构化数据无明显的数据库结构可言，可作为一个整体数据进行保存，如文档，图像，音视频等。

Redis数据库是一个键值对数据库，提供了5种基本数据类型，利用键名对数据进行保存和读取。Redis的业务处理逻辑，包含在了Redis的键值的设计中，一般是利用实际的业务数据，动态拼装键名，来进行相关数据的保存和读取。因此客户端应用程序需要有一个统一的键值设计方案，才能有效实现相应的业务逻辑。

本文提供了一种对Redis键名进行结构化设计的方案。

键名的长度：可达512M，但键名越长，越占资源，需要权衡

以下提供的命名项目，中间用冒号（:）分隔，其中（2,3,4,6）项是基本的，其他项目可以根据需要进行取舍使用。

序号	条目	说明	举例
1	实体族	也可理解为命令空间，Schema等	sys
2	实体名	表名，包括系统表	user
3	查询字段名	查找字段，或用于定位相关业务信息缺省字段可以省略不写，如主键字段	userid
4	查询字段值	具体业务内容，跟查询字段名对应	888
5	数据值对应的列族名	字段族，参考Hbase的结构设计	base
6	数据值对应的列名	当前键要保存的数据值对应的数据列名即当【查询字段名】= 【查找字段值】时，获得的内容对应的数据列名	username
7	数据值的版本号	参考Hbase的结构设计，可保留值的多个版本信息
8	数据值的时间戳	参考Hbase的结构设计

表名： user

表名： role

序号	字段名	说明
1	roleid	关系型数据库的表物理主键，在Redis中，若没有引用，则可不要
2	rolename	角色名称，固定值为 visitor, admin

表名：loginlog ：登录历史表

序号	字段名	说明
1	loginlogid	关系型数据库的表物理主键，在Redis中，若没有引用，则可不要
2	userid	用户名称
3	logintime	登录时间
4	logouttime	退出时间

表名：online ：在线人员

序号	字段名	说明
1	onlineid	关系型数据库的表物理主键，在Redis中，若没有引用，则可不要
2	userid	用户id
3	logintime	登录时间
4	token	令牌

序号	键名设计（包含的内容）	举例
1	1:2:3:4:5:6:7:8	key = sys:user:userid:888:base:username:1:217453 value = username的值
2	2:3:4:6 实体名:查询字段名:字段值:列名	key = user:userid:888:username： value = username的值，可通过userid, 获得username key = user:username:edwin:userid value = userid, 可通过username 找到 userid
3	2:4:6 实体名:{字段值}:列名	key = user:888:username (对应主键字段名为 userid) value = username的值只适合主键字段（或每个实体的缺省字段）不建议根据数据类型来区别不同字段,代码容易混
4	2:4 实体名: {字段值}	key = user:888 （对应缺省主键字段: userid） value = 跟当前userid 相关的值列表
5	2:3 实体名:字段名	key = online:userid value = 所有在线用户的userid列表
6	2: 实体名:	key = loginlog: value = 日志列表
	扩展用法	结合多个列，甚至多个实体的组合键设计

在redis 中，键名是唯一的，都在同一个级别；但不同的键，保存的信息各不相同：

保存整个 entity的相关内容，
- 保存entity的一条记录；
- 保存entity的一条记录的一个字段的值，
- 保存一对多的关系，
- 保存多对多的关系，等等

近期文章