一、memcached与redis的区别？

　　1.存储方式不同。memcached把数据全部存在内存之中，断电之后会挂掉，而redis虽然也用到了内存，但是会有部分数据存在硬盘中，保证数据持久性。

　　2.数据支持类型不同。memcached对数据支持比较简单，而redis支持数据类型较丰富，如string、list、set、sorted set、hash。

　　3.底层实现不同。一般调用系统函数，会消耗比较多的时间去请求，redis自己构建了vm，速度会更快。

二、redis数据的淘汰策略？

　　1.volatile-lru：从已经设置过期时间的数据集中，挑选最近最少使用的数据淘汰。

　　2.volatile-ttl：从已经设置过期时间的数据集中，挑选即将要过期的数据淘汰。

　　3.volatile-random：从已经设置过期时间的数据集中，随机挑选数据淘汰。

　　4.allkeys-lru：从所有的数据集中，挑选最近最少使用的数据淘汰。

　　5.allkeys-random：从所有的数据集中，随机挑选数据淘汰。

　　6。no-enviction：禁止淘汰数据。

三、为什么redis把所有数据都放到内存中？

　　redis为了达到最快的读写速度，将数据都读到内存中，并通过异步的方式将数据写入磁盘。如果不将数据放在内存中，磁盘IO速度会严重影响redis的性能。

四、redis的并发竞争问题如何解决？

　　首先redis为单进程单线程模式，采用队列模式将并发访问变为串行访问。redis本身时没有锁的概念的，redis对多个客户端连接并不存在竞争，但是在Jedis客户端对redis进行并发访问时会产生一系列问题，这些问题时由于客户端连接混乱造成的。有两种方案解决。

　　1.在客户端，对连接进行池化，同时对客户端读写redis操作采用内部锁synchronized。

　　2.在服务器角度，利用setnx实现锁。

五、redis过期键的删除策略？

　　1.定时删除：在设置键的过期时间的同时，创建一个timer，让定时器在键的过期时间到达时，立即执行对键的删除操作。（主动删除）

　　　　对内存友好，但是对cpu时间不友好，有较多过期键的而情况下，删除过期键会占用相当一部分cpu时间。

　　2.惰性删除：放任过期键不管，但是每次从键空间中获取键时，都检查取到的键是否过去，如果过期就删除，如果没过期就返回该键。（被动删除）

　　　　对cpu时间友好，程序只会在取出键的时候才会对键进行过期检查，这不会在删除其他无关过期键上花费任何cpu时间，但是如果一个键已经过期，而这个键又保留在数据库中，那么只要这个过期键不被删除，他所占用的内存就不会释放，对内存不友好。

　　3.定期删除：每隔一段时间就对数据库进行一次检查，删除里面的过期键。（主动删除）

　　　　采用对内存和cpu时间折中的方法，每个一段时间执行一次删除过期键操作，并通过限制操作执行的时长和频率来减少对cpu时间的影响。难点在于，选择一个好的策略来设置删除操作的时长和执行频率。

六、redis与一般db的同步过程？

　　有两种方式。

　　第一种，先去redis中判断数据是否存在，如果存在，则直接返回缓存好的数据，如果不存在，去db中读取数据，并把数据缓存一份到redis中。适用与数据里比较大，但是不经常更新的情况，如用户排行。

 

　　第二种，先去redis中判断数据是否存在，如果存在，则直接更新对应数据（这一步会记录下更新的key，并把更新后的数据返回给页面，如果不存在，先去数据库中更新内容，然后把数据保存一份到redis中。再往后，后台会进行一系列操作，把redis中更新的key读取出来，找到数据库中对应的数据，并更新数据库。这种方式是把redis当作数据库使用，适合大数据的频繁变动。但是对redis的依赖很大，要做好挂掉之后的数据备份。

 

七、简述redis的哨兵模式

　　哨兵是对redis进行实时的监控，主要有两个功能。

　　1.监测主数据库和从数据库是否正常运行。2.当主数据库出现故障的时候，可以自动将一个从数据库转换为主数据库，实现自动切换。

八、redis的哨兵的监控机制是怎样的？

　　哨兵监控也是有集群的，会有多个哨兵进行监控，当判断发生故障的哨兵达到一定数量的时候才进行修复。一个健壮的部署至少需要三个哨兵实例。

1. 每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 

2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

3. 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4. 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 

5. 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 

6. 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 

7. 若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除