redis 和 memcached 什么区别？为什么高并发下有时单线程的 redis 比多线程的 memcached 效率要高？
区别：
1.mc 可缓存图片和视频。rd 支持除 k/v 更多的数据结构;
2.rd 可以使用虚拟内存，rd 可持久化和 aof 灾难恢复，rd 通过主从支持数据备份;
3.rd 可以做消息队列。
原因：mc 多线程模型引入了缓存一致性和锁，加锁带来了性能损耗。
redis 主从复制如何实现的？redis 的集群模式如何实现？redis 的 key 是如何寻址的？
主从复制实现：主节点将自己内存中的数据做一份快照，将快照发给从节点，从节点将数
据恢复到内存中。之后再每次增加新数据的时候，主节点以类似于 mysql 的二进制日志方
式将语句发送给从节点，从节点拿到主节点发送过来的语句进行重放。
分片方式：
-客户端分片
-基于代理的分片
● Twemproxy
● codis-路由查询分片
● Redis-cluster（本身提供了自动将数据分散到 Redis Cluster 不同节点的能力，整个数据集
合的某个数据子集存储在哪个节点对于用户来说是透明的）
redis-cluster 分片原理：Cluster 中有一个 16384 长度的槽(虚拟槽)，编号分别为 0-16383。
每个 Master 节点都会负责一部分的槽，当有某个 key 被映射到某个 Master 负责的槽，那
么这个 Master 负责为这个 key 提供服务，至于哪个 Master 节点负责哪个槽，可以由用户
指定，也可以在初始化的时候自动生成，只有 Master 才拥有槽的所有权。Master 节点维
护着一个 16384/8 字节的位序列，Master 节点用 bit 来标识对于某个槽自己是否拥有。比
如对于编号为 1 的槽，Master 只要判断序列的第二位（索引从 0 开始）是不是为 1 即可。
这种结构很容易添加或者删除节点。比如如果我想新添加个节点 D, 我需要从节点 A、B、
C 中得部分槽到 D 上。
使用 redis 如何设计分布式锁？说一下实现思路？使用 zk 可以吗？如何实现？这两种有什
么区别？
redis:
1.线程 A setnx(上锁的对象,超时时的时间戳 t1)，如果返回 true，获得锁。
2.线程 B 用 get 获取 t1,与当前时间戳比较,判断是是否超时,没超时 false,若超时执行第 3 步;
3.计算新的超时时间 t2,使用 getset 命令返回 t3(该值可能其他线程已经修改过),如果
t1==t3，获得锁，如果 t1!=t3 说明锁被其他线程获取了。
4.获取锁后，处理完业务逻辑，再去判断锁是否超时，如果没超时删除锁，如果已超时，
不用处理（防止删除其他线程的锁）。
zk:
1.客户端对某个方法加锁时，在 zk 上的与该方法对应的指定节点的目录下，生成一个唯一
的瞬时有序节点 node1;
2.客户端获取该路径下所有已经创建的子节点，如果发现自己创建的 node1 的序号是最小
的，就认为这个客户端获得了锁。
3.如果发现 node1 不是最小的，则监听比自己创建节点序号小的最大的节点，进入等待。
4.获取锁后，处理完逻辑，删除自己创建的 node1 即可。
区别:zk 性能差一些，开销大，实现简单。
知道 redis 的持久化吗？底层如何实现的？有什么优点缺点？
RDB(Redis DataBase:在不同的时间点将 redis 的数据生成的快照同步到磁盘等介质上):内存到硬盘的快照，定期更新。缺点：耗时，耗性能(fork+io 操作)，易丢失数据。
AOF(Append Only File：将 redis 所执行过的所有指令都记录下来，在下次 redis 重启时，只需要执行指令就可以了):写日志。缺点：体积大，恢复速度慢。
bgsave 做镜像全量持久化，aof 做增量持久化。因为 bgsave 会消耗比较长的时间，不够实
时，在停机的时候会导致大量的数据丢失，需要 aof 来配合，在 redis 实例重启时，优先使
用 aof 来恢复内存的状态，如果没有 aof 日志，就会使用 rdb 文件来恢复。Redis 会定期做
aof 重写，压缩 aof 文件日志大小。Redis4.0 之后有了混合持久化的功能，将 bgsave 的全量
和 aof 的增量做了融合处理，这样既保证了恢复的效率又兼顾了数据的安全性。bgsave 的
原理，fork 和 cow, fork 是指 redis 通过创建子进程来进行 bgsave 操作，cow 指的是 copy on
write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据
会逐渐和子进程分离开来。
redis 过期策略都有哪些？LRU 算法知道吗？写一下 java 代码实现？
过期策略:
定时过期(一 key 一定时器)，惰性过期：只有使用 key 时才判断 key 是否已过期，过期则清
除。定期过期：前两者折中。
LRU:new LinkedHashMap<K, V>(capacity, DEFAULT_LOAD_FACTORY, true);
//第三个参数置为 true，代表 linkedlist 按访问顺序排序，可作为 LRU 缓存；设为 false 代表
按插入顺序排序，可作为 FIFO 缓存LRU 算法实现：
1.通过双向链表来实现，新数据插入到链表头部；
2.每当缓存命中（即缓存数据被访问），则将数据移到链表头部；
3.当链表满的时候，将链表尾部的数据丢弃。
LinkedHashMap：HashMap 和双向链表合二为一即是 LinkedHashMap。HashMap 是无序
的，LinkedHashMap 通过维护一个额外的双向链表保证了迭代顺序。该迭代顺序可以是插
入顺序（默认），也可以是访问顺序。
缓存穿透、缓存击穿、缓存雪崩解决方案？
缓存穿透：指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将
导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。
解决方案：
1.查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短；
2.布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据
会被这个 bitmap 拦截掉，从而避免了对 DB 的查询。
缓存击穿：对于设置了过期时间的 key，缓存在某个时间点过期的时候，恰好这时间点对
这个 Key 有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并
回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。
解决方案：
1.使用互斥锁：当缓存失效时，不立即去 load db，先使用如 Redis 的 setnx 去设
置一个互斥锁，当操作成功返回时再进行 load db 的操作并回设缓存，否则重试 get 缓存的
方法。
2.永远不过期：物理不过期，但逻辑过期（后台异步线程去刷新）。
缓存雪崩：设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部
转发到 DB，DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多 key，击穿是某一个
key 缓存。
解决方案：将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，
比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效
的事件。
