redis 三种模式（主从复制，哨兵，集群）理论图文详解和 redis 总结

---

上接：
https://blog.csdn.net/shenyuanhaojie/article/details/121274871

https://blog.csdn.net/shenyuanhaojie/article/details/121231039

---

一、主从复制

1. 主从同步的用处

  通过持久化功能，redis 保证了即使在服务器重启的情况下也不会丢失数据，因为持久化会把内存中的数据保存到硬盘上，重启会从硬盘上加载数据，但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。为此，redis 提供了复制 replication 功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。
  在复制的概念中，数据库分为两类，一类是主数据库 master，另一类是从数据库 slave。主数据库可以进行读写操作，当写操做导致数据变化时自动将数据同步给从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

2. 主从同步原理

2.1 原理详解

• 若启动一个 Slave 机器进程，则它会向 Master 机器发送一个 sync_command 命令，请求同步连接。

• 无论是第一次连接还是重新连接，Master 机器都会启动一个后台进程，将数据快照（RDB）保存到数据文件中（.rdb文件），同时 Master 还会记录修改数据的所有命令并缓存在数据文件中。

• 后台进程完成缓存操作之后，Master 机器就会向 Slave 机器发送数据文件，Slave 端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着 Master 机器就会将修改数据的所有操作一并发送给 Slave 端机器。若 Slave 出现故障导致宕机，则恢复正常后会自动重新连接。

• Master 机器收到 Slave 端机器的连接后，将其完整的数据文件发送给 Slave 端机器，如果 Master 同时收到多个 Slave发来的同步请求则 Master 会在后台启动一个进程以保存数据文件，然后将其发送给所有的 Slave 端机器，确保所有的 Slave 端机器都正常。

RDB 做全量同步，AOF 做增量同步

2.2 理论精简

slave -> master 发送 sync command 申请同步
master 主进程 -> 调用 fork() 函数 派生 RDB 子进程进行持久化 -> 生成 RDB 文件
将 RDB 文件推送给 slaves（完成全量同步）
#增量同步：使用到了 AOF 持久化（机制：将缓存数据保存到缓冲中），所以主从节点均需要开启 AOF
增量同步是通过 AOF 功能将缓存中的数据 append（追加）到缓冲中来进行 master 缓冲 -> slave 缓冲的同步
在持续性的运行过程中，也是增量持续同步的过程

2.3 最终精简版

slave -> master 发送 sync
master 使用 RDB 生成 .rdb 文件（全量同步）发送给 slaves
master 使用 AOF 将缓冲区数据同步给 slaves 缓冲区数据（增量）

---

二、哨兵模式

1. 哨兵的作用

哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题

哨兵模式主要功能：

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

  使用一个或者多个哨兵 sentinel 实例组成的系统，对 redis 节点进行监控，在主节点出现故障的情况下，能将从节点中的一个升级为主节点，进行故障转移，保证系统的可用性。

2. 哨兵原理

2.1 原理详解

• 首先主节点的信息是配置在哨兵 sentinel 的配置文件中。

• 哨兵节点会和配置的主节点建立起两条连接命令连接和订阅连接
  PS：redis 发布订阅（pub/sub）是一种消息通信模式:发送者（pub）发送消 息，订阅者 （sub）接收消息。

• 哨兵会通过命令连接每 10s 发送一次 INFO 命令，通过 INFO 命令，主节点会返回自己的 run_id 和自己的从节点信息。

• 哨兵会对这些从节点也建立两条连接命令连接和订阅连接。

• 哨兵通过命令连接向从节点发送 INFO 命令，获取到他的一些信息：

run id（redis 服务器 id） 
role（职能）
从服务器的复制偏移量 offset
其他

• 通过命令连接向服务器的 sentinel:hello 频道发送一条消息，内容包括自己的 IP、端口、run id、配置（后续投票的时候会用到）等。

• 通过订阅连接对服务器的 sentinel:hello 频道做了监听，所有向该频道发送的哨兵的消息都能被接受到。

• 解析监听到的消息，进行分析提取，就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些哨兵节点记录下来。

• 向观察到的其他的哨兵节点建立命令连接（此时没有订阅连接）。

2.2 原理精简

3 个哨兵 3 个 redis

• 三个哨兵之间建立命令连接，周期检测 “队友” 状态
• 哨兵会向 master 节点（己在配置文件中指定）发送两条连接，分别是命令连接和订阅连接（为了周期性获取 master 节点的数据)
• 哨兵向 master 周期性发送 info 命令，master（活着的情况下）会返回 redis-cli info replication master 节点的信息 + 从节点位置
• 哨兵通过 master 返回的信息，再向 slaves 节点发送 info 命令，slaves 返回数据，从而哨兵集群就可以获取到 redis 所有集群信息
• 哨兵会向服务器发送命令连接，建立自己的 hello 频道，哨兵会向这个 hello 频道建立订阅，用于哨兵之间的消息共享

2.3 思路

• 3 个哨兵互相监听，使用 ping 互相检测存活
• 3 个哨兵分别向数据节点 master 发送命令连接和订阅连接（info 命令）获取数据节点信息（包含主从节点）3 个哨兵再向其他从节点发送 info ，用于获取从节点详细信息
• 3 个哨兵之间通过 hello 频道进行消息共享

3. 哨兵模式下的故障迁移

• ① 主观下线
  哨兵节点会每秒一次的频率向建立了命令连接的实例发送 PING 命令，如果在 down-after-milliseconds 毫秒内没有做出有效响应包括 PONG/LOADING/MASTERDOWN 以外的响应，哨兵就会将该实例在本结构体中的状态标记为 SRI_S_DOWN 主观下线。

• ② 客观下线
  当一个哨兵节点发现主节点处于主观下线状态是，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。如果超过配置参数 quorum 个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为 SRIO DOWN 客观下线询问命令 SENTINEL is-master-down-by-addr。

• ③ master 选举
  在认为主节点客观下线的情况下，哨兵节点节点间会发起一次选举，命令为 SENTINEL is-master-down-by-addr ，只是 runid 这次会将自己的 runid 带进去，希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为 leader 的情况下，会有该 leader 对故障进行迁移。

• ④ 故障转移

####在从节点中挑选出新的主节点
通讯正常
优先级排序
优先级相同时选择 offset 最大的

###将该节点设置成新的主节点SLAVEOF no one,并确保在后续的INGO命令时 该节点返回状态为master 
###将其他的从节点设置成从新的主节点复制，SLAVEOF命令
###将旧的主节点变成新的主节点的从节点

PS:优缺点
#优点:
高可用，哨兵模式是基于主从模式的，所有主从模式的优点，哨兵模式都具有有;主从可以自动切换，系统更健壮，可用性更高

#缺点:
redis 比较难支持在线扩容，在群集容量达到上限时在线扩容会变得很复杂

---

三、集群

1. redis 集群的含义

主节点负责读写请求和集群信息的维护，从节点只进行主节点数据和状态信息的复制

  redis 的哨兵模式基本已经可以实现高可用、读写分离，但是在这种模式每台 redis 服务器都存储相同的数据，很浪费内存资源，所以在 redis3.0 上加入了 Cluster 群集模式，实现了 redis 的分布式存储，也就是说每台 redis 节点存储着不同的内容。根据官方推荐，集群部署至少要 3 台以上的 master 节点，最好使用 3 主 3 从六个节点的模式。
  Cluster 群集由多个 redis 服务器组成的分布式网络服务群集，群集之中有多个 master 主节点，每一个主节点都可读可写，节点之间会相互通信，两两相连，redis 群集无中心节点。

2. redis 集群的特点

• 在 redis-Cluster 群集中，可以给每个一个主节点添加从节点，主节点和从节点直接尊循主从模型的特性，当用户需要处理更多读请求的时候，添加从节点可以扩展系统的读性能
• redis-cluster 的故障转移：redis 群集的主机节点内置了类似 redis sentinel 的节点故障检测和自动故障转移功能，当群集中的某个主节点下线时，群集中的其他在线主节点会注意到这一点，并且对已经下线的主节点进行故障转移
• 集群进行故障转移的方法和 redis sentinel 进行故障转移的方法基本一样，不同的是，在集群里面，故障转移是由集群中其他在线的主节点负责进行的，所以群集不必另外使用 redis sentinel

---

四、分布式锁

https://www.zhihu.com/question/300767410/answer/1749442787
  如果在一个分布式系统中，我们从数据库中读取一个数据，然后修改保存，这种情况很容易遇到并发问题。因为读取和更新保存不是一个原子操作，在并发时就会导致数据的不正确。这种场景其实并不少见，比如电商秒杀活动，库存数量的更新就会遇到。如果是单机应用，直接使用本地锁就可以避免。如果是分布式应用，本地锁派不上用场，这时就需要引入分布式锁来解决。由此可见分布式锁的目的其实很简单，就是为了保证多台服务器在执行某一段代码时保证只有一台服务器执行。

简单来说：
  现在的业务应用通常都是微服务架构，这也意味着一个应用会部署多个进程，那么多个进程如果需要修改数据库中的同一行记录时，为了避免操作乱序导致数据错误，此时就需要引入分布式锁解决问题。

为了保证分布式锁的可用性，至少要确保锁的实现要同时满足以下几点：

• 互斥性。在任何时刻，保证只有一个客户端持有锁。
• 不能出现死锁。如果在一个客户端持有锁的期间，这个客户端崩溃了，也要保证后续的其他客户端可以上锁。
• 保证上锁和解锁都是同一个客户端。

一般来说，实现分布式锁的方式有以下几种：

• 使用 MySQL，基于唯一索引。
• 使用 ZooKeeper，基于临时有序节点。
• 使用 Redis，基于 setnx 命令。

对 redis 来说注意三点，对 key 的加锁，如果请求未完成对快要过期的 key 的续期，请求完成后 key 的解锁。防止并发环境下被读取的一个 key 可能被多个请求修改，造成无效操作，资源浪费的情况。

五、redis 总结

• redis 可以做为 mysql 的前置缓存数据库，redis 与 mysql 对接的方式需要配置线程池，需要定义后端 mysql 的位置（ IP + port ＋sock 文件的位置）

• redis 基础功能：用于内存/缓存的快速存储（读取）

• 实现的方式：

默认将数据存储在内存/缓存中
具有丰富的数据类型：string list hash set && order set 等
重要数据持久化的功能，持久化的方式：AOF RDB

单线程模式 -> 速度快的原因之一：Epoll + I/O 复用（cluster 中的 slots 哈希槽可以充当数据读、取的索引)

• redis 中的算法：

LRU：淘汰策略
1) 缓存中的数据进行随机淘汰
2) 缓存中被设置了过期时间的数据进行随机淘汰
3) 缓存中被设置了过期时间的数据，进行惰性删除（仅当访问到的数据过期了，才会删除）
4) 当数据持续存储过程中内存将满，会在设置了过期时间的数据中进行近期淘汰

令牌桶 + 漏桶算法：限流
Raft：选举机制，用于选举新的主节点

• redis 缓存高热数据的机制

高热数据：命中次数高的数据
指定提高缓存内数据的命中数，最直接的可以刷脚本，访问这些数据

六、系统优化

1. 单例服务器，服务器本身优化

硬件资源选择（系统五大资源）

• 磁盘 固态盘 SCSI（硬件磁盘阵列）
• 服务器内存条选择（本地服务器和云服务器）
• CPU 核数选择
• 网络网卡（本地服务器和云服务器），需要考虑负载压力下的网络流量 QPS
• 服务器选型（麒麟、晓龙、浪潮英信、华为、华三、戴尔（类型：刀片、塔式、机柜））

以上需要计算费用成本，还需要考虑到该服务器上的服务在运行时消耗的性能比例（需要预留给系统一部分资源）

服务本身环境的选择

• 操作系统选择 Linux 发行版：centos ubuntu redhat server debian alphon mac SUSE（PS：虚拟化 KVM XEN FUFE）

• 基于操作系统，依赖环境。选择最小化安装还是指定操作系统版本的安装 + 指定内核版本。软件是否有依赖（例如：tomcat 需要 JDK，编译需要 gcc gcc-c++ pcre …）

• 软件资源优化 五大负载＋内核优化（TCP协议相关、队列相关、路由转发、重定向、端口、文件打开数、系统的软硬限制等）

2. 单例服务器应用服务本身优化

以 redis 为例

首先从启动读取的恢复文件来看，基于AOF需要开启 AOF功能（RDB 默认）

• RDB 中 save M N 触发周期的选择判定，这会影响到磁盘资源的使用
• AOF 中选择合适的 syncwrite 同步写入磁盘的策略 everysecond

使用过程中，需要考虑到的是内存的使用量（ OOM ）

• 内存淘汰策略：惰性淘汰＋定期删除，禁止淘汰＋定期删除。根据情况选择合适的淘汰策略（配置文件中定义）。

持久化方向
持久化的功能在保证数据完整性的同时，依然会持续性的对磁盘产生存储压力（压力来源于 AOF 和 RDB 生成的数据文件，AOF 和 RDB 的日志文件）。

• 数据/日志文件的定期归档
• 日志文件的分割（保存在日志中心）
• 共享存储 NFS GFS fastDFS

redis主进程

• 可以使用两个 redis 主进程配合实现备份冗余，提高抗高并发的能力

3. 集群优化

4. 架构优化

5. 根据数据流向进行优化