上面讲了简单的key存储，如 xdd的存储，此时普通的需求可以满足；然而在实际业务中，往往key键的存储会非常的复杂，比如我们现在有一个需求： 需求：根据基础数据系统中的数据字典类型查询对应的字典集合 这时，我们需要关注的业务就变得复杂了，就不能使用常规的key键存储方式，上面的需求大致可以拆分为： 系统：基础数据系统 user:sex:1=男 user:sex:0= 女 模块：数据字典 sys:available:1=true sys:available:0=false 方法：根据数据字典类型查询 参数：字典类型 为什么要这样拆分呢？为了可读性；也为了抽象出key存储规则；因为业务复杂情况下，我们定义的key键太多时就不便于管理，也不便于查找，以 系统-模块-方法-参数 这样的规则定义，我们可以很清晰的了解redis key存储的值是做了什么事情 common:sys:sex:1 男 common:sys:sex:0 女 common:sys:flag:1 是 common:sys:flag:0 否 common:page:title 欢迎使用XX管理系统 user:1 {id:1.name:小明} user:2 {id:2.name:习大大} 这个在使用工具去查看的时候就可以看出层级关系啦