Redis 고급 학습 고가용성 센티널(요약 공유)

이 문서는 기능 아키텍처, 배포 및 구성과 관련된 문제를 포함하여 Redis의 고가용성 Sentinel에 대한 관련 지식을 제공합니다. 모든 사람에게 도움이 되기를 바랍니다.

추천 학습: Redis 동영상 튜토리얼

1. 기능 및 아키텍처

1. 기능

Sentinel을 소개하기 전에 먼저 Redis의 고가용성과 관련된 기술을 거시적 관점에서 검토하세요. 여기에는 지속성, 복제, 센티널 및 클러스터가 포함됩니다. 주요 기능과 해결된 문제는 다음과 같습니다.

• 지속성: 지속성은 가장 간단한 고가용성 방법입니다(때로는 고가용성 방법으로 분류되지도 않음). 주로 기능은 데이터입니다. 즉, 프로세스 종료로 인해 데이터가 손실되지 않도록 데이터가 하드 디스크에 저장됩니다.
• 복제: 복제는 고가용성 Redis의 기반입니다. Sentinel과 Cluster 모두 복제를 기반으로 고가용성을 달성합니다. 복제는 주로 데이터의 다중 시스템 백업은 물론 읽기 작업에 대한 로드 밸런싱 및 간단한 오류 복구를 구현합니다. 단점: 오류 복구는 자동화될 수 없습니다. 쓰기 작업은 로드 밸런싱될 수 없습니다. 스토리지 용량은 단일 시스템으로 제한됩니다.
• Sentinel: Sentinel은 복제를 기반으로 자동화된 오류 복구를 구현합니다. 단점: 쓰기 작업은 로드 밸런싱될 수 없으며 스토리지 용량은 단일 시스템으로 제한됩니다.
• 클러스터: Redis는 클러스터링을 통해 쓰기 작업의 로드 밸런싱이 불가능하고 스토리지 용량이 단일 머신으로 제한되는 문제를 해결하여 상대적으로 완전한 고가용성 솔루션을 달성합니다.

이제 보초에 대해 이야기해 보겠습니다.

Redis Sentinel이라고도 알려진 Redis Sentinel은 Redis 버전 2.8에서 도입되었습니다. Sentinel의 핵심 기능은 마스터 노드의 자동 장애 조치입니다. 다음은 Redis 공식 문서에 있는 Sentinel 기능에 대한 설명입니다.

• Monitoring: Sentinel은 마스터 노드와 슬레이브 노드가 정상적으로 작동하는지 지속적으로 확인합니다.
• 자동 장애 조치: 마스터 노드가 제대로 작동하지 않으면 Sentinel은 장애가 발생한 마스터 노드의 슬레이브 노드 중 하나를 새 마스터 노드로 업그레이드하고 다른 슬레이브 노드를 복사하도록 합니다. 새로운 마스터 노드.
• 구성 공급자: 초기화 중에 클라이언트는 센티널에 연결하여 현재 Redis 서비스의 마스터 노드 주소를 얻습니다.
• 알림: Sentinel은 장애 조치 결과를 클라이언트에 보낼 수 있습니다.

그 중 모니터링 및 자동 장애 조치 기능을 통해 Sentinel은 마스터 노드 장애를 적시에 감지하고 전송을 완료할 수 있으며 구성 공급자 및 알림 기능은 클라이언트와의 상호 작용에 반영되어야 합니다.

다음은 기사에서 "클라이언트"라는 단어의 사용법에 대한 설명입니다. 이전 기사에서는 redis 서버가 API를 통해 액세스되는 한 redis-cli, Java 클라이언트를 포함하여 클라이언트라고 부릅니다. 구별과 설명을 용이하게 하기 위해 이 문서의 클라이언트에는 redis-cli가 포함되어 있지 않지만 redis-cli보다 더 복잡합니다. redis-cli는 redis에서 제공하는 기본 인터페이스를 사용하고 클라이언트는 이를 캡슐화합니다. Sentinel의 구성 공급자 및 알림 기능을 최대한 활용하기 위한 인터페이스 및 기능입니다.

2. 아키텍처

일반적인 Sentinel 아키텍처 다이어그램은 다음과 같습니다.

Sentinel 노드와 데이터 노드의 두 부분으로 구성됩니다.

• Sentinel 노드: Sentinel 시스템은 하나 이상의 Sentinel로 구성됩니다. 노드, Sentinel 노드는 데이터를 저장하지 않는 특수 Redis 노드입니다.
• 데이터 노드: 마스터 노드와 슬레이브 노드는 모두 데이터 노드입니다.

2. 배포

이 부분에서는 마스터 노드 1개, 슬레이브 노드 2개, 센티넬 노드 3개를 포함한 간단한 센티널 시스템을 배포합니다. 편의상 이러한 모든 노드는 포트 번호로 구별되는 하나의 시스템(LAN IP: 192.168.92.128)에 배포되며 노드 구성은 최대한 단순화됩니다.

1. 마스터-슬레이브 노드 배포

Sentinel 시스템의 마스터-슬레이브 노드는 일반 마스터-슬레이브 노드와 동일하며 추가 구성이 필요하지 않습니다. 다음은 마스터 노드(포트=6379)와 두 개의 슬레이브 노드(포트=6380/6381)의 구성 파일입니다. 구성은 비교적 간단하므로 자세히 설명하지 않습니다.

#redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
#redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 192.168.92.128 6379
#redis-6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 192.168.92.128 6379

redis-server redis-6379.conf
redis-server redis-6380.conf
redis-server redis-6381.conf

노드 시작 후 마스터 노드에 접속하여 마스터-슬레이브 상태가 정상인지 확인합니다. 구성이 완료되면 마스터 노드와 슬레이브 노드를 순서대로 시작합니다.

2. 센티넬 노드 배포

센티넬 노드는 본질적으로 특별한 Redis 노드입니다.

세 개의 센티넬 노드 구성은 거의 동일합니다. 주요 차이점은 포트 번호(26379/26380/26381)입니다. 다음은 26379 노드를 예로 들어 구성을 소개합니다. 부분은 최대한 간단하므로 나중에 더 많은 구성을 소개하겠습니다.

#sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 192.168.92.128 6379 2

哨兵节点的启动有两种方式，二者作用是完全相同的：其中，sentinel monitor mymaster 192.168.92.128 6379 2 配置的含义是：该哨兵节点监控192.168.92.128:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。

redis-sentinel sentinel-26379.conf
redis-server sentinel-26379.conf --sentinel

3.  总结

按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过redis-cli连接哨兵节点进行验证

哨兵系统的搭建过程，有几点需要注意：

（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。

（2）哨兵节点本质上是redis节点。

（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。

三、客户端访问哨兵系统

上一小节演示了哨兵的两大作用：监控和自动故障转移，本小节则结合客户端演示哨兵的另外两个作用：配置提供者和通知。

1.  代码示例

在介绍客户端的原理之前，先以Java客户端Jedis为例，演示一下使用方法：下面代码可以连接我们刚刚搭建的哨兵系统，并进行各种读写操作（代码中只演示如何连接哨兵，异常处理、资源关闭等未考虑）。

public static void testSentinel() throws Exception {
         String masterName = "mymaster";
         Set<String> sentinels = new HashSet<>();
         sentinels.add("192.168.92.128:26379");
         sentinels.add("192.168.92.128:26380");
         sentinels.add("192.168.92.128:26381");
         JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作
         Jedis jedis = pool.getResource();
         jedis.set("key1", "value1");
         pool.close();
}

Jedis客户端对哨兵提供了很好的支持。如上述代码所示，我们只需要向Jedis提供哨兵节点集合和masterName，构造JedisSentinelPool对象；然后便可以像使用普通redis连接池一样来使用了：通过pool.getResource()获取连接，执行具体的命令。2.  客户端原理

在整个过程中，我们的代码不需要显式的指定主节点的地址，就可以连接到主节点；代码中对故障转移没有任何体现，就可以在哨兵完成故障转移后自动的切换主节点。之所以可以做到这一点，是因为在JedisSentinelPool的构造器中，进行了相关的工作；主要包括以下两点：

（1）遍历哨兵节点，获取主节点信息：遍历哨兵节点，通过其中一个哨兵节点+masterName获得主节点的信息；该功能是通过调用哨兵节点的sentinel get-master-addr-by-name命令实现，该命令示例如下：

一旦获得主节点信息，停止遍历（因此一般来说遍历到第一个哨兵节点，循环就停止了）。

（2）增加对哨兵的监听：这样当发生故障转移时，客户端便可以收到哨兵的通知，从而完成主节点的切换。具体做法是：利用redis提供的发布订阅功能，为每一个哨兵节点开启一个单独的线程，订阅哨兵节点的+switch-master频道，当收到消息时，重新初始化连接池。

3.  总结

通过客户端原理的介绍，可以加深对哨兵功能的理解：

（1）配置提供者：客户端可以通过哨兵节点+masterName获取主节点信息，在这里哨兵起到的作用就是配置提供者。

需要注意的是，哨兵只是配置提供者，而不是代理。二者的区别在于：如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求(如set/get)会直接发向主节点；如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。

举一个例子可以很好的理解哨兵的作用是配置提供者，而不是代理。在前面部署的哨兵系统中，将哨兵节点的配置文件进行如下修改：

sentinel monitor mymaster 192.168.92.128 6379 2
改为
sentinel monitor mymaster 127.0.0.1 6379 2

（2）通知：哨兵节点在故障转移完成后，会将新的主节点信息发送给客户端，以便客户端及时切换主节点。然后，将前述客户端代码在局域网的另外一台机器上运行，会发现客户端无法连接主节点；这是因为哨兵作为配置提供者，客户端通过它查询到主节点的地址为127.0.0.1:6379，客户端会向127.0.0.1:6379建立redis连接，自然无法连接。如果哨兵是代理，这个问题就不会出现了。

四、基本原理

前面介绍了哨兵部署、使用的基本方法，本部分介绍哨兵实现的基本原理。

1. Sentinel 노드에서 지원하는 명령

Sentinel 노드는 특수 모드로 실행되는 Redis 노드로, 지원하는 명령은 일반 Redis 노드와 다릅니다. 운영 및 유지 관리에서는 이러한 명령을 통해 Sentinel 시스템을 쿼리하거나 수정할 수 있지만 더 중요한 것은 Sentinel 시스템이 오류 검색 및 장애 조치와 같은 다양한 기능을 구현하기 위해서는 Sentinel 노드 간의 통신과 분리될 수 없으며, 통신은 매우 간단합니다. 이 중 대부분은 센티넬 노드에서 지원하는 명령을 통해 이루어집니다. 다음은 Sentinel 노드에서 지원하는 주요 명령어를 소개합니다.

(1) 기본 쿼리: 이 명령어를 통해 Sentinel 시스템의 토폴로지, 노드 정보, 구성 정보 등을 쿼리할 수 있습니다.

• info sentinel: 모니터링되는 모든 마스터 노드의 기본 정보 가져오기
• sentinel masters: 모니터링되는 모든 마스터 노드의 세부 정보 가져오기
• sentinel master mymaster: 모니터링되는 모든 마스터 노드의 세부 정보 가져오기 mymaster
• sentinelslaves mymaster: 세부 정보 가져오기 모니터링되는 마스터 노드 mymaster 및 슬레이브 노드의 정보
• sentinel sentinels mymaster: 모니터링되는 센티넬 노드 mymaster의 세부 정보 가져오기
• sentinel get-master-addr-by-name mymaster: 모니터링되는 마스터 노드 mymaster 주소 정보 가져오기 이전 기사에서 소개한 바 있습니다
• sentinel is-master-down-by-addr: Sentinel 노드는 이 명령을 사용하여 마스터 노드가 오프라인인지 여부를 물어 객관적으로 오프라인인지 판단할 수 있습니다

(2) 마스터노드 모니터링 추가/삭제

sentinel monitor mymaster2 192.168.92.128 16379 2 : 설정파일의 sentinel monitor 기능은 sentinel 노드 배포시와 완전히 동일하므로 자세한 설명은 생략하겠습니다

sentinel Remove mymaster2: 현재 Sentinel 노드 취소 마스터 노드 mymaster2 모니터링

(3) 강제 장애 조치

sentinel 장애 조치 mymaster: 이 명령은 현재 마스터 노드가 그대로 실행 중이더라도 mymaster 장애 조치를 강제할 수 있습니다. 예를 들어, 현재 마스터 노드의 머신이 폐기될 예정인 경우, Failover 명령을 통해 미리 Failover를 수행할 수 있습니다.

2. 기본 원리

센트리의 원리는 다음 개념을 이해하는 것이 중요합니다.

(1) 예약된 작업: 각 센티널 노드는 3개의 예약된 작업을 유지합니다. 예약된 작업의 기능은 다음과 같습니다. 마스터-슬레이브 노드에 정보 명령을 보내 최신 마스터-슬레이브 구조를 얻습니다. 게시 및 구독 기능을 통해 다른 센티널 노드의 정보를 얻습니다. 핑을 보내 하트비트 감지를 수행합니다. 다른 노드에 명령을 내려 오프라인 상태인지 확인합니다.

(2) 주관적 오프라인: 예정된 하트비트 감지 작업에서 다른 노드가 일정 시간 동안 응답하지 않으면 센티넬 노드가 주관적으로 해당 노드를 오프라인합니다. 이름에서 알 수 있듯이 주관적 오프라인은 감시 노드가 오프라인을 "주관적으로" 판단한다는 의미입니다. 주관적 오프라인의 상대는 객관적인 오프라인입니다.

(3) 목표 오프라인: Sentinel 노드가 주관적으로 마스터 노드를 오프라인시킨 후, 다음과 같이 판단되면 sentinel is-master-down-by-addr 명령을 통해 다른 Sentinel 노드에게 마스터 노드의 상태를 묻습니다. 마스터 노드가 오프라인 상태입니다. 센티널 수가 특정 값에 도달하면 마스터 노드는 객관적으로 오프라인 상태가 됩니다.

목표 오프라인은 마스터 노드에만 적용되는 개념입니다. 슬레이브 노드와 센티널 노드가 실패하면 센티널에 의해 주관적으로 오프라인 상태가 된 후 후속 목표 오프라인 및 장애 조치 작업이 발생하지 않습니다.

(4) 리더 센티넬 노드 선출: 마스터 노드가 객관적으로 오프라인이라고 판단되면 각 센티넬 노드는 협상하여 리더 센티넬 노드를 선출하고, 리더 노드는 이에 대한 장애 조치 작업을 수행합니다.

마스터 노드를 모니터링하는 모든 센티널은 리더로 선출될 수 있습니다. 선거에 사용되는 알고리즘은 Raft 알고리즘의 기본 아이디어입니다. 즉, 한 라운드에서 선착순입니다. , 센티넬 A는 리더가 되기 위해 B에게 메시지를 보냅니다. 리더의 신청에 대해 B가 다른 센티널에 동의하지 않은 경우 A가 리더가 되는 데 동의합니다. 여기서는 구체적인 선거 과정에 대해 자세히 설명하지 않습니다. 일반적으로 파수꾼 선정 과정은 오프라인에서 먼저 목표를 달성하는 사람이 리더가 되는 것이 일반적입니다.

(5) 장애 조치: 선출된 리더 센티널은 장애 조치 작업을 시작하며 대략 3단계로 나눌 수 있습니다.

슬레이브 노드에서 새 마스터 노드 선택: 선택 원칙은 먼저 건강하지 않은 슬레이브 노드를 필터링하고; 그런 다음 우선 순위가 가장 높은 슬레이브 노드를 선택합니다(slave-priority로 지정). 우선 순위를 구별할 수 없으면 가장 큰 복제 오프셋을 가진 슬레이브 노드를 선택합니다. 여전히 구별할 수 없으면 가장 작은 runid 슬레이브 노드를 가진 슬레이브 노드를 선택합니다. .
• 마스터-슬레이브 상태 업데이트: 선택한 슬레이브 노드를 마스터 노드로 만들려면slaveofnoone 명령을 사용하고 다른 노드를 슬레이브 노드로 만들려면 슬레이브of 명령을 사용하세요.
• 오프라인 마스터 노드(예: 6379)를 새 마스터 노드의 슬레이브 노드로 설정합니다. 6379가 다시 온라인 상태가 되면 새 마스터 노드의 슬레이브 노드가 됩니다.

5. 구성 및 실습 제안

1. 구성

다음은 Sentinel과 관련된 몇 가지 구성을 소개합니다.

(1) 감시 모니터 {masterName} {masterIp} {masterPort} {quorum}

sentinel 모니터는 sentinel의 핵심 구성입니다. 이전에 sentinel 노드를 배포할 때 설명한 바 있습니다. 그 중 masterName은 마스터 노드 이름을 지정하고, masterIp 및 masterPort는 마스터 노드 주소를 지정하며, quorum은 sentinel의 임계값 수를 지정합니다. 마스터 노드의 오프라인 상태를 판단하는 방법 : 마스터 노드가 오프라인 상태라고 판단한 센티널의 수가 정족수에 도달하면 마스터 노드는 객관적으로 오프라인 상태가 됩니다. 권장 값은 센티널 수의 절반에 1을 더한 값입니다.

(2) sentinel down-after-milliseconds {masterName} {time}

sentinel down-after-milliseconds는 주관적인 오프라인 판단과 관련이 있습니다. sentinel은 ping 명령을 사용하여 다른 노드에서 하트비트 감지를 수행합니다. 노드 초과 다운 - 밀리초 이후 구성된 시간 내에 응답이 없으면 Sentinel은 주관적으로 오프라인으로 기록합니다. 이 구성은 마스터 노드, 슬레이브 노드 및 센티넬 노드의 주관적인 오프라인 결정에 유효합니다.

다운 후 밀리초의 기본값은 30000이며, 이는 다양한 네트워크 환경 및 애플리케이션 요구 사항에 따라 조정될 수 있습니다. 값이 클수록 주관적인 오프라인 판단이 느슨해지며 가능성이 있다는 장점이 있습니다. 오판의 확률이 적고, 결함 발견 및 장애 복구 시간이 길어지고 클라이언트의 대기 시간도 길어진다는 단점이 있습니다. 예를 들어 애플리케이션에 고가용성 요구 사항이 있는 경우 오류가 발생할 때 가능한 한 빨리 전송을 완료하기 위해 값을 적절하게 줄일 수 있습니다. 네트워크 환경이 상대적으로 열악한 경우 빈번한 오판을 피하기 위해 임계값을 적절하게 늘릴 수 있습니다.

(3) sentinel parallel-syncs {masterName} {number}

sentinel parallel-syncs는 장애 조치 후 슬레이브 노드 복제와 관련됩니다. 매번 새 마스터 노드에 대한 복제 작업을 시작하는 슬레이브 노드 수를 지정합니다. . 예를 들어, 마스터 노드 전환이 완료된 후 3개의 슬레이브 노드가 새 마스터 노드로 복제를 시작하려고 한다고 가정합니다. parallel-syncs=1이면 슬레이브 노드가 하나씩 복제를 시작합니다. 3개의 슬레이브 노드 노드가 함께 복제를 시작합니다.

parallel-syncs 값이 클수록 슬레이브 노드가 복제를 완료하는 데 걸리는 시간이 빨라지지만, 네트워크 부하와 마스터 노드의 하드 디스크 부하에 대한 부담이 커지므로 실제 상황에 따라 설정해야 합니다. . 예를 들어, 마스터 노드의 로드가 낮고 슬레이브 노드의 서비스 가용성 요구 사항이 높은 경우에는 parallel-syncs 값을 적절하게 늘릴 수 있습니다. 병렬 동기화의 기본값은 1입니다.

(4) sentinel Failover-timeout {masterName} {time}

sentinel Failover-timeout은 Failover Timeout 판단과 관련이 있으나, 이 파라미터는 전체 Failover 단계의 Timeout을 판단하는 데 사용되지 않고 여러 하위 항목에 사용됩니다. -phases.Timeout, 예를 들어 마스터 노드가 슬레이브 노드로 승격되는 시간이 타임아웃을 초과하거나 슬레이브 노드가 새로운 마스터 노드로 복제 작업을 시작하는 시간(데이터 복사 시간 제외) 시간 초과를 초과하면 장애 조치 시간이 초과됩니다.

failover-timeout의 기본값은 180000이며, 이는 180초입니다. 시간이 초과되면 값은 다음 번에 원래 값의 두 배가 됩니다.

(5) 위의 매개변수 외에도 보안 검증과 관련된 매개변수 등 몇 가지 다른 매개변수가 있는데 여기서는 소개하지 않습니다.

2. 실용적인 제안

(1) 센티넬 노드의 수는 한편으로는 센티넬 노드의 중복성을 높이고 다른 한편으로는 센티넬 자체가 고가용성 병목 현상이 발생하는 것을 방지합니다. 오프라인에 대한 오판을 줄여줍니다. 또한 이러한 다양한 센티널 노드는 다양한 물리적 시스템에 배포되어야 합니다.

(2) 센티넬 노드의 수는 센티넬이 투표를 통해 "결정"(리더 선출에 대한 결정, 객관적인 오프라인에 대한 결정 등)을 쉽게 내릴 수 있도록 홀수여야 합니다.

(3) 하드웨어, 매개변수 등을 포함하여 각 센티넬 노드의 구성은 일관되어야 하며 모든 노드는 정확하고 일관된 시간을 보장하기 위해 ntp 또는 유사한 서비스를 사용해야 합니다.

(4) Sentinel의 구성 공급자 및 알림 클라이언트 기능을 구현하려면 위에서 언급한 Jedis와 같은 클라이언트 지원이 필요합니다. 개발자가 사용하는 라이브러리가 해당 지원을 제공하지 않는 경우 개발자가 직접 구현해야 할 수도 있습니다.

(5) Sentinel 시스템의 노드가 docker(또는 포트 매핑을 수행할 수 있는 다른 소프트웨어)에 배포되는 경우 포트 매핑으로 인해 Sentinel 시스템이 제대로 작동하지 않을 수 있다는 사실에 특별한 주의를 기울여야 합니다. Sentinel의 작업은 다른 노드와의 연결을 기반으로 하며 docker의 포트 매핑으로 인해 Sentinel이 다른 노드에 연결하지 못할 수 있습니다. 예를 들어 센티널이 외부에 선언한 IP와 포트에 따라 서로를 발견할 수 있으며, 센티넬 A가 포트 매핑을 사용하여 도커에 배포되면 다른 센티널은 A가 선언한 포트를 사용하여 A에 연결할 수 없습니다.

6. 요약

이 글에서는 먼저 Sentinel의 역할인 모니터링, 장애 조치, 구성 공급자 및 알림을 소개하고 Sentinel 시스템의 배포 방법과 클라이언트를 통해 Sentinel 시스템에 액세스하는 방법을 간략하게 설명합니다. 마지막으로 센티널 실행에 대한 몇 가지 제안이 제공됩니다.

마스터-슬레이브 복제를 기반으로 Sentinel은 마스터 노드의 자동 장애 조치를 도입하여 Redis의 고가용성을 더욱 향상시킵니다. 그러나 Sentinel의 결함도 분명합니다. Sentinel은 슬레이브 노드의 자동 장애 조치를 수행할 수 없으며 읽기 작업은 다음과 같습니다. 쓰기 분리 이 시나리오에서는 슬레이브 노드에 장애가 발생하면 읽기 서비스를 사용할 수 없게 되어 슬레이브 노드에서 추가 모니터링 및 전환 작업을 수행해야 합니다.

또한 Sentinel은 쓰기 작업의 로드 밸런싱이 불가능하고 저장 용량이 단일 시스템으로 제한되는 문제를 아직 해결하지 못했습니다. 이러한 문제를 해결하려면 클러스터를 사용해야 합니다. 이에 대해서는 이후 기사에서 소개하겠습니다. 관심을 가져 주셔서 감사합니다.

추천 학습: "Redis 비디오 튜토리얼", "2022 최신 Redis 인터뷰 질문 및 답변"

위 내용은 Redis 고급 학습 고가용성 센티널(요약 공유)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!