Redis 常见面试题（二）

过期机制

过期key定位

Redis在设置一个带有过期时间的key时，会将该key带上过期时间存储到Hash中，当查询该key时，会去这个Hash中检查是否过期。

删除策略

定期删除

Redis会开启一个定时任务，定期去扫描Hash，删除其中过期的Key，扫描机制是：
在Redis2.6版本中，
规定每秒运行10次，大概100ms运行一次。

1. 随机测试100个设置了过期时间的key
2. 删除所有发现的已过期的key
3. 若删除的key超过25个则重复步骤1
   在Redis2.8版本后，可以通过修改配置文件redis.conf 的 hz 选项来调整这个次数

惰性删除

所有key的读写操作执行之前都会调用 expireIfNeeded 函数对其进行检查，如果过期，则删除该键，返回key不存在；未过期继续执行原有的命令。

内存淘汰策略

通过设置maxmemory-policy，有几种淘汰策略：

1. volatile-lru：最近最少使用设置过期时间的key
2. allkeys-lru：最近最少使用所有的key（常用）
3. volatile-random：随机删除设置过期时间的key
4. allkeys-random：随机删除所有的key
5. volatile-ttl：删除即将过期的key
6. noeviction：不删除key，返回错误（默认选项，一般不使用这个）

Slave如何同步Master数据

Redis主从架构中，一般都是master用于写操作，若干个slave用于读操作

Slave启动时全量同步

1. Slave刚启动时向Master发送SYNC指令
2. Master此时会开启一个备份进行执行RDB备份操作，如果已有进程执行RDB操作则忽略
3. 该备份进程会将当期全部数据保存为.rdb
4. 备份完成后会将.rdb文件发送给Slave

Slave正常运行时增量同步

1. Master在接收用户写操作时会先判断当前操作是否需要写入到Slave中
2. 如果需要写入则调用propagate()，该操作将这条记录写入到AOF文件中，同时调用replicationFeedSlaves()将记录扩散到Slave
3. replicationFeedSlaves()主要通过将数据写入到Slave的socket缓存区

RDB和AOF

1. RDB与AOF同时开启 默认先加载AOF的配置文件
2. 相同数据集，AOF文件要远大于RDB文件，恢复速度慢于RDB
3. AOF运行效率慢于RDB,但是同步策略效率好

建议方案：
4. RDB只做备份用途，并且只在Slave上持久化RDB，15分钟备份一次
5. 如果开启AOF，最坏情况下也只会丢失不超过2s的数据，但是AOF的IO比较高
6. 如果不开启AOF，仅靠主从复制也可以，省掉大量的IO，但是代价是如果Master和Slave都挂掉会丢失十几分钟的数据，启动脚本也需要对比Master和Slave中较新的RDB文件（新浪微博选择）

集群原理

Redis在3.0版本之后推出了集群的版本，即可以支持多个Master节点，每个Master节点下可以再挂上多个Slave节点。这样整个集群就可以横向扩展了，通过增加Master节点即可。
一种叫做一致性哈希的算法（非Redis cluster运用 ，Memcache使用）：
每次key都会计算hash，然后顺时针寻找最近的节点作为存储，为了改进master热点的问题，使用虚拟节点改进，这样保证数据能够均匀分到各个实际的节点中。

Redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot，每个节点会持有一部分slot，slot让节点node的增加和删除非常简单，只需要移动slot即可，移动slot的成本非常低。
Redis cluster默认是不支持Slave节点读或者写的，跟我们主从架构的模式是不一样的。
Cluster节点之间采用Gossip协议进行通信，以此来交换节点的信息、Slot信息等

请求重定向

1. 客户端会向任意一个Redis实例发送命令，该实例会计算Key所在的slot在不在本地，如果在则处理，不在则返回Moved重定向指令，客户端根据Moved指令重定向到对应节点
2. 节点通过Gossip协议进行数据交换，得知slot在哪个节点上