redis很多人都用错了

一.规范命名：

1.1通过合理的命名

不同的业务使用不同的前缀（防止key冲突），用冒号隔开，比如业务名:表名:id

 uv:page:1024 

1.2 控制key的长度

key 本身是字符串，底层的数据结构是 SDS。SDS 结构中 会包含字符串长度、分配空间大小等元数据信息 ， 当 key 字符串 的长度增加时，SDS 中的元数据也会占用更多内存空间 。

尽量使用单词首字符或者缩写代替

1.3 不要包含特殊字符

比如：空格，换行，单双引号以及其他转义字符

二. value规范设计

2.1避免使用bigkey

有两种情况：

• 值为string,例如value为10M的string,只能在业务层，控制string类型的value大小在10K以下，还可以对vale进行压缩减少大小。
• 值为集合类型，尽量把集合元素个数控制在1w个以下，如果超过需要把大集合拆分成多个小集合；

List,Hash,Set,Sort Set 集合元素小于一定阀值，会才用压缩数据结构，达到节省内存效果，比如hash元素小于1000，就会使用zipList来保存，需要注意的时，使用压缩数据结构虽然节省了内存，但是会降低读写访问速度，所以不属于bigkey的前提下，如果业务更需要高性能，那就不用刻意去控制集合元素个数

2.2 使用高效序列化方式和压缩方法

• 使用protobuf，kryo序列化可以节省内存空间
• 使用xml和json序列化数据虽然可读性好，但是占用内存，可以使用gzip压缩数据达到节省内存目的

2.3 使用整数对象共享池

Redis 内部维护了 0 到 9999 这 1 万个整数对象，并把这些整数 作为一个共享池使用

两种情况不能使用：

• 如果 Redis 中设置了 maxmemory，而且启用了 LRU 策略（allkeys-lru 或 volatile-lru 策略），
• 如果集合类型数据采用 ziplist 编码，而集合元素是整数，这个时候，也不 能使用共享池。因为 ziplist 使用了紧凑型内存结构，判断整数对象的共享情况效率低。

三。数据保存规范

• redis更多的保存热数据
• redis保存的数据需要设置过期时间
• 不同的业务使用不同实例的redis,避免不同的业务相互影响
• 控制redis单个实例内存大小（2G-6G），避免生成RDB,主从复制阻塞主线程，影响正常请求处理

四。命令使用规范

• 使用重命令方式禁用命令：keys,flushall,flushdb;keys可以使用scan代理，flushall,flushdb加上async代替
• 慎用monitor命令
• 慎用全量操作命令， （例如 Hash 类型的 HGETALL、Set 类型的 SMEMBERS） ，大集合会阻塞主线程，影响正常请求。可以使用sscan,hscan分配返回集合；把大集合拆分成按（ 时间、地域、用户 ID 等属性）小集合，每次访问只会访问到小集合
• 使用批量操作：mget,mset，pipeline (非原子操作）