Redis-Key命名规范

建议风格一致

key的书写风格保持一致，常见的变量风格有：

做到项目级别的风格统一; 个人建议采用小驼峰

一个项目一个命名空间，项目内业务不同命名空间也不同。

一般情况下：

结合起来 PRO:USER:UID:18 直接意思就是，xx项目下的xx表中xx字段对应的值

以上是单机模式，当在redis集群中使用相关业务时候，常常需要将部分业务散列到相同的slot中，这时hash tag的作用就显得非常重要； 做法是在key中添加{}前缀prefix

key空间分为16384个槽，有效地设置了16384个主节点的簇大小的上限（但建议的最大节点大小约为1000个节点）。集群中的每个主节点处理16384个散列槽的子集。

当没有正在进行的集群重新配置时（即散列插槽从一个节点移动到另一个节点），集群是稳定的。

当集群稳定时，单个节点将提供单个散列槽（但是，在网络分裂或故障的情况下，服务节点可以有一个或多个将替换它的从属，并且可以用于扩展读取过时数据的读取操作）。用于将键映射到散列槽的基本算法如下（读取此规则的散列标记异常的下一段）：

HASH_SLOT = CRC16(key) mod 16384

使用16个CRC16输出位中的14个（这就是为什么在上面的公式中存在模16384运算的原因）。

在实际测试中，CRC16在16384个插槽中均匀分配不同类型的key时表现非常出色。

计算用于实现散列标记的散列槽有一个例外。散列标记是一种确保在同一散列槽中分配多个key的方法。这用于在Redis集群中实现多键操作。为了实现散列标签，在某些条件下以稍微不同的方式计算key的散列槽。

如果key包含一个{...}模式仅是{and}之间的子串，以获得散列slot被散列。

但是，由于可能存在多次出现{or}，以下规则很好地指定了算法：

如果满足条件三，不是对key进行散列，而是仅对第一次出现{和第一次出现}之间的内容进行散列。

例如：

两个key{user1000}.following和{user1000}.followers将散列到相同的散列slot，因为只有在子串user1000会计算散列slot。
对于键foo{}{bar}，通常将整个键进行哈希处理，因为第一次出现{右侧是}，而中间没有字符。
对于键foo{{bar}}zap，子串{bar将被散列，因为它是第一次出现{和右边第一次出现}之间的子串。
对于keyfoo{bar}{zap}的子串bar将被散列，算法在第一个有效或无效（无内部字节）匹配{and}后停止匹配。

该算法的结果是，如果key开头{}，则保证整个散列。当使用二进制数据作为键名时，这很有用。

在项目中，redis属于高频使用，遇到了各种各样的redis问题，针对自身情况梳理了一个redis使用规范。

一般情况下：

结合起来 PRO:USER:UID:18 就很清晰

拒绝大key操作，禁用超过10K的string大key(虽然redis支持512MB大小的string)，如果1mb的key每秒重复写入10次，就会导致写入网络IO达10MB。
设计key时使用合适的数据类型(在资源利用和性能之间作平衡)。例如：将一个普通字符串弄成hash类型进行存储这是不合理的
控制key的生命周期，例如：key设置为永不过期是不合理的，也不建议过期时间全部一样，避免key大面积失效，mysql被打满
控制value长度。例如string类型，如果value为'8个字节的长整型'则内部使用int类型，如果value为'小于等于39个字节的字符串'则内部使用embstr类型，如果value为'大于39个字节的字符串'则内部使用raw类型。这样能很好的利用redis的性能。