大量key在同一时间过期，注意什么？
如果过期时间过于集中，会导致Redis可能会出现短暂的卡顿现象。严重的话会出现缓存雪崩，一般需要在时间上加一个随机值，
使用过期时间分散一些。
Redis分布式锁的实现原理
setnx命令设置唯一的key，只有不存在时才返回成功，这就相当于争抢锁。再使用expire给锁加一个过期时间防止锁忘记释放，导致死锁情况。
不过setnx和expire是两个命令，可以使用set命令，将两个操作合成一个原子操作
使用keys扫出指定模式key列表会有什么问题
由于Redis是单线程，keys指令在运行时会导致线程阻塞一段时间，线上服务会停顿
可以使用scan无阻塞地提取，但会有一定的重复概率，需要在客户端做一次去重，所花时间比keys要长。
增量式迭代命令
如何使用Redis做异步队列？
一般使用list结构，rpush生产消息，lpop消费消息。无消息时，适应sleep()重试或使用blpop阻塞直到有消息到来
如何Redis实现延时队列
使用sortedset,拿时间戳作为score，消息内容作为key调用add来生间消息，消费者用zrangebyscore指令获取N次之前的数据轮询进行处理
怎么持久化
RDB:镜像全量持久化
AOF：增量持久化。
Redis雪崩、穿透 击穿
缓存同一时间大面积失效，导致大量的请求直接由db处理。就好像洪水一瞬点冲向小堤坝一样。
穿透是指请求了缓存和数据库中都没有的数据，而用户不断发起请求。一般认为是恶意攻击，永远不要相信用户的输入参数，做好校验。
缓存击穿和雪崩有点像，是指某几个key非常热点，担承了大量的请求，当这几个key在失效的瞬点，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。
策略，
- 在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值。
- 如果是集群部署，将热点数据均匀分布在不同的Redis库也能避免。
- 或者热点数据永不过期，有更新操作就更新缓存就好了。
- Nginx配置项
- 布隆过滤器
- 热点数据永不过期
- 互斥锁
小总结
- 事前：Redis高可用，主从+哨兵，Redis Cluster，避免全盘崩溃
- 事中：本地ehcache缓存+Hystrix限流+降级，避免 MySQL被打死
- 事后： Redis持久化RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复数据。
Redis为啥快
- 完全基于内存
- 数据结构简单
- 采用单线程，避免不必要的上下文切换和竞争条件，
- 也不存在多进程或者是多线程导致的切换而消耗CPU，不用考虑各种锁的问题。
- 使用多路I/O复用模型，非阻塞IO
- 底层通过机制优化
单进程单线程瓶颈怎么解决
单机多核开多个Redis实例，集群、主从同步读写分离
持久化问题
持久化的话是Redis高可用中比较重要的一个环节，因为Redis数据在内存的特性，持久化必须得有，我了解到的持久化是有两种方式的。
- RDB：RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化。
- AOF：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog。
两种方式都可以把Redis内存中的数据持久化到磁盘上，然后再将这些数据备份到别的地方去，RDB更适合做冷备，AOF更适合做热备，比如我杭州的某电商公司有这两个数据，我备份一份到我杭州的节点，再备份一个到上海的，就算发生无法避免的自然灾害，也不会两个地方都一起挂吧，这灾备也就是异地容灾，地球毁灭他没办法
哨兵？
主要功能：
- 集群监控：负责监控Redis master 和slave进程是否正常工作
- 消息通知：如果某个Redis实现有故障，那么哨兵负责发送消息作为报警通知给管理员
- 故障转换：如果master node挂掉了，会自动转换到slave node上
- 配置中心：如果故障转移发生了，通知client客户端新的master地址。
主从之间数据怎么同步
启动slave时，会发送一个Pysnc命令给master,如果这个slave第一次连接到master，他会触发一个全量复制。master会避动一个线程，生成RDB快照，
还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave，slave拿到之后第一件事情就是写进本地磁盘，然后加载进内存，然后
master会把内存里面缓存的那些新命名都发给slave.
过期策略
- 定期删除，默认100ms就随机抽一些设置了过期时间的Key,检查是否过期，删除。
- 惰性删除，查询时时再检测是否过期，过期就删除还不给你返回
- 内存淘汰机制
对于定期没删除又没查询的，近似LRU算法思路