说说你对redis的理解2

高可用

1.主从复制

redis中的数据备份在多个服务器中，为了保障数据一致性，提供了主从复制的策略。主服务器进行读写操作，从服务器只读，并且接收主服务器的同步过来的写操作。

设置主服务器和从服务器

# 服务器 B 执行这条命令
replicaof <服务器 A 的 IP 地址> <服务器 A 的 Redis 端口号>

全量复制过程

• 建立连接，协同同步：从服务器向主服务请求 psync，进行数据同步，传递主服务器runid（第一次为‘ ？’）和复制进度offset（-1）参数。主服务器相应FULLRESYNC，并带上两个参数，runid（自己的id），复制进度offset（第一次全量复制）
• 同步操作，主服务执行bgsave命令，异步将自己当前的数据转成rdb文件，发送给从服务武器。由于是bgsave，没有阻塞主进程的对数据的修改。将同步期间收到的写操作放到缓冲区replication buffer 中。
• 从服务器收到rdb文件，先清除原有的数据，然后将rdb数据载入内存。接着主服务发送缓冲区的命令，然后从服务器执行命令，完成同步。

增量复制过程

当由于网络问题，客户端和主服务器断开连接后，客户端在从服务器读取数据。当主服务器恢复连接后，需要将主服务器所执行的写操作，增量同步到从服务器。

问题是主服务器怎么知道将那些数据同步到从服务器？

使用一个环形缓存repl_backlog_buffer，标记出主服务器执行到的位置（主服务器偏移量），和从服务器读到的位置（从服务器偏移量）

• 如果从服务器要读取的数据还在主服务器，就将主服务器的偏移发送给从服务器，从服务器利用偏移量之差取出缓存的命令，并执行。（增量同步）
• 如果从服务器要读取的数据不在主服务器，就进行全量同步

2.哨兵机制

哨兵机制是为了检测主从服务器是否使用的。

（1）工作机制：

• 判断故障：每隔一秒ping一次，如果主节点没有响应就发起投票，判断主节点是不是主观线。当有一半以上判定主观下线时，就判断为下线。

• 选举新主节点：所有判断主观下线的节点，可以成为领导者候选节点，通过哨兵投票，选出哨兵的leader。leader决定那个是新的主节点。

• 故障转移：在已下线的主节点中选择一个从节点，将其转移成主节点。

  ​ 让原来的从节点修改复制目标。

  ​ 将新主节点的ip信息通过发布者/订阅者机制通知给客户端

  ​ 继续监视旧主节点，当旧主节点上线后改为从节点。

场景

缓存雪崩

大量缓存数据在同一时间过期（失效），请求都打在数据库上。

解决：均匀设置过期时间、互斥锁，并设置超时时间、后台线程定时更新缓存

缓存击穿

缓存中的某个热点数据过期，大量的请求访问了该热点数据。

解决：不给热点数据设置过期时间、互斥锁方案、

缓存穿透

缓存穿透：当用户访问的数据，既不在缓存中，也不在数据库中

解决：非法请求的限制，如果判断出是恶意请求就直接返回错误。

当我们线上业务发现缓存穿透的现象时，可以针对查询的数据，在缓存中设置一个空值或者默认值。

布隆过滤器，写入数据库数据时，使用布隆过滤器做个标记。通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在

布隆过滤器：一个很长的二进制数组，将存入的数据根据多个hash函数计算出位置，然后将计算结果标记成1。