1. Redis数据过期淘汰策略
Redis 中数据过期策略采用定期删除+惰性删除策略。
定期删除策略：Redis 启用一个定时器定时监视所有的 key，判断key是否过期，过期的话就删除。这种策略可以保证过期的 key 最终都会被删除，但是也存在严重的缺点：每次都遍历内存中所有的数据，非常消耗 CPU 资源，并且当 key 已过期，但是定时器还处于未唤起状态，这段时间内 key 仍然可以用。
惰性删除策略：在获取 key 时，先判断 key 是否过期，如果过期则删除。这种方式存在一个缺点：如果这个 key 一直未被使用，那么它一直在内存中，其实它已经过期了，会浪费大量的空间。
2、定期删除+惰性删除策略是如何工作的？
这两种策略天然的互补，结合起来之后，定时删除策略就发生了一些改变，不在是每次扫描全部的 key 了，而是随机抽取一部分 key 进行检查，这样就降低了对 CPU 资源的损耗，惰性删除策略互补了为检查到的key，基本上满足了所有要求。但是有时候就是那么的巧，既没有被定时器抽取到，又没有被使用，这些数据又如何从内存中消失？没关系，还有内存淘汰机制，当内存不够用时，内存淘汰机制就会上场。Redis 内存淘汰机制有以下几种策略：
noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。（Redis 默认策略）
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 Key。（推荐使用）
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 Key。
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 Key。这种情况一般是把 Redis 既当缓存，又做持久化存储的时候才用。
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 Key。
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。
修改内存淘汰机制只需要在 redis.conf 配置文件中配置 maxmemory-policy 参数即可。
2. redis ttl与生存时间有什么关系
Redis对键提供生存时间，在不指定生存时间时，生存时间是永久。时间到期后Redis会自动删除这个键。可以用EXPIRE命令，时间单位时秒，如果一个键是被设为有限的生存时间，那么在SET key进行重新赋值的时候会被再次设为永久：
SET session:captcha sd2a
EXPIRE session:captcha 600！
3. redis有效期设置方式有几种
Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。
支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。
所以Redis也可以被看成是一个数据结构服务器。
4. 怎么查看redis数据的过期时间
通过EXPIRE 命令或者PEXPIRE 命令，客户端可以以秒或者毫秒精度为数据库中的某个键设置生存时间( Time To Live , TTL) ，在经过指定的秒数或者毫秒数之后，服务器就会自动删除生存时间为0的键:
redis> SET key value
OK
redis> EXP 工RE key 5
(integer) 1
redis> GET key // 5 秒之内
"value"
redis> GET key // 5 秒之后
(nil)
5. Redis过期时间
1.0.0版本后可用
时间复杂度： O(1)
给一个 key 设置超时时间。在一个超时时间结束后，这个键将会被自动删除。一个拥有关联过期时间的键在Redis术语里通常被认为 不稳定的 。
只有删除或者覆盖键的内容的命令，包括 DEL , SET , GETSET 和所有的 *STORE 命令，才会把过期时间清除。这意味着从理论上讲，所有改变键上存储的值而不是使用新的值来替换的操作，都将会保持过期时间不变。例如，使用 INCR 增加一个键的值，使用 LPUSH 讲一个新的值放到列表中，或者使用 HSET 改变一个哈希的字段的值都将会使过期时间保持不变。
使用 PERSIST 命令将一个键变成持久化的键，过期时间也会被清除。
如果一个键被 RENAME 重命名，关联的生存时间将会被转移到新的键名上。
如果一个键被 RENAME 重命名，就像在一个已经存在的键 Key_A ，它被一个调用 RENAME Key_B Key_A 所覆盖，原始的 Key_A 是否关联过期时间是没关系的，新的键 Key_A 将会继承 Key_B 的所有特征。
注意，使用负数调用 EXPIRE / PEXPIRE ，或者使用过去的时间调用 EXPIREAT / PEXPIREAT 将会使键被删除，而不是过期(相应的，弹出的 key event 将会是 del ，而不是 expired )。
可以使用一个已经有过期时间集的键作为参数来调用 EXPIRE 。在这种情况下，一个键的生存时间已经 更新 为一个新值。对此很多应用，下面的 Navigation session 模式一节记录了一个例子。
在Redis 2.1.3之前的版本中，使用一个命令改变一个拥有过期时间的键的值，效果跟彻底移除这个键一样。这种语义是必须的，因为复制层的限制现在已经确定了。
EXPIRE 将会返回0，并且不会使用一个过期时间集合来改变一个键的过期时间。
特别的 返回数字 ：
redis> SET mykey "Hello"
redis> EXPIRE mykey 10
redis> TTL mykey
redis> SET mykey "Hello World"
redis> TTL mykey
redis>
想象你有一个网页服务，并且你对用户最近访问的N个页面有兴趣，这样每个临近的页面视图的执行时间不会超过前一个页面视图执行的60秒。理论上来讲，你可以认为用户访问的页面集合为 Navigation session ，其中就可以包含用户在寻找哪些他或她感兴趣的产品信息，因此你可以推荐关联的产品。
你可以非常容易的使用下面的策略在Redis中建模这种类型：每次用户访问一个页面你就调用下面的命令：
如果用户闲置超过60秒，这个键将会被删除，只有访问时间差值小于60秒的页面才会被记录。
这个模式可以很容易的修改为使用 INCR 做计数器来替代使用 RPUSH 的列表。
通常情况下创建Redis的键时不关联生存时间。这个键将会简单的一直生存，除非用户显示的删除它，例如使用 DEL 命令。
EXPIRE 家族命令能够把一个过期时间关联到一个给定的键，代价是这个键会使用额外的内存。当一个键设置了过期时间，Redis将会确保当指定的时间过去之后移除这个键。
一个键的生存时间可以被 EXPIRE 命令更新，或者被 PERSIST 命令完全移除(或其他严格相关的命令)。
在Redis2.4版本中，过期时间可能不是非常精确的，并且它可能是在0到1秒之间的出入。从Redis2.6版本开始，过期时间误差是从0到1毫秒。
键的过期信息以绝对的Unix时间戳形式保存(Redis2.6以及更新的版本毫秒内)。这意味着甚至当Redis实例未启动时时间就流走了。
为了过期时间能工作的很好，计算机时间必须保持稳定。如果你从两个时钟巨大不同步的计算机上移动一个RDB文件，有趣的事情将会发生(像所有的键在加载时变成过期)。
实际上运行中的实例将一直会检查计算机的时钟，举例来说，如果你给一个键设置1000秒的生存时间，然后在未来将你的计算机设置在2000秒以后，这个键将会立即失效，而不是持续1000秒。
Redis键将会通过两种方式过期：一个被动的方式，和一个主动的方式。
一个键的被动过期是很简单的，当一些客户端尝试访问它，然后这个键被发现超时了。
当然，这是不够的，因为有一些键将永远不会被再次访问。这些键无论如何都应该被过期。所以，Redis会定期的在过期的集合中随机范围内测试少量的键。所有的已过期的键将会被从键空间被删除。
这就是Redis会在每秒做10次的事情：
这是一个小概率的算法，基本的设想是我们的样本代表整个键空间，然后我们继续失效直到将要失效的键百分比小于25%。
这意味着在任何一个时刻，正在使用内存的已经过期的最大数量的键等于每秒最大写操作数量除以4.
为了获得正确的行为而不牺牲一致性，当一个键失效， DEL 操作会同时在AOF文件和附属的副节点执行。这种方式失效进程是在主实例集中的，也不会出现一致性错误。
然而，当副本已经连接到主节点后将不会独立的失效键(但将会等待来自主节点的 DEL )，他们仍将会获取数据集中的全部过期状态，所以当一个副本被选举为主节点后，它将能够独立的失效这些键，完全像一个主节点。
6. 三分钟读懂redis数据库
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
1. 使用Redis有哪些好处？
(1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
(2) 支持丰富数据类型，支持string，list，set，sorted set，hash
(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
(4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
2. redis相比memcached有哪些优势？
(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型
(2) redis的速度比memcached快很多
(3) redis可以持久化其数据
3. redis常见性能问题和解决方案：
(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件
(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库
(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3...
这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。
4. MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据
相关知识：redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略：
voltile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据
相关推荐：《Python视频教程》
5. Memcache与Redis的区别都有哪些？
1)、存储方式
Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。
Redis有部份存在硬盘上，这样能保证数据的持久性。
2)、数据支持类型
Memcache对数据类型支持相对简单。
Redis有复杂的数据类型。
3），value大小
redis最大可以达到1GB，而memcache只有1MB
6. Redis 常见的性能问题都有哪些？如何解决？
1).Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。
2).Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3).Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
4). Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内
7. redis 最适合的场景
Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢?
如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：
1.Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
2.Redis支持数据的备份，即master-slave模式的数据备份。
3.Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
（1）会话缓存（Session Cache）
最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？
幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
（2）全页缓存（FPC）
除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。
再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。
此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
（3）队列
Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。
如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。
（4）排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：
当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。
（5）发布/订阅
最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！（不，这是真的，你可以去核实）。
7. java设置 redis 失效时间多久
EXPIRE命令返回1表示成功，返回0表示键值不存在或设置失败。
同时这里还有一个比较常用的命令是ttl，用于查看一个键还有多久时间会被删除。返回的是剩余时间（秒数）。
这里就不贴代码了，有一点需要说明的是，ttl命令在键不存在或被删除之后，会返回-2，在没有为键设置生存时间（即永久存在，建一个键之后的默认情况）时返回的是-1。大家可以亲自操作一把。
如果想要把一个设置过过期时间的键取消过期时间设置，则需要使用persist命令。
redis > SET session:27e7a id1234
OK
redis > EXPIRE session:27e7a 1200
(integer) 1
redis > TTL session:27e7a
(integer) 1092
redis > PERSIST session:27e7a
(integer) 1
redis > TTL session:27e7a
(integer) -1
这里需要说明一点的是，除了使用persist命令外，使用set、getset命令为键赋值，也会同时消除键的生存时间，如果需要可以重新使用expire命令为键设置生存时间。而其他对键的操作命令（如incr、lpush、hset、zrem）都不会影响键的生存时间。
expire命令的单位是秒，而且这个参数必须为整数，如果需要更精准的时间的话，需要使用pexpire命令设置，其单位为毫秒，同理也需要用pttl命令来看键的剩余毫秒数。当然使用expire命令设置的过期时间也是可以用pttl看键的剩余毫秒数的。
访问限制
有时候我们会有一个需求是需要限制一个用户对一个资源的访问频率，我们假定一个用户（用IP作为判断）每分钟对一个资源访问次数不能超过10次。
我们可以使用一个键，每次用户访问则把值加1，当值加到10的时候，我们设定键的过期时间为60秒，并且禁止访问。这时候下次访问发现值为10，则不让访问了，然后60秒后键被删除，这时候再次创建键。这样就可以解决，但是其实这样时间并不精准，问题还是挺大的。
我们还有一个方案：使用队列。前面的章节也说到了，使用列表类型可以用作队列。
我们设定一个队列rate.limiting.192.168.1.1（假定是这个IP），我们把每次的访问时间都添加到队列中，当队列长度达到10以后，判断当前时间与队列第一个值的时间差是否小于60，如果小于60则说明60秒内访问次数超过10次，不允许访问；否则说明可以访问，则把队列头的值删除，队列尾增加当前访问时间。
这种方法可以比较精准的实现访问限制，但是当限制的次数比较大时，这种方法占用的存储空间也会比较大。
缓存
有时候会把一些对CPU或IO资源消耗比较大的操作结果缓存起来，并设置一定时间的自动过期。比如我们设定一个微博外链的最热站点缓存放于新浪微博的首页，这样我们不可能每次访问都重新计算最热的外链站点，所以我们可以设定两小时更新一次。每次访问是判断这个键有没有，如果存在则直接返回，如果没有则通过计算把内容存入键中，并设定两小时的过期时间。
然而在很多场合这种方法会很恐怖，当服务器内存有限的时候，大量使用缓存切设置生存时间过长就会导致redis占用太多内存，而redis有时候会把系统内存都吃掉，导致系统崩溃。但是设置时间过短又会导致缓存的命中太低。
所以我们最好的办法是设定缓存的淘汰规则。这种方式比较适用于将redis用作缓存系统的时候比较好。
具体就是：修改配置文件中的maxmemory参数，限制redis的最大内存，当超出后会按照maxmemory-policy参数指定的策略删除不需要的键，直到redis占用的内存小于设定值。
8. 如何查询redis的缓存文件路径
1、首先找到redis的安装目录，如下图测试环境目录，进入到/opt/install/redis-2.8.19/src，如下图所示。
9. redis ttl过期会 自动删除吗
在Redis中，内存的大小是有限的，所以为了防止内存饱和，需要实现某种键淘汰策略。主要有两种方法，一种是当Redis内存不足时所采用的内存释放策略。
另一种是对过期键进行删除的策略，也可以在某种程度上释放内存。