redis数据结构和定时策略

1. redis数据结构

类型	简介	特性	场景
String(字符串)	二进制安全	可以包含任何数据,比如jpg图片或者序列化的对象,一个键最大能存储512M	key,value
Hash(字典)	键值对集合,即编程语言中的Map类型	适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值(Memcached中需要取出整个字符串反序列化成对象修改完再序列化存回去)	存储对象
List(有序，重复列表)	链表(双向链表)	增删快,提供了操作某一段元素的API	1、最新消息排行等功能(比如朋友圈的时间线) 2、twitter的关注列表，粉丝列表
Set(无序，不重复集合)	哈希表实现,元素不重复	1、添加、删除、查找的复杂度都是O(1) 2、为集合提供了求交集、并集、差集等操作	1、共同好友 2、利用唯一性,统计访问网站的所有独立ip 3、好友推荐时,根据tag求交集,大于某个阈值就可以推荐4.粉丝列表
Sorted Set(有序集合)	将Set中的元素增加一个权重参数score,元素按score有序排列	数据插入集合时,已经进行天然排序	1、排行榜 2、带权重的消息队列

2.持久化方式

1.RDB
     在指定时间间隔内，将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存中，来达到恢复数据的
持久化过程：
Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写进一个临时文件中，等到持久化过程结束了，再用这个临时文件替换上次持久化好的文件。在这个过程中，只有子进程来负责IO操作，主进程仍然处理客户端的请求，这就确保了极高的性能

2.AOF
     以日志的形式记录Redis每一个写操作,将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件不可以改写文件，redis启动之后会读取appendonly.aof文件来实现重新恢复数据，完成恢复数据的工作。默认不开启，需要将redis.conf中的appendonly no改为yes启动Redis。

3.过期策略

定时删除
含义：
    在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除

优点：
   保证内存被尽快释放

缺点：
    若过期key很多，删除这些key会占用很多的CPU时间，在CPU时间紧张的情况下，CPU不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些key
定时器的创建耗时，若为每一个设置过期时间的key创建一个定时器（将会有大量的定时器产生），性能影响严重.

惰性删除
含义：
     key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。
优点：
      删除操作只发生在从数据库取出key的时候发生，而且只删除当前key，所以对CPU时间的占用是比较少的，而且此时的删除是已经到了非做不可的地步（如果此时还不删除的话，我们就会获取到了已经过期的key了）
缺点：
     若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露（无用的垃圾占用了大量的内存）

定期删除
含义：
     每隔一段时间执行一次删除(在redis.conf配置文件设置hz，1s刷新的频率)过期key操作
优点：
     通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用–处理"定时删除"的缺点
定期删除过期key–处理"惰性删除"的缺点
缺点
     在内存友好方面，不如"定时删除"
在CPU时间友好方面，不如"惰性删除"
难点
    合理设置删除操作的执行时长（每次删除执行多长时间）和执行频率（每隔多长时间做一次删除）（这个要根据服务器运行情况来定了）
看完上面三种策略后可以得出以下结论：

• 定时删除和定期删除为主动删除：Redis会定期主动淘汰一批已过去的key
• 惰性删除为被动删除：用到的时候才会去检验key是不是已过期，过期就删除
• 惰性删除为redis服务器内置策略

定期删除可以通过：
第一、配置redis.conf 的hz选项，默认为10 （即1秒执行10次，100ms一次，值越大说明刷新频率越快，最Redis性能损耗也越大）
第二、配置redis.conf的maxmemory最大值，当已用内存超过maxmemory限定时，就会触发主动清理策略

关注小编公众号（java交流):回复520，免费领取Java学习资料！