Redis 高可用性アーキテクチャの構築から原理分析まで

この記事では、Redis に関する関連知識を紹介しており、高可用性アーキテクチャの構築から原理分析まで、関連する内容を中心に紹介していますので、一緒に見ていきましょう。 . .

推奨学習: Redis ビデオ チュートリアル

会社の最近のシステム最適化により、大きなテーブルがいくつかのテーブルに分割されました。前に、今度は再び redis を実行します。 redis に関しては、redis サービスを Alibaba Cloud から自社サーバーに移行することが要件の 1 つです (会社の性質上)。この機会を利用して、Redis の高可用性クラスター アーキテクチャを確認してみました。 Redis クラスター モードには、マスター/スレーブ レプリケーション モード、センチネル モード、クラスター クラスター モードの 3 つがあり、一般的にはセンチネル クラスターとクラスター クラスターの使用頻度が高くなります。これら 3 つのモードについて簡単に理解しましょう。

永続化メカニズム

クラスター アーキテクチャを理解する前に、最初に Redis の永続化メカニズムを紹介する必要があります。これは、永続化が後続のクラスターに関係するためです。 Redis の永続性とは、Redis サービスがダウンしたときにクラスター アーキテクチャでのデータの回復やマスター/スレーブ ノードのデータ同期を防ぐために、いくつかのルールに従ってメモリにキャッシュされたデータを保存することです。 Redis 永続化には RDB と AOF の 2 つの方法があり、バージョン 4.0 以降、新しいハイブリッド永続化モードが導入されました。

RDB

RDB は、redis によってデフォルトで有効になっている永続化メカニズムです。その永続化メソッドは、ユーザーによって構成されたルールに基づいています。「X 秒以内に少なくとも Y 個の変更が発生しました」 、スナップショットを生成し、それを dump.rdb バイナリ ファイルに保存します。デフォルトでは、redis は 3 つの構成で構成されています: 900 秒以内に少なくとも 1 つのキャッシュ キーの変更が発生した、300 秒以内に少なくとも 10 のキャッシュ キーの変更が発生した、および 60 秒以内に少なくとも 10,000 の変更が発生した。

Redis の自動スナップショット永続データに加えて、メモリ データの手動スナップショットに役立つ 2 つのコマンドがあります。これらの 2 つのコマンドは、saveand# です。 ##bgs保存。

• save: データ スナップショットを同期的に実行します。キャッシュされたデータの量が多い場合、キャッシュされたデータがブロックされます。他のコマンドの実行効率が低い。

• bgsave: 非同期でデータ スナップショットを実行します。Redis メイン スレッドは、データ スナップショットを実行するために子プロセスをフォークアウトします。これにより、他のプロセスの実行がブロックされません。コマンドにより効率が向上します。非同期スナップショットが使用されるため、スナップショットのプロセス中に他のコマンドによってデータが変更される可能性があります。この問題を回避するために、reids ではコピーオンライト (Cpoy-On-Write) 方式を採用しており、このときスナップショットを取得するプロセスはメインスレッドによってフォークされるため、メインスレッドのリソースを享受することができます。スナップショット プロセス中にデータ変更が発生すると、データがコピーされてコピー データが生成され、子プロセスが変更されたコピー データを dump.rdb ファイルに書き込みます。

RDB スナップショットはバイナリで保存されるため、データの回復は速くなりますが、データ損失のリスクがあります。 60 秒以内に少なくとも 100 件のデータ変更が発生するようにスナップショット ルールが設定されている場合、50 秒の時点で何らかの理由で Redis サービスが突然ダウンし、この 50 秒以内のデータはすべて失われます。

AOF

AOF は Redis のもう 1 つの永続化メソッドです。RDB とは異なり、AOF はデータを変更するすべてのコマンドを記録し、ディスク上の appendonly.aof ファイルに保存します。再起動すると、ファイルがロードされ、ファイルに保存されたコマンドが再度実行されて、データ回復の効果が得られます。デフォルトでは、AOF はオフになっていますが、conf 構成ファイルを変更することでオンにできます。

 # appendonly no  关闭AOF持久化
 appendonly yes   # 开启AOF持久化
 # The name of the append only file (default: "appendonly.aof")
 appendfilename "appendonly.aof" # 持久化文件名

AOF には、コマンドをディスクに保存する 3 つの方法があります。デフォルトでは、AOF はコマンドの永続性のために

appendfsync Everysec を使用します。

appendfsync always #每次有新的改写命令时，都会追加到磁盘的aof文件中。数据安全性最高，但效率最慢。
appendfsync everysec # 每一秒，都会将改写命令追加到磁盘中的aof文件中。如果发生宕机，也只会丢失1秒的数据。
appendfsync no #不会主动进行命令落盘，而是由操作系统决定什么时候写入到磁盘。数据安全性不高。

AOFを開いた後、redisサービスを再起動する必要があり、再度当該書き換えコマンドを実行するとaofファイルに運用コマンドが記録されます。

RDB と比較すると、AOF データのセキュリティは高くなりますが、サービスが実行され続けると、AOF のファイルもセキュリティで保護されます。ますます大きくなり、次回データを復元するときの速度はますます遅くなります。 RDB と AOF の両方が有効になっている場合、redis はデータを復元するときに AOF を優先するため、AOF の方が失われるデータが少なくなります。

AOF## 回収効率高低低

##RDB

低

データセキュリティ

高

スペース使用量

高

混合模式

由于RDB持久化方式容易造成数据丢失，AOF持久化方式数据恢复较慢，所以在redis4.0版本后，新出来混合持久化模式。混合持久化将RDB和AOF的优点进行了集成，并而且依赖于AOF,所以在使用混合持久化前，需要开启AOF。在开启混合持久化后，当发生AOF重写时，会将内存中的数据以RDB的数据格式保存到aof文件中，在下一次的重写之前，混合持久化会追加保存每条改写命令到aof文件中。当需要恢复数据时，会加载保存的rdb内容数据，然后再继续同步aof指令。

  # AOF重写配置，当aof文件达到60MB并且比上次重写后的体量多100%时自动触发AOF重写  auto-aof-rewrite-percentage 100
  auto-aof-rewrite-min-size 64mb
  
  aof-use-rdb-preamble yes # 开启混合持久化# aof-use-rdb-preamble no # 关闭混合持久化

AOF重写是指当aof文件越来越大时，redis会自动优化aof文件中无用的命令，从而减少文件体积。比如在处理文章阅读量时，每查看一次文章就会执行一次Incr命令，但是随着阅读量的不断增加,aof文件中的incr命令也会积累的越来越多。在AOF重写后，将会删除这些没用的Incr命令，将这些命令直接替换为set key value命令。除了redis自动重写AOF，如果需要，也可以通过bgrewriteaof命令手动触发。

主从复制

在生产环境中，一般不会直接配置单节点的redis服务，这样压力太大。为了缓解redis服务压力，可以搭建主从复制，做读写分离。redis主从复制，是有一个主节点Master和多个从节点Slave组成。主从节点间的数据同步只能是单向传输的，只能由Master节点传输到Slave节点。

环境配置

准备三台linux服务器，其中一台作为redis的主节点，两台作为reids的从节点。如果没有足够的机器可以在同一台机器上面将redis文件多复制两份并更改端口号，这样可以搭建一个伪集群。

IP	主/从节点	端口	版本
192.168.36.128	主	6379	5.0.14
192.168.36.130	从	6379	5.0.14
192.168.36.131	从	6379	5.0.14

1. 配置从节点36.130，36.131机器中reids.conf

修改redis.conf文件中的replicaof，配置主节点的ip和端口号，并且开启从节点只读。

2. 启动主节点36.128机器中reids服务

 ./src/redis-server redis.conf

3.  依次启动从节点36.130，36.131机器中的redis服务

 ./src/redis-server redis.conf

启动成功后可以看到日志中显示已经与Master节点建立的连接。如果出现与Master节点的连接被拒，那么先检查Master节点的服务器是否开启防火墙,如果开启，可以开放6379端口或者关闭防火墙。如果防火墙被关闭但连接仍然被拒，那么可以修改Master节点服务中的redis.conf文件。将bing 127.0.0.1修改为本机对外的网卡ip或者直接注释掉即可，然后重启服务器即可。

4. 查看状态

全部节点启动成功后，Master节点可以查看从节点的连接状态，offset偏移量等信息。

 info replication # 主节点查看连接信息

数据同步流程

• 全量数据同步主从节点之间的数据同步是通过建立socket长连接来进行传输的。当Slave节点启动时，会与Master节点建立长连接，并且发送psync同步数据命令。当Master节点收到psync命令时，会执行pgsave进行rdb内存数据快照(这里的rdb快照与conf文件中是否开启rdb无关),如果在快照过程中有新的改写命令，那么Master节点会将这些命令保存到repl buffer缓冲区中。当快照结束后，会将rdb传输给Slave节点。Slave节点在接收到rdb后，如果存在旧数据，那么会将这些旧数据清除并加载rdb。加载完成后会接受master缓存在repl buffer中的新命令。在这些步骤全部执行完成后，主从节点已经算连接成功了，后续Master节点的命令会不断的发送到Slave节点。如果在高并发的情况下，可能会存在数据延迟的情况。

• 部分数据同步

部分数据同步发生在Slave节点发生宕机，并且在短时间内进行了服务恢复。短时间内主从节点之间的数据差额不会太大，如果执行全量数据同步将会比较耗时。部分数据同步时，Slave会向Master节点建立socket长连接并发送带有一个offset偏移量的数据同步请求，这个offset可以理解数据同步的位置。Master节点在收到数据同步请求后，会根据offset结合buffer缓冲区内新的改写命令进行位置确定。如果确定了offset的位置，那么就会将这个位置往后的所有改写命令发送到Slave节点。如果没有确定offset的位置，那么会再次执行全量数据同步。比如，在Slave节点没有宕机之前命令已经同步到了offset=11这个位置，当该节点重启后，向Master节点发送该offset，Master根据offset在缓冲区中进行定位，在定位到11这个位置后，将该位置往后的所有命令发送给Slave。在数据同步完成后，后续Master节点的命令会不断的发送到该Slave节点

优缺点

• 优点

  1. 可以实现一主多从，读写分离，减轻Master节点读操作压力
  2. 是哨兵，集群架构的基础

• 缺点

  1. 自動マスター/スレーブ切り替え機能はありませんので、マスターノードがダウンした場合は手動でマスターノードを切り替える必要があります。マスター ノードがダウンし、同期されていないデータがある場合、データ損失が発生します。
Sentinel モード

Sentinel モードでは、マスター/スレーブがさらに最適化されます。アーキテクチャ内のサーバーの状態に関しては、ダウンタイムが発生すると、Sentinel が短期間で新しいマスター ノードを選択し、マスターとスレーブの切り替えを実行します。それだけでなく、マルチセンチネル ノードでは、各センチネルが相互に監視し、センチネル ノードがダウンしているかどうかを監視します。

#環境構成

IPマスター/スレーブ ノードポートセンチネル ポートバージョン192.168.36.128マスター6379 263795.0.14から## 263795.0.146379##

主从复制是哨兵模式的基础，所以在搭建哨兵前需要完成主从复制的配置。在搭建完主从后，哨兵的搭建就容易很多。 找到安装目录下的sentinel.conf文件并进行修改。主要修改两个地方，分别为哨兵端口port和监控的主节点ip地址和端口号。

在配置完成后，可以使用命令启动各机器的哨兵服务。启动成功后，可查看redis服务和哨兵服务的进行信息。

搭建成功后，就来通过代码演示主节点宕机的情况下，哨兵是否会帮助系统自动进行主备切换。在springboot项目中引入对应的pom,并配置对应的redis哨兵信息。

<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-data-redis</artifactid>
    <version>2.2.2.RELEASE</version></dependency><dependency>
    <groupid>org.apache.commons</groupid>
    <artifactid>commons-pool2</artifactid>
    <version>2.4.2</version></dependency>

server:
  port: 8081spring:
  redis:
    sentinel:
      master: mymaster # 主服务节点
      nodes: 192.168.36.128:26379,192.168.36.130:26379,192.168.36.131:26379 #哨兵节点
    timeout: 3000 #连接超时时间

@Slf4j
@RestController
public class RedisTest {

    @Resource
    private StringRedisTemplate stringRedisTemplate;
    
    /*
    * 每秒钟向redis中写入数据，中途kill掉主节点进程，模拟宕机
    */
    @GetMapping("/redis/testSet")
   public void test(@RequestParam(name = "key") String key,
                    @RequestParam(name = "value") String value) throws InterruptedException {
        int idx=0;
        for(;;){
            try {
                idx++;
                stringRedisTemplate.opsForValue().set(key+idx, value);
                log.info("=====存储成功:{},{}=====",key+idx,value);
            }catch (Exception e){
                log.error("====连接redis服务器失败:{}====",e.getMessage());
            }
            Thread.sleep(1000);
        }
   }
}

当启动服务后，通过节后向后端传递数据，可以看到输出的日志，表示redis哨兵集群已经可以正常运行了。那么这个时候kill掉36.128机器上的主节点，模拟服务宕机。通过日志可以知道，服务出现异常了，在过十几秒发现哨兵已经自动帮系统进行了主从切换，并且服务也可以正常访问了。

2022-11-14 22:20:23.134  INFO 8764 --- [nio-8081-exec-2] com.gz.redis.RedisTest                   : =====存储成功:test14,123=====
2022-11-14 22:20:24.142  INFO 8764 --- [nio-8081-exec-2] com.gz.redis.RedisTest                   : =====存储成功:test15,123=====
2022-11-14 22:20:24.844  INFO 8764 --- [xecutorLoop-1-1] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was /192.168.36.128:6379
2022-11-14 22:20:26.909  WARN 8764 --- [ioEventLoop-4-4] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [192.168.36.128:6379]: Connection refused: no further information: /192.168.36.128:6379
2022-11-14 22:20:28.165 ERROR 8764 --- [nio-8081-exec-2] com.gz.redis.RedisTest                   : ====连接redis服务器失败:Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException: Command timed out after 3 second(s)====
2022-11-14 22:20:31.199  INFO 8764 --- [xecutorLoop-1-1] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.36.128:6379

2022-11-14 22:20:52.189 ERROR 8764 --- [nio-8081-exec-2] com.gz.redis.RedisTest                   : ====连接redis服务器失败:Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException: Command timed out after 3 second(s)====
2022-11-14 22:20:53.819  WARN 8764 --- [ioEventLoop-4-2] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [192.168.36.128:6379]: Connection refused: no further information: /192.168.36.128:6379
2022-11-14 22:20:56.194 ERROR 8764 --- [nio-8081-exec-2] com.gz.redis.RedisTest                   : ====连接redis服务器失败:Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException: Command timed out after 3 second(s)====
2022-11-14 22:20:57.999  INFO 8764 --- [xecutorLoop-1-2] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.36.128:6379
2022-11-14 22:20:58.032  INFO 8764 --- [ioEventLoop-4-4] i.l.core.protocol.ReconnectionHandler    : Reconnected to 192.168.36.131:6379
2022-11-14 22:20:58.040  INFO 8764 --- [nio-8081-exec-2] com.gz.redis.RedisTest                   : =====存储成功:test24,123=====
2022-11-14 22:20:59.051  INFO 8764 --- [nio-8081-exec-2] com.gz.redis.RedisTest                   : =====存储成功:test25,123=====
2022-11-14 22:21:00.057  INFO 8764 --- [nio-8081-exec-2] com.gz.redis.RedisTest                   : =====存储成功:test26,123=====
2022-11-14 22:21:01.065  INFO 8764 --- [nio-8081-exec-2] com.gz.redis.RedisTest                   : =====存储成功:test27,123=====

故障转移

在多个哨兵的模式下，每个哨兵都会向redis节点发送心跳包来检测节点的运行状态。如果某个哨兵发现主节点连接超时了，没有收到心跳，那么系统并不会立刻进行故障转移，这种情况叫做主观下线。如果后续的哨兵节点发现，与主节点的心跳也失败了并且哨兵数量超过2个，那么这个时候就会认为主节点客观下线，并且会进行故障转移，这个客观下线的数值可以在哨兵的配置文件中进行配置。

sentinel monitor master 192.168.36.128 6378 2

在故障转移前，需要选举出一个哨兵leader来进行Master节点的重新选举。哨兵的选举过程大致可以分为三步：

• 当某个的哨兵确定主节点已经下线时，会像其他哨兵发送is-master-down-by-addr命令，要求将自己设为leader，并处理故障转移工作。

• 其他哨兵在收到命令后，进行投票选举

• 如果票数过半时，那么发送命令的哨兵节点将成为主节点，并进行故障转移。

当选举出主哨兵后，那么这个主哨兵就会过滤掉宕机的redis节点，重新选举出Master节点。首先会根据redis节点的优先级进行选举(slave-priority)，数值越大的从节点将会被选举为主节点。如果这个优先级相同，那么主哨兵节点就会选择数据最全的从节点作为新的主节点。如果还是选举失败，那么就会选举出进程id最小的从节点作为主节点。

脑裂

在集群环境下会由于网络等原因出现脑裂的情况，所谓的脑裂就是由于主节点和从节点和哨兵处于不同的网络分区，由于网络波动等原因，使得哨兵没有能够即使接收到主节点的心跳，所以通过选举的方式选举了一个从节点为新的主节点，这样就存在了两个主节点，就像一个人有两个大脑一样，这样会导致客户端还在像老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，哨兵会将老的主节点降为从节点，这时再从新主节点同步数据，这会导致大量数据丢失。如果需要避免脑裂的问题，可以配置下面两行信息。

 min-replicas-to-write 3 # 最少从节点为3
 min-replicas-max-lag 10 # 表示数据复制和同步的延迟不能超过10秒

优缺点

优点：除了拥有主从复制的优点外，还可以进行故障转移，主从切换，系统更加可靠。

缺点：故障转移需要花费一定的时间，在高并发场景下容易出现数据丢失。不容易实现在线扩容。

クラスタモード

セントリーモードでは、マスターノードダウン時にマスター/スレーブの切り替えが可能ですが、切り替え処理に10秒以上かかるため、何らかの問題が発生する可能性があります。 。同時実行性が高くない場合は、このクラスター モードを使用できますが、同時実行性が高い場合、この 10 秒が重大な結果を引き起こす可能性があるため、多くのインターネット企業は Cluster クラスター アーキテクチャを使用しています。クラスター クラスターは複数の Redis ノードで構成されます。各 Redis サービス ノードにはマスター ノードと複数のスレーブ ノードがあります。データを保存するとき、Redis はデータのキーに対してハッシュ操作を実行し、操作結果に基づいて異なるスロットに割り当てます。 。 少し。通常の状況では、クラスタ クラスタ アーキテクチャには 6 つのノード (3 つのマスターと 3 つのスレーブ) が必要です。

環境セットアップ

仮想マシンが 3 台しかないため、各サーバー上にポート 6379 と 6380 を使用して 2 つの Redis サービスを構築する必要があります。構築できるノードは 6 つだけです。

				##192.168.36.130
6379			##192.168.36.131	から
26379	5.0.14

#IPマスター/スレーブ ノードポートバージョン192.168.36.128-63795.0.14##192.168.36.128##192.168.36.130- 63795.0.14---

-	6380	5.0.14
			##192.168.36.130
6380	5.0.14		192.168.36.131
6379	5.0.14		#192.168. 36.131
6380	5.0.14		为了看起来不是那么混乱，可以为cluster新建一个文件夹，并将redis的文件拷贝到cluster文件夹中，并修改文件夹名为redis-6379,reids-6380。 新建完成后，修改每个节点的redis.conf配置文件，找到cluster相关的配置位置，将cluster-enable更改为yes,表示开启集群模式。开启后，需要修改集群节点连接的超时时间cluster-node-timeout，节点配置文件名cluster-config-file等等，需要注意的是，同一台机器上面的服务节点记得更改端口号。 在每个节点都配置完成后，可以依次启动各节点。启动成功后，可以查看redis的进程信息，后面有明显的标识为[cluster]。 现在虽然每个节点的redis都已经正常启动了，但是每个节点之间并没有任何联系啊。所以这个时候还需要最后一步，将各节点建立关系。在任意一台机器上运行下面的命令-- cluster create ip:port,进行集群创建。命令执行成功后，可以看到槽位的分布情况和主从关系。 ./src/redis-cli --cluster create 192.168.36.128:6379 192.168.36.128:6380 192.168.36.130:6379 192.168.36.130:6380 192.168.36.131:6379 192.168.36.131:6380 --cluster-replicas 1复制代码 cluster成功启动后，可以在代码中简单的测试一下，这里的代码依旧采用哨兵模式中的测试代码，只是将sentinel相关的信息注释掉并加上cluster的节点信息即可。 spring:   redis:     cluster:       nodes: 192.168.36.128:6379,192.168.36.128:6380,192.168.36.130:6379,192.168.36.130:6380,192.168.36.131:6379,192.168.36.131:6380#    sentinel:#      master: mymaster#      nodes: 192.168.36.128:26379,192.168.36.130:26379,192.168.36.131:26379     timeout: 3000     lettuce:       pool:         max-active: 80         min-idle: 50 数据分片 Cluster模式下由于存在多个Master节点，所以在存储数据时，需要确定将这个数据存储到哪台机器上。上面在启动集群成功后可以看到每台Master节点都有自己的一个槽位(Slots)范围,Master[0]的槽位范围是0 - 5460，Master[1]的槽位范围是5461 - 10922，Master[2]的槽位范围是10922 - 16383。redis在存储前会通过CRC16方法计算出key的hash值，并与16383进行位运算来确定最终的槽位值。所以，可以知道确定槽位的方式就是 CRC16(key) & 16383。计算出槽位后，此时在java服务端并不知道这个槽位对应到哪一台redis服务，其实在java服务端启动服务时会将redis的相关槽位和映射的ip信息进行一个本地缓存，所以知道槽位后，就会知道对应槽位的ip。 选举机制 cluster模式中的选举与哨兵中的不同。当某个从节点发现自己的主节点状态变为fail状态时，便尝试进行故障转移。由于挂掉的主节点可能会有多个从节点，从而存在多个从节点竞争成为新主节点 。其选举过程大概如下： 从节点将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST信息，通知集群中的所有节点，需要进行重新选举了。 其他节点收到该信息，但只有master节点会进行响应，判断请求者的合法性，并发送 FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack。 发送通知的从节点会收集各master主节点返回的FAILOVER_AUTH_ACK。 如果该从节点收到的ack数过半，那么该节点就会被选举为新的Master主节点。成为主节点后，广播通知其他小集群节点 优缺点 优点： 有多个主节点，做到去中心化。 数据可以槽位进行分布存储 扩展性更高，可用性更高。cluster集群中的节点可以在线添加或删除，官方推荐节点数不超1000。当部分Master节点不可用时，整个集群任然可以正常工作。 缺点： 数据通过异步复制，不保证数据的强一致性 Slave节点在集群中充当冷备，不能缓解读压力 概要 reids は現在非常に人気のあるミドルウェアで、DB への負荷を軽減し、システムのパフォーマンスを向上させるキャッシュとして使用できます。同時実行性のセキュリティを確保するための分散ロックとしても使用できます。システムの結合を軽減するための MQ メッセージ キューとしても使用できます。スタンドアロン モード、マスター/スレーブ レプリケーション、セントリー、クラスター モードをサポートします。各モードには独自の長所と短所があり、実際のプロジェクトでは、独自のビジネス ニーズと同時実行の程度に応じて選択できます。 推奨される学習: Redis ビデオ チュートリアル

以上がRedis 高可用性アーキテクチャの構築から原理分析までの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。