### 一、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
```
key： PRO:USER:LOGINNAME:373166324
value：12kd-dsj5ce-d4445-h4sd472
```

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

有一个传统公式做一个快速容量预估参考：
```
（key的长度 + value的长度）X 数量 X 1.2
```
以上是一种快速计算的公式，如果想根据redis数据结构来作精确计算，可以参考下述的帖子，针对每种数据结构，结构中的变量及类型，精确算出某种结构的缓存大小，如String类型：
```
1个dictEntry结构，24字节，负责保存具体的键值对; 向上取整为32；

1个redisObject结构，16字节，用作val对象; 向上取整为16；

1个SDS结构，(key长度 + 9)字节，用作key字符串; 向上取整16/32/64/...

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次方取值，计算公式为：
```
( 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`

如果上面的公式不好理解，还可以这样计算：
```
string类型的内存大小 = 键值个数*（dictEntry大小 + redisObject大小 + 包含key的sds大小 + 包含value的sds大小）+ bucket个数*8
```

已有0条评论

添加新评论☺

如果认为本文对您有所帮助请赞助本站

支付宝扫一扫赞助

已有0条评论

添加新评论☺