我要评论高可用
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。
![[AIGC] Redis基础命令集详细介绍](/images/newimg/nimg1.png)
发表评论