京东面试官：Redis 这些我必问

分布式缓存

高性能（常用）

高并发

缓存不良后果

1. 缓存与数据库双写不一致
2. 缓存雪崩
3. 缓存穿透
4. 缓存并发竞争

Redis 线程模型

Redis 和 Memcached 区别

1. Redis 支持服务器端的数据操作：Redis 比 Memcached 来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在 Memcached 里，你需要将数据拿到客户端来进行类似的修改再 set 回去。这大大增加了网络 IO 的次数和数据体积。在 Redis 中，这些复杂的操作通常和一般的 GET/SET 一样高效。所以，如果需要缓存能支持更复杂的结构和操作，那么 Redis 会是不错的选择
2. 集群模式：memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据，但是 Redis 目前是原生支持 cluster 模式的

Redis 单线程模型

1. redis 初始化时，会将连接应答处理器跟 AE_READABLE 事件关联
2. 客户端对 redis 发起连接，产生一个 AE_READABLE 事件
3. 连接应答处理器处理客户端 AE_READABLE 事件，创建客户端对应的 socket，同时将这个 socket 的 AE_READABLE 事件和命令请求处理器关联
4. 客户端对 redis 发起读请求，会在 socket 上产生一个 AE_READABLE 事件
5. 绑定 AE_READABLE 事件的命令请求处理器会从 socket 中读取请求相关数据，执行对应操作，当执行完毕后，将 socket 的 AE_WRITABLE 事件跟命令回复处理器关联
6. 当客户端这边准备好读取响应时，会在 socket 上产生一个 AE_WRITABLE 事件
7. 绑定 AE_WRITABLE 事件的命令回复处理器将准备好的响应数据写入 socket，供客户端来读取
8. 命令回复处理器写完后，删掉 socket 的 AE_WRITABLE 事件和命令回复处理器的绑定关系

Redis 单线程模型效率高

1. 非阻塞 I/O 多路复用机制（不处理事件，只轮询请求压入队列）
2. 纯内存操作（操作只有几微秒）
3. 单线程反而 避免了多线程频繁上下文切换的问题

Redis 数据类型

• string

• hash

"id":150,
"name":"zhangsan",
"age":20 复制代码

• list

• set

• sorted set

1. 将每个用户以及其对应的分数写入进去

1. zrevrange board 0 99 可以获取排名前 100 的用户
2. zrank board username 可以看到用户在排行榜里的排名

Redis 过期策略

1. noeviction:当内存不足以容纳新写入数据时，新写入操作直接报错（没人用）
2. allkeys-lru: 当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（最常用）
3. allkeys-random: 当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key，(没人用)
4. volatile-lru:当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key(不合适)
5. volatile-ttl:当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除(不合适)

package com.mousycoder.mycode;

import java.util.LinkedHashMap;
import java.util.Map;

/**
 * @version 1.0
 * @author: mousycoder
 * @date: 2019/10/31 17:55
 */
public class LRUCache<K,V> extends LinkedHashMap<K,V> {

    private final int CACHE_SIZE;

    public LRUCache( int cacheSize) {
        super((int)Math.ceil(cacheSize / 0.75) + 1 ,0.75f,true);
        this.CACHE_SIZE = cacheSize;
    }

    @Overrideprotected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > CACHE_SIZE;
    }

    public static void main(String[] args) {
        LRUCache<Integer,Integer> lruCache = new LRUCache<>(10);
        for (int i = 0; i < 15; i++) {
            lruCache.put(i,i);
        }

        Integer integer1 = lruCache.get(0);
        for (Integer integer : lruCache.keySet()) {
            System.out.println(integer);
        }

    }
} 

Redis 高并发和高可用

主从架构

Redis Replication

1. redis 采用异步方式复制数据到 slave 节点
2. 一个 master node 是可以配置多个 slave node 的
3. slave node 也可以连接其他的 slave node
4. slave node 做复制的时候，是不会 block master node 的正常工作
5. slave node 在做复制的时候，也不会 block 对自己的查询操作，它会用旧的数据集来提供服务。但是复制完成时，需要删除旧数据集，加载新的数据集，这个时候就会暂停对外服务了。
6. slave node 主要用来进行横向扩容，做读写分离，扩容 slave node 可以提高读的吞吐量

1. 当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node
2. master 会触发一次 full resynchronization （如果不是第一次连接，master 只会复制给 slave 部分缺少的数据，从 backlog 里找）
3. master 会启动一个后台线程，开始生成一份 RDB 快照（ bgsave,也可以直接在内存中创建），同时将从客户端收到的所有写命令缓存在内存中。RDB 文件生成完毕之后，master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后 master 会将内存中缓存的写命令发送给 slave,slave 也会同步这些数据（slave 如果跟 master 网络故障，断开连接，会自动重连，master 如果发现有多个 slave 来重新连接，仅仅只会启动一个 RDB save 操作，用一份数据服务所有 slave node）

Redis 高可用性

Sentinal

1. 集群监控，负责监控 redis master 和 slave 进程是否正常
2. 消息通知，如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员
3. 故障转移，如果 master 挂掉，会自动转移到 slave
4. 配置中心，如果故障转移了，通知 client 客户端新的 master 地址

两节点哨兵集群

三节点哨兵集群（经典）

Redis 主从 + 哨兵

1. master 内存中数据异步同步到 slave master 就挂掉了,丢掉了 master 内存中的数据

1. 脑裂，某个 master 所在机器突然脱离了正常的网络，其他 slave 机器不能连接，但是实际上 master 还在运行，哨兵认为 master 宕机，选举 slave 为 master，此时集群里有 2 个 master, client 还没来得及切换到新的 master，还继续写在旧的 master 上，数据丢了，此时旧的 master 再次恢复，被被作为一个 slave 挂到新的 master 上，自己的数据被清空 （脑裂，大脑一分为 2，同时指挥同一个人）

1. min-slaves-max-lag 10 （至少一个 slave 同步的延迟不能超过 10s） 减少异步复制的数据丢失，发现 slave 复制数据和 ack 延时过长，拒绝写入，减少同步数据损失。让 client 做降级写到本地磁盘里和限流，或者先暂存到消息队列，然后重新发回 master
2. min-slaves-to-write 1 减少脑裂带来的数据丢失，最多损失 10 s 数据，假设 master 不能继续给 slave 发送数据，并且 slave 10s 没给自己的 ack 消息，直接拒绝客户端写请求，同时 client 做降写到本地磁盘、限流，或者先暂存到消息队列，然后重新发回 master

哨兵

1. 如果 slave 跟 master 断开连接已经超过 down-after-milliseconds * 10 + master 宕机时间，则放弃
2. 按 slave 优先级排序 ，slave-priority 越小越靠前
3. replica offset ，哪个 slave 复制越多的数据，越靠前
4. runid 越小，越靠前

Redis 优化方案

Redis 持久化

• RDB 对 Redis 中的数据执行周期性的持久化。
• AOF 机制，每条写命令作为日志，以 append-only 模式写入一个日志文件总，在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集

RDB

• RDB 会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，RDB 做冷备，生成多个文件，每个文件都代表某一个时刻的完整的数据快照，AOF 也可以做冷备，只有一个文件，每隔一定时间去 copy 一份这个文件出来。 RDB 做冷备，由 Redis 控制固定时长去生成快照文件，比较方便。AOF，需要自己写脚本定时控制。
• RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能，因为 redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化
• 相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速

• 如果想要在 redis 故障时，尽可能少丢数据，那么 RDB 没有 AOF 好，一般 RDB 数据快照，都是间隔 5 分钟，或者更长的时候生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟数据
• RDB 每次在 fork 子进程来执行 RDB 快早数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，甚至数秒（RDB 生成间隔不要太长）

AOF

1. 更好保护数据不丢失，后台线程 fsync 操作，最多丢失一秒钟数据，保证 os cache 中的数据写入磁盘中
2. AOF 用 append-only 模式，没有磁盘寻址开销，写入性能非常高，文件不容易损坏。
3. AOF 日志过大的时候，后台 rewrite log 时候，老的日志文件照常写入，新的 merge 后的日志文件 ready 的时候，再交换新老日志文件
4. 适合灾难性恢复，某人不小心 flushall 清空所有数据，只要后台 rewrite 还没发生，那么可以立刻拷贝 AOF 文件，将最后一条 flushall 命令给删了，然后再将该 AOF 文件放回去，可以通过恢复机制，自动恢复所有数据

1. AOF 日志文件比 RDB 数据快照文件大
2. 降低 Redis 的写 QPS
3. AOF 复杂，Bug 多
4. 数据恢复比较慢

最佳方案

Redis Cluster

分布式算法

hash 算法

一致性 hash 算法

Hash Slot 算法

Redis Cluster 核心

1. 基础通信

1. 10000 端口

1. 交换的信息

1. gossip 协议

1. ping 消息

1. JRedis 原理

• 请求重定向

• hash slot

• smart jedis

• hashslot 迁移和 ask 重定向

• 高可用性和主备切换原理

缓存雪崩

1. 数据库绝对不会死，确保了每秒只会过去 2000 个请求
2. 只要数据库不死，对于用户来说 2/5 的请求可以被处理
3. 系统没死，用户多点几次可能就刷出来了

缓存穿透

缓存与数据库双写一致性

1. cache aside pattern

1. 修改数据库成功，删除缓存失败，导致数据库是新的数据，缓存中是旧的数据

1. 修改数据库还没修改完，同时又有查询请求，把旧的数据放到缓存中（高并发，每秒并发读几万，每秒只要有数据更新请求，就可能出现数据库+缓存不一致情况）

Redis 并发竞争问题

Redis 集群部署架构