Redis面试题（一）



Redis面试题（一）

1. MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据?

相关知识：Redis六种淘汰机制

Redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略： 
volatile-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（驱逐）：禁止驱逐数据

第一种

redis sortSet里 放两天内(为方便取一天内活跃用户)登录过的用户，登录一次ZADD一次，如set已存在则覆盖其分数（登录时间）。键：login:users，值：分数 时间戳、value userid。设置一个周期任务，比如每天03:00:00点删除sort set中前一天3点前的数据（保证set不无序增长、留近一天内活跃用户）。取时，拿到当前时间戳（int 10位），再减1天就可按分数范围取过去24h活跃用户。

第二种：

限定 Redis 占用的内存，Redis 会根据自身数据淘汰策略，加载热数据到内存。
所以，计算一下 20W 数据大约占用的内存，然后设置一下 Redis 内存限制即可。

2.Redis常见性能问题和解决办法？

1.主线程（master）写内存快照，save命令调度rdbSave函数，此时会阻塞主线程的工作，当快照比较大
的时候对性能影响非常严重，会出现间断性暂停服务。
解决方法：主线程不做任何的持久化工作包括RDB和AOF操作，尤其是不能使用内存快照做持久化
2. 主线程（master）做AOF持久化操作，如果不重写AOF文件这个持久化方式对性能的影响是最小的，有时AOF文件过大会影响主线程重启的恢复速度。
解决方法：如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒钟同步一次。
3. 主线程调用bgrewriteaof 重写AOF文件，AOF在重写的时候会栈大量的cpu和内存的资源，导致服务
load过高，出现短暂服务暂停现象。
解决方法：为了主从复制的速度和链接稳定性，Slave和Master最好在同一个局域网中。
4. Redis主从复制的性能问题，第一次Slave向Master同步的实现是：Slave向Master发出同步请求，
Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，
初次同步完成。第二次以及以后的同步实现是：Master将变量的快照直接实时依次发送给各个Slave。
不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久
化基础上，只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞，但由于磁盘io的限制，
如果Master快照文件比较大，那么dump会耗费比较长的时间，这个过程中Master可能无法响应请求，也就
是说服务会中断，对于关键服务，这个后果也是很可怕的。
解决方法：尽量避免在压力较大的主库上增加从库的
5.单点故障问题，由于目前Redis的主从复制还不够成熟，所以存在明显的单点故障问题，这个目前只能自
己做方案解决，如：主动复制，Proxy实现Slave对Master的替换等，这个也是Redis作者目前比较优先的
任务之一
解决办法：为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：
Master<--Slave1<--Slave2<--Slave3.......，这样的结构也方便解决单点故障问题，实现Slave
对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。