目录
1、 1单点Redis存在的问题；
1、 2Redis持久化；
1、 2.1RDB持久化方式；
1、 2.2AOF持久化方式；
1、 3RDB和AOF持久化方式对比分析；
1、 4Redis主从集群；
1、 4.1搭建Redis主从架构；
1、 4.2数据同步原理；
1、 5Redis的哨兵；
1、 5.1Redis哨兵的作用和原理；
1、 6Redis分片集群；
1、 6.1分片集群结构；
1、 6.2散列插槽；
1、 6.3数据迁移；
1.1 单点Redis存在的问题
1.2 Redis持久化
1.2.1 RDB持久化方式
RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。
快照文件称为RDB文件，默认是保存在当前运行目录。
Redis停机时会执行一次RDB。
小总结：
RDB方式bgsave的基本流程？
1、 fork主进程得到一个子进程，共享内存空间；
2、 子进程读取内存数据并写入新的RDB文件；
3、 用新RDB文件替换旧的RDB文件；
RDB会在什么时候执行？save 60 1000代表什么含义？
•默认是服务停止时。
•代表 60 秒内至少执行 1000 次修改则触发 RDB
RDB的缺点？
1、 RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险；
2、 fork子进程、压缩、写出RDB文件都比较耗时；
1.2.2 AOF持久化方式
AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。
因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置。
1.3 RDB和AOF持久化方式对比分析
1.4 Redis主从集群
1.4.1 搭建Redis主从架构
小总结：
假设有A、B两个Redis实例，如何让B作为A的slave节点？
•在B 节点执行命令： slaveof A 的 IP A 的 port。
1.4.2 数据同步原理
master如何判断slave是不是第一次来同步数据？这里会用到两个很重要的概念：
•Replication Id ：简称 replid ，是数据集的标记， id 一致则说明是同一数据集。每一个 master 都有唯一的 replid ， slave 则会继承 master 节点的 replid
•offset ：偏移量，随着记录在 repl_baklog 中的数据增多而逐渐增大。 slave 完成同步时也会记录当前同步的 offset 。如果 slave 的 offset 小于 master 的 offset ，说明 slave 数据落后于 master ，需要更新。
因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据？
小总结：
简述全量同步的流程？
•slave 节点请求增量同步；
•master 节点判断 replid ，发现不一致，拒绝增量同步；
•master 将完整内存数据生成 RDB ，发送 RDB 到 slave；
•slave 清空本地数据，加载 master 的 RDB；
•master 将 RDB 期间的命令记录在 repl_baklog ，并持续将 log 中的命令发送给 slave；
•slave 执行接收到的命令，保持与 master 之间的同步。
总结：
简述全量同步和增量同步区别？
•全量同步： master 将完整内存数据生成 RDB ，发送 RDB 到 slave 。后续命令则记录在 repl_baklog ，逐个发送给 slave 。
•增量同步： slave 提交自己的 offset 到 master ， master 获取 repl_baklog 中从 offset 之后的命令给 slave。
什么时候执行全量同步？
•slave 节点第一次连接 master 节点时；
•slave 节点断开时间太久， repl_baklog 中的 offset 已经被覆盖时。
什么时候执行增量同步？
•slave 节点断开又恢复，并且在 repl_baklog 中能找到 offset 时。
1.5 Redis的哨兵
1.5.1 Redis哨兵的作用和原理
1.5.1.1 服务状态监控
1.5.1.2 选举新的Master
一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：
•首先会判断 slave 节点与 master 节点断开时间长短，如果超过指定值（ down-after-milliseconds * 10 ）则会排除该 slave 节点
•然后判断 slave 节点的 slave-priority 值，越小优先级越高，如果是 0 则永不参与选举
•如果 slave- prority 一样，则判断 slave 节点的 offset 值，越大说明数据越新，优先级越高
•最后是判断 slave 节点的运行 id 大小，越小优先级越高。
1.5.1.3 如何实现故障转移
总结：
Sentinel的三个作用是什么？
•监控
•故障转移
•通知
Sentinel如何判断一个redis实例是否健康？
•每隔 1 秒发送一次 ping 命令，如果超过一定时间没有相向则认为是主观下线
•如果大多数 sentinel 都认为实例主观下线，则判定服务下线
故障转移步骤有哪些？
•首先选定一个 slave 作为新的 master ，执行 slaveof no one
•然后让所有节点都执行 slaveof 新 master
•修改故障节点，执行 slaveof 新 master
1.6 Redis分片集群
1.6.1 分片集群结构
1.6.2 散列插槽
小总结：
Redis如何判断某个key应该在哪个实例？
•将16384 个插槽分配到不同的实例
•根据 key 的有效部分计算哈希值，对 16384 取余
•余数作为插槽，寻找插槽所在实例即可
如何将同一类数据固定的保存在同一个Redis实例？
•这一类数据使用相同的有效部分，例如 key 都以 { typeId } 为前缀。
1.6.3 数据迁移
参考文献：
黑马程序员Redis入门到实战教程，深度透析redis底层原理+redis分布式锁+企业解决方案+黑马点评实战项目_哔哩哔哩_bilibili
版权声明：本文不是「本站」原创文章，版权归原作者所有 | 原文地址: