redis主从复制的核心原理
通过执行slaveof命令或设置slaveof选项，让一个服务器去复制另一个服务器的数据。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。
全量复制：
- 主节点通过bgsave命令fork子进程进行RDB持久化，该过程是非常消耗CPU、内存（页表复制）、硬盘IO的
- 主节点通过网络将RDB文件发送给从节点，对主节点的带宽都会带来很大的消耗
- 从节点清空老数据、载入新RDB文件的过程是阻塞的，无法响应客户端的命令；如果从节点执行bgrewriteaof，也会带来额外的消耗
部分复制：
- 复制偏移量：执行复制的双方，主从节点，分别会维护一个复制偏移量offset
- 复制积压缓冲区：主节点内部维护了一个固定长度的、先进先出FIFO队列作为复制积压缓冲区，当主从节点offset的差距过大超过缓冲区长度时，将无法执行部分复制，只能执行全量复制
- 服务器运行ID（runid）：每个Redis节点，都有其运行ID，运行ID由节点在启动时自动生成，主节点会将自己的运行ID发送给从节点，从节点会将主节点的运行ID保存起来。从节点Redis断开重连的时候，就是根据运行ID来判断同步的进度：
- 如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使用部门复制（到底能不能部分复制还是得看offset和复制积压缓冲区的情况）
- 如果从节点保存的runid和主节点的runid不同，说明从节点在断线前同步的Redis节点并不是当前的主节点，只能进行全量复制。
Redis有哪些数据结构？分别有哪些典型的应用场景？
- 字符串：可以用来做简单的数据，可以缓存某个简单的字符串，也可以缓存某个json格式的字符串，Redis分布式锁的实现就利用了这种数据结构，还包括可以实现计数器、Session共享、分布式ID
- 哈希表：可以用来存储一些key-value对，更合适存储对象
- 列表：Redis的列表通过命令的组合，既可以当作栈，也可以当作队列来使用，可以用来缓存类似于微信公众号、微博等消息流数据
- 集合：和列表相似，也可以存储多个元素，但是不能重复，集合可以进行交集、并集、差集操作，从而可以实现类似于我和某个人共同关注的人、朋友圈点赞等功能
- 有序集合：集合是无序的，有序结合是可以设置顺序的，可以用来实现排行榜功能
Redis分布式锁底层是如何实现的？
- 首先利用setnx来保证，如果key不存在才能获取到锁，如果key存在，则获取不到锁
- 然后还要利用lua脚本来保证多个redis操作的原子性
- 同时还要考虑到锁过期，所以需要额外的一个看门狗定时任务来监听锁是否需要续约
- 同时还要考虑到redis节点挂掉后的情况，所以需要采用红锁的方式来同时向N/2 + 1个节点申请锁，都申请到了才证明获取锁成功，这样就算其中的某个redis节点挂掉了，锁也不能被其他客户端获取到
Redis集群策略
- 主从模式：这种模式比较简单，主库可以读写，并且会和从库进行数据同步，这种模式下，客户端直接连接主库或某个从库，但是主库或者从库宕机后，客户端需要手动修改IP，另外，这种模式也比较难进行扩容，整个集群所能存储的数据受到某台机器的内存容器，所以不可能支持特大的数据量
- 哨兵模式：这种模式在主从的基础上新增了哨兵节点，但主库节点宕机后，哨兵会发现主库节点宕机，然后在从库中选择一个库作为新的主库，另外哨兵也可以做集群，从而可以保证某一个哨兵宕机后，还有其他哨兵节点可以继续工作，这种模式可以比较好的保证Redis集群的高可用，但是仍然不能很好的解决Redis的容量上限问题
- Cluster模式：Cluster模式是用的比较多的模式，它支持多主多从，这种模式会按照key进行槽位的分配，可以使得不同的key分散到不同的主节点上，利用这种模式可以使得整个集群支持更多的数据容量，同时每个主节点可以拥有自己的多个从节点，如果该主节点宕机，会从它的从节点中选举一个新的主节点
对于这三种模式，如果Redis要存的数据量不大，可以使用哨兵模式，如果Redis要存的数据量大，并且需要持续的扩容，那么选择Cluster模式。
缓存穿透、缓存击穿、缓存雪崩分别是什么？
缓存中存放的大多是热点数据，目的是防止请求直接访问数据库，而是先从缓存中获取数据。
- 缓存雪崩：如果换成中某一时刻大批热点数据同时过期，那么 那么就可能导致大量请求直接访问数据库，解决的方法就是在过期时间上加一点随机值，另外如果搭建一个高可用的Redis集群也是防止缓存雪崩的有效手段
- 缓存击穿：和缓存雪崩相似，缓存雪崩是大批热点数据失效，而缓存击穿是指某一个热点key突然失效，也导致了大量请求直接访问数据库，解决方法是考虑将这个热点key不设置过期时间
- 缓存穿透：加入某一时刻访问redis的大量key都在redis中不存在（比如黑客故意伪造一些乱七八糟的key），那么也会给数据库造成压力，这就是缓存穿透，解决方法就是使用布隆过滤器，它的作用就是如果它认为一个key不存在，那么这个key就肯定不存在，所以可以在缓存之前加一层布隆过滤器来拦截不存在的key
