## 大量key在同一时间过期，注意什么？ 如果过期时间过于集中，会导致Redis可能会出现短暂的卡顿现象。严重的话会出现缓存雪崩，一般需要在时间上加一个随机值， 使用过期时间分散一些。 ## Redis分布式锁的实现原理 setnx命令设置唯一的key，只有不存在时才返回成功，这就相当于争抢锁。再使用expire给锁加一个过期时间防止锁忘记释放，导致死锁情况。 不过setnx和expire是两个命令，可以使用set命令，将两个操作合成一个原子操作 ## 使用keys扫出指定模式key列表会有什么问题 由于Redis是单线程，keys指令在运行时会导致线程阻塞一段时间，线上服务会停顿 可以使用scan无阻塞地提取，但会有一定的重复概率，需要在客户端做一次去重，所花时间比keys要长。 ## 如何使用Redis做异步队列？ 一般使用list结构，rpush生产消息，lpop消费消息。无消息时，适应sleep()重试或使用blpop阻塞直到有消息到来。 ## 怎么持久化 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算法思路