一、Redis的key命名规范

  1. 建议全部大写，不强制

  2. key不能太长也不能太短，太短可读性太差，键名越长越占资源（毕竟内存很贵 按需申请）

  3. key 单词与单词之间以分号:号分割，例如：manager:info:user，因为这种在新的Redis客户端工具中都被自动分组，而使用_下划线分割的传统方式则无效。

  4. redis使用的时候注意命名空间，一个项目一个命名空间，项目内业务不同命名空间也不同。

一般情况下：

1) 第一段放置业务标识名或其缩写 如manager

2) 第二段放信息标识 如, info/benefit/order

3) 第三段放置用于区分区key的字段，如userId、priductId、activityId

例如，常见的设置登录token

  1. key： PRO:USER:LOGINNAME:373166324
  2. value：12kd-dsj5ce-d4445-h4sd472

二、Redis容量预估计算（扩容、申请）

新业务场景需要使用redis时，一般会需要申请redis资源，如2G/4G/8G…申请redis容量，跟业务有关，如用户数、用户资产数、商品数量、活动数量，此外对于每一个缓存item，其缓存的key和value的长度也会影响，二者是乘积的关系；

有一个传统公式做一个快速容量预估参考：

  1. （key的长度 + value的长度）X 数量 X 1.2

以上是一种快速计算的公式，如果想根据redis数据结构来作精确计算，可以参考下述的帖子，针对每种数据结构，结构中的变量及类型，精确算出某种结构的缓存大小，如String类型：

  1. 1个dictEntry结构，24字节，负责保存具体的键值对; 向上取整为32；
  3. 1个redisObject结构，16字节，用作val对象; 向上取整为16；
  5. 1个SDS结构，(key长度 + 9)字节，用作key字符串; 向上取整16/32/64/...
  7. 1个SDS结构，(val长度 + 9)字节，用作val字符串;向上取整16/32/64/...

当key个数逐渐增多，redis还会以rehash的方式扩展哈希表节点数组，即增大哈希表的bucket个数，每个bucket元素都是个指针(dictEntry*)，占8字节，bucket个数是超过key个数向上求整的2的n次方，如2000个key，1024<2000<2048，因此bucket个数为2048；

加上向上2的n次方取值，计算公式为：

  1. ( 32 + 16 + (keyLength+9)取整 + (valLength+9)取整 )*数量 + (数量)向上取整*8(指针大小)；

如：key长度为 13（13+9->32），value长度为15（15+9->32），key个数为2000（2000->2048）

根据上面总结的容量评估模型，容量预估值为2000 ×(32 + 16 + 32 + 32) + 2048×8 = 240384 B

如果上面的公式不好理解，还可以这样计算：

  1. string类型的内存大小 = 键值个数*（dictEntry大小 + redisObject大小 + 包含key的sds大小 + 包含value的sds大小）+ bucket个数*8