Redisのマスタースレーブレプリケーション、セントリー、クラスタリングの理論を語ろう【画像と文章で詳しく解説】

この記事では、redis の 3 つのモード (マスター/スレーブ レプリケーション、センチネル、クラスター) 理論について、写真と文章を交えて説明します。

1. マスター/スレーブ同期の使用

replication 関数を提供します。この関数は、1 つのデータベースのデータが更新されたときに、更新されたデータを他のデータベースに自動的に同期できます。 [関連する推奨事項: Redis ビデオ チュートリアル ]

master、もう 1 つはマスター データベースです。スレーブ データベース。データベーススレーブ。マスター データベースは読み取りおよび書き込み操作を実行できます。書き込み操作によりデータが変更されると、データはスレーブ データベースに自動的に同期されます。スレーブ データベースは通常読み取り専用で、マスター データベースから同期されたデータを受け取ります。マスター データベースには複数のスレーブ データベースを含めることができますが、スレーブ データベースにはマスター データベースを 1 つだけ含めることができます。

#2. マスタ/スレーブ同期原理

スレーブ マシン プロセスが開始されると、
• sync_command

  コマンドをマスター マシンに送信して同期接続を要求します。

最初の接続であっても再接続であっても、マスター マシンはバックグラウンド プロセスを開始してデータ スナップショット (RDB) をデータ ファイル (.rdb ファイル) に保存し、マスター マシンはまた、データを変更するすべてのコマンドが記録され、データ ファイルにキャッシュされます。
バックグラウンド プロセスがキャッシュ操作を完了した後、マスター マシンはデータ ファイルをスレーブ マシンに送信します。スレーブ マシンはデータ ファイルをハードディスクに保存し、ロードします。をメモリに保存すると、マスター マシンはデータを変更するためのすべての操作をスレーブ マシンに送信します。スレーブに障害が発生してダウンタイムが発生した場合、正常に戻った後に自動的に再接続されます。
マスター マシンがスレーブ マシンから接続を受信した後、完全なデータ ファイルをスレーブ マシンに送信します。マスターが複数のスレーブ マシンから同時に同期要求を受信した場合、マスター マシン プロセスがバックグラウンドで開始されてデータ ファイルが保存され、その後すべてのスレーブ マシンに送信されて、すべてのスレーブ マシンが正常であることを確認します。
#RDB は完全同期を実行し、AOF は増分同期を実行します

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

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

1. セントリーの役割

Sentinel モードの主な機能:

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

1 つ以上の Sentinel

インスタンスで構成されるシステムを使用して、redis ノードを監視します。マスター ノードに障害が発生した場合、スレーブ ノードの 1 つをマスター ノードにアップグレードできます。フェイルオーバーによりシステムが保証されます。可用性。

2.1 原則の詳細説明

sentinel
• の設定ファイルにマスターノードの情報を設定します。
  センチネル ノードは、設定されたマスター ノードとの 2 つの接続を確立します: コマンド接続とサブスクリプション接続です。
• PS: Redis のパブリッシュとサブスクライブ (pub/sub) は一種の接続です。メッセージの通信モード: 送信者 (パブ) がメッセージを送信し、サブスクライバー (サブ) がメッセージを受信します。

  
  

  Sentinel は、コマンド接続を通じて 10 秒ごとに INFO コマンドを送信します。INFO コマンドを通じて、マスター ノードは独自の run_id と独自のスレーブ ノード情報を返します。

• Sentinel は、これらのスレーブ ノードに対して 2 つの接続コマンド接続とサブスクリプション接続も確立します。

• センチネルはコマンド接続を通じて INFO コマンドをスレーブ ノードに送信し、情報の一部を取得します:

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

  ログイン後にコピー

sentinel:hello
• チャネルに、独自の IP、ポート、実行 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. 根據資料流向進行最佳化

程式設計入門！ ！

以上がRedisのマスタースレーブレプリケーション、セントリー、クラスタリングの理論を語ろう【画像と文章で詳しく解説】の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。