键值设计

优雅的key结构

Redis的Key虽然可以自定义，但最好遵循下面的几个最佳实践约定：

• 遵循基本格式：[业务名称]：[数据名]：[id]
• 长度不超过44字节
• 不包含特殊字符

例如：我们的登录业务，保存用户信息，其key是这样的：

优点：

• 可读性强

• 避免key冲突

• 方便管理

• 节省内存

  key是string类型，底层编码包含：int、embstr和raw三种。

  在小于44字节时，是embstr编码，采用连续内存空间，内存占用更小（减少内存碎片）

  （可用通过object encoding xxx查看编码方式）

Big Key

内存占用

memory usage xxx

这个实际不推荐使用，占用cpu高，但是求出来的是精确值，包括数据结构加在一起的内存占用。

推荐使用估算方法：

• strlen xxx，查看这个元素值的字符串长度
• llen，查看集合元素数量

危害

• 网络阻塞

• 数据倾斜

• Redis阻塞

  对元素较多的hash、list、zset等做运算会耗时较长，使主线程阻塞

• CPU压力

恰当的数据类型

存储一个对象

方式一：json字符串

优点：实现简单粗暴

缺点：数据耦合，不够灵活（改一个字段的值，需要把整个json都修改掉）

方式二：字段打散

优点：可以灵活访问对象任意字段

缺点：

1. 占用空间大（每存一个键值对，都需要很多元数据，额外的内存占用）
2. 没法做统一控制

方式三：hash 👍

优点：底层使用zipList,空间占用小，可以灵活访问对象的任意字段

缺点：代码相对复杂（不过只要有工具类就也好实现）

存取大量键值对

如，存 100 万对field和value，field是自增的id

hash的entry数量超过500时，会使用哈希表而不是ZipList/listpack，内存占用较多。

可以分组打包，每 500 个一组