Redis--键值设计

Redis的key最好遵循如下规则设计：

　　1.遵循基本格式 ：业务名称：数据名：ID

　　2.长度不超过44个字节

　　3.不包含特殊字符

　　优点：

　　　　1.可读性强

　　　　2.避免key冲突

　　　　3.方便管理

　　　　4.更节省内存：key是string类型，底层编码是int，embstr，raw三种，embstr在小于44个字节长度使用，采用连续内存空间，内存占用更小

 

BigKey问题：

　　如何发现BigKey？

　　　　redis-cli --bigkeys

　　　　　　利用redis-cli提供的--bigkeys参数，可以便利分析所有的key，并返回key的整体信息，与每个数据的Top1的key

　　　　scan扫描

　　　　　　通过scan 游标，去扫描一部分key，不会占用redis的主线程

127.0.0.1:6379> scan 0
1) "13"
2)  1) "k2"
    2) "k1"
    3) "k4"
    4) "float_key"
    5) "ids"
    6) "k3"
    7) "inkey"
    8) "int_key"
    9) "stus"
   10) "k5"
   11) "13234339480"
   12) "sort_list"
127.0.0.1:6379> scan 13
1) "0"
2) 1) "string_key"
   2) "test_list"
   3) "13234339444"

　　　　利用第三方工具，分析RDB快照文件，全面分析内存使用情况

　　如何删除BigKey？

　　　　BigKey内存占用较多，即便删除这样的key，也会耗费大量时间，导致redis主线程阻塞

　　　　3.0以下版本

　　　　如果是集合类型，则便利big'key元素，先逐个删除子元素，最后删除bigkey

　　　　4.0以后

　　　　提供异步删除命令：unlink

恰当的数据结构

　　案例1:比如存储一个user对象，

　　　　方式一：json字符串

　　　　　　优点：实现简单粗暴

　　　　　　缺点：数据耦合，不够灵活

　　　　方式二：对象打散

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

　　　　　　缺点：占用空间大

　　　　方式三：hash

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

　　　　　　缺点：代码相对复杂

　　案例2：假设有hash类型的key，其中100万对的filed和value，filed是自增id，这个key存在什么问题？如何优化？

　　　　存在的问题：

　　　　　　hash的entry数量超过521，就是用hash表而不是ziplist，内存占用较多

　　　　　　可以通过config get hash-max-ziplist-entries，查看该信息，然后配置该上限值，但是如果entry过多，会导致bigkey问题。