分析：这个问题其实相当重要，到底redis有没有用到家，这个问题就可以看出来。比如你的redis只能存储5G数据，课时你写了10G，那会删除5G的数据。怎么删的，则会个问题思考过吗？还有，你的数据已经设置了过期时间了，内存占有率还是比较高，有思考过吗？且看我来讲解：
redis是采用定期删除+惰性删除策略
为什么不用定时删除策略？：
定时删除，用一个定时器来负责监视key，当这个key过期就自动删除，虽然内存及时释放，但是十分消耗CPU资源，在大并发请求下CPU要尽可能的把时间都用在处理请求，而不是删除key，因此没有采用这一策略
定期删除+惰性删除是如何工作的呢？
定时删除，redis默认每100ms检查是否有过期的key，有过期的key则删除。需要说明的是redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查（如果每100ms，全部key进行检查，redis岂不是卡死了）。因此，如果只采用定期策略，会导致很多key到时间没有删除
也就是使用定时删除会导致删除不完全，于是惰性删除就登场了。
也就是说你在获取key的时候，redis会检查一下，这个key如果设置过期时间那么是否过期了？如果过期 此时就删除。
采用定期删除+惰性删除就没问题了呢？
不是的如果定期删除没有删除key，然后你也没有及时去请求这个key，也就是说惰性删除也没有生效。这样redis的内存会越来越高，那么就应该采用内存淘汰机制。
在redis.conf中有一行配置
# maxmemory-policy volatile-lru该配置就是配内存淘汰策略的(什么，你没配过？好好反省一下自己)
1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。
2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用，目前项目在用这种。
3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。应该也没人用吧，你不删最少使用Key,去随机删。
4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把redis既当缓存，又做持久化存储的时候才用。不推荐
5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。依然不推荐
6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。不推荐
ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。
Redis持久化原理及配置详解
Redis的强大功能很大程度上是由于其将所有数据都存储在内存中。为了使Redis在重启后仍能保证数据不丢失,需要将数据从内存中以某种形式持久化到硬盘中。Redis支持两种持久化方式,一种是RDB方式,一种是AOF方式。可以单独使用其中一种或两种结合使用。(持久化即将数据保存到磁盘,机器宕机或者重启数据不丢失,存储到内存中的数据会丢失)
Redis有两种持久化的方式：快照（RDB文件）和追加式文件（AOF文件）：
- RDB持久化方式会在一个特定的间隔保存那个时间点的一个数据快照。
- AOF持久化方式则会记录每一个服务器收到的写操作。在服务启动时，这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟Redis协议一致，以追加的方式进行保存。
- Redis的持久化是可以禁用的，就是说你可以让数据的生命周期只存在于服务器的运行时间里。
- 两种方式的持久化是可以同时存在的，但是当Redis重启时，AOF文件会被优先用于重建数据。
RDB概述：
RDB是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。
优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
缺点：RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候
RDB是Redis默认的持久化方式，所以RDB是默认开启的
redis.conf中的具体配置参数如下；