Redis 클러스터 솔루션(마스터-슬레이브 모드, Sentinel 모드, Redis 클러스터 모드)에 대한 심층적인 이해
- WBOY앞으로
- 2022-03-24 19:12:073706검색
이 글은 마스터-슬레이브 모드, 센티넬 모드, Redis 클러스터 모드와 관련된 문제를 주로 소개하는 Redis에 대한 관련 지식을 제공합니다.
추천 학습: Redis 튜토리얼
redis 클러스터 솔루션 소개(마스터-슬레이브 모드, 센티넬 모드, Redis 클러스터 모드)
1. 마스터-슬레이브 모드
데이터를 완전히 저장하는 주요 존재 단일 redis 두 가지 문제:
대량 데이터 볼륨으로 인한 데이터 백업 및 성능 저하.
Redis의 마스터-슬레이브 모드는 이 두 가지 문제에 대한 더 나은 솔루션을 제공합니다. 마스터-슬레이브 모드는 하나의 Redis 인스턴스를 호스트로 사용하고 나머지 인스턴스를 백업 머신으로 사용하는 것을 의미합니다.
호스트와 슬레이브의 데이터는 완전히 일치합니다. 호스트는 데이터 쓰기 및 읽기 등 다양한 작업을 지원하는 반면, 슬레이브는 호스트와의 데이터 동기화 및 읽기만 지원합니다. 즉, 클라이언트는 호스트에 데이터를 쓸 수 있습니다. , 호스트는 데이터 쓰기 작업을 슬레이브에 자동으로 동기화합니다.
마스터-슬레이브 모드는 데이터 백업 문제를 매우 잘 해결하며, 마스터-슬레이브 서비스 데이터가 거의 일관되기 때문에 데이터 쓰기 명령을 호스트로 보내 실행하고, 데이터 읽기 명령을 다른 슬레이브에 보낼 수 있습니다. 실행함으로써 읽기와 쓰기의 분리 목적을 달성합니다.
마스터-슬레이브 복제 작동 방식:
슬레이브 슬레이브 노드 서비스가 시작되어 마스터에 연결되면 적극적으로 SYNC 명령을 보냅니다. 동기화 명령을 받은 후 마스터 서비스 마스터 노드는 백그라운드 저장 프로세스를 시작하고 데이터 세트 수정을 위해 수신된 모든 명령을 수집합니다. 백그라운드 프로세스가 완료된 후 마스터는 전체 데이터베이스 파일을 슬레이브로 전송하여 전체 작업을 완료합니다. 동기화. 슬레이브 슬레이브 노드 서비스는 데이터베이스 파일 데이터를 수신한 후 메모리에 저장하고 로드합니다. 이후 마스터 노드는 수집된 모든 수정 명령과 새로운 수정 명령을 순차적으로 슬레이브에 계속 전송합니다. 이번에는 슬레이브가 이러한 데이터 수정 명령을 실행하여 최종 데이터 동기화를 달성합니다.
마스터와 슬레이브 간의 연결이 끊어지면 슬레이브는 연결이 성공한 후 자동으로 전체 동기화가 수행됩니다. 
배포:
redis 버전:6.0.9
1. Redis 구성 파일의 복사본 4개를 복사하고
이름을 master.conf로 지정합니다. 구성 파일 간단한 구성
마스터 노드의 구성 파일은 일반적으로 특별한 설정이 필요하지 않습니다. 기본 포트는 6379 슬레이브1 노드 포트 설정 6380이고, 그 다음 127.0.0.1 6379
슬레이브2 노드 포트 설정 6381 라인을 구성하고, 그런 다음 127.0.0.1 6379
슬레이브3 노드 포트 세트 6382의 복제본 라인을 구성하고 127.0.0.1 6379
3의 복제본 라인을 구성합니다. 각각 마스터 노드와 3개의 슬레이브 노드를 엽니다
redis-server master.conf
redis- serverslave1.conf redis-serverslave2.conf
redis-serverslave3 .conf
4. 클러스터 마스터-슬레이브 상태 확인
마스터-슬레이브 모드의 장점과 단점:
1. 장점:
동일한 마스터가 여러 슬레이브를 동기화할 수 있습니다.
마스터는 자동으로 데이터를 슬레이브에 동기화할 수 있으며, 읽기와 쓰기를 분리하여 마스터의 읽기 압력을 공유할 수 있습니다. 마스터와 슬레이브 간의 동기화는 동기화 기간 동안 비차단 방식으로 수행됩니다. 클라이언트는 여전히 쿼리를 제출하거나 요청을 업데이트할 수 있습니다.
자동 내결함성 및 복구 기능이 없습니다. 마스터 또는 슬레이브의 가동 중지 시간으로 인해 컴퓨터가 다시 시작될 때까지 기다려야 합니다. 또는 수동으로 클라이언트 IP를 전환하여 복구
마스터가 다운된 경우 데이터가 동기화되지 않으면 IP 전환 후 데이터 불일치 문제가 발생합니다. Redis의 용량이 제한되어 있습니다. 실제로 Redis의 마스터-슬레이브 모드는 매우 간단하여 실제 프로덕션 환경에서는 거의 사용되지 않습니다. 시스템의 고가용성을 제공하기 위해 실제 프로덕션 환경에서는 마스터-슬레이브 모드를 사용하는 것이 좋습니다. 권장되지 않는 이유는 데이터의 양이 매우 크거나 시스템의 고가용성이 요구되는 상황에서는 마스터-슬레이브 모드도 불안정하기 때문입니다. 이 모델은 매우 간단하지만 다른 모델의 기초가 되기 때문에 이 모델을 이해하면 다른 모델을 학습하는데 많은 도움이 될 것입니다.
2. Sentinel 모드(Sentinel)
Sentinel은 이름에서 알 수 있듯이 Redis 클러스터를 보호하기 위해 존재합니다. 문제가 발견되면 그에 따라 대응할 수 있습니다. 그 기능은 다음과 같습니다
마스터와 슬레이브가 정상적으로 실행되는지 모니터링
여러 센티널이 동일한 것을 모니터링할 수 있습니다. Redis 및 센티널도 자동으로 모니터링할 수 있습니다
슬레이브 및 기타 센티널 노드를 자동으로 검색한 후 센티널은 정기적으로 PING 명령을 보내 이러한 데이터베이스 및 노드가 서비스를 중지했는지 여부를 정기적으로 모니터링할 수 있습니다.
PING 데이터베이스 또는 노드가 시간 초과(밀리초 후 마스터 이름 밀리초 후 센티넬 다운을 통해 구성됨)하고 응답하지 않는 경우 Sentinel은 이를 주관적으로 오프라인으로 간주합니다(sdown, s는 주관적 - 주관적을 의미함). 마스터가 오프라인인 경우 센티널은 다른 센티널에게 명령을 보내 마스터도 주관적으로 오프라인이라고 생각하는지 묻습니다. 특정 투표 수(즉, 구성 파일의 쿼럼)에 도달하면 Sentinel은 마스터가 객관적으로 오프라인(odown)이라고 간주하고, 마스터-슬레이브 시스템에 대한 오류 복구를 시작하기 위해 선두 Sentinel 노드를 선택합니다. 마스터의 오프라인 상태에 동의할 만큼 센티널 프로세스가 충분하지 않은 경우 마스터의 객관적인 오프라인 상태가 제거됩니다. 마스터가 다시 센티넬 프로세스에 전송된 PING 명령에 대해 유효한 응답을 반환하면 마스터의 주관적인 오프라인 상태가 제거됩니다. .
센트리는 마스터가 객관적으로 오프라인 상태가 된 후 선출된 리더 센티넬이 오류 복구 작업을 수행해야 한다고 믿습니다.
리더가 선택된 후 리더는 시스템에서 오류 복구를 수행하기 시작하고 데이터베이스에서 하나를 선택합니다. 실패한 마스터의 새로운 마스터를 선출하기 위해,
성공해야 할 슬레이브를 선택한 후 선두 센티널은 데이터베이스에 이를 마스터로 업그레이드하라는 명령을 보낸 다음, 다른 슬레이브에게 새 마스터를 수락하라는 명령을 보내고, 드디어 데이터 업데이트. 중지된 기존 마스터를 새 마스터의 슬레이브 데이터베이스로 업데이트하여 서비스 복원 후에도 계속 슬레이브로 실행될 수 있도록 합니다. 
Sentinel 모드는 이전 마스터-슬레이브 복제 모드를 기반으로 합니다. sentinel의 구성 파일은 sentinel.conf입니다. 해당 디렉터리에 다음 구성을 추가합니다. 포트가 충돌하지 않도록 주의하세요.
port 26379 protected-mode no daemonize yes pidfile "/var/run/redis-sentinel-26379.pid" logfile "/data/redis/logs/sentinel_26379.log" dir "/data/redis/6379" sentinel monitor mymaster 127.0.0.1 6379 2 ##指定主机IP地址和端口，并且指定当有2台哨兵认为主机挂了，则对主机进行容灾切换 #sentinel auth-pass mymaster pwdtest@2019 ##当在Redis实例中开启了requirepass，这里就需要提供密码 sentinel down-after-milliseconds mymaster 3000 ##这里设置了主机多少秒无响应，则认为挂了 sentinel failover-timeout mymaster 180000 ##故障转移的超时时间，这里设置为三分钟
형식은 다음과 같습니다.
sentinel 상태 보기: 
3. redis 클러스터 모드(Cluster)
Cluster는 Centerless 구조를 채택하고 있으며 특징은 다음과 같습니다.
클라이언트가 Redis 노드에 직접 연결될 필요는 없습니다.
클러스터 모드의 특정 작동 메커니즘:
Redis의 각 노드에는 0-16383 값 범위의 슬롯이 있으며 총 16384개의 슬롯이 있습니다
키를 사용하면 Redis는 CRC16 알고리즘을 기반으로 결과를 얻은 다음 결과의 나머지 부분을 16384로 계산하여 각 키가 0-16383 사이의 해시 슬롯에 해당하도록 이 값을 통해 해당 노드를 찾습니다. 해당 슬롯으로 이동한 후 자동으로 이 액세스 작업이 해당 노드에서 수행됩니다.
고가용성을 보장하기 위해 클러스터 모드에는 마스터-슬레이브 복제 모드도 도입되었습니다. 하나의 마스터 노드는 하나 이상의 슬레이브 노드에 해당하며, 슬레이브 노드가 활성화됩니다.
다른 마스터 노드가 마스터 노드 A를 핑할 때 마스터 노드의 절반 이상이 A와 통신하는 시간이 초과되면 마스터 노드 A가 다운된 것으로 간주됩니다. 마스터 노드 A와 해당 슬레이브 노드가 다운되면 클러스터는 더 이상 서비스를 제공할 수 없습니다.
Redis 클러스터는 16384 슬롯에 해당하는 노드가 정상적으로 작동하는지 확인해야 합니다. 노드에 장애가 발생하면 해당 노드가 담당하는 슬롯도 무효화되어 전체 클러스터가 작동하지 않게 됩니다.
클러스터의 접근성을 높이기 위해 공식적으로 권장되는 솔루션은 노드를 마스터-슬레이브 구조, 즉 마스터 노드와 n개의 슬레이브 노드로 구성하는 것입니다. 이때, 마스터 노드에 장애가 발생하면 Redis 클러스터는 선출 알고리즘에 따라 슬레이브 노드 중 하나를 선택하여 마스터 노드로 승격하게 됩니다. Redis 클러스터 자체가 장애 조치를 제공하여 외부로 계속 서비스를 제공하게 됩니다. 내결함성.
클러스터 모드 클러스터 노드의 최소 구성은 6개 노드입니다(클러스터 선택 메커니즘 및 마스터-슬레이브 백업 구현에 따라 Redis는 Redis 클러스터를 형성하려면 총 3개 이상의 마스터와 3개의 슬레이브가 필요합니다. 다운되어 마스터-슬레이브 백업이 필요한지 여부), 마스터 노드는 읽기 및 쓰기 작업을 제공하고 슬레이브 노드는 백업 노드 역할을 하며 요청을 제공하지 않으며 장애 조치에만 사용됩니다. .
클러스터 클러스터 배포
클러스터 선택 메커니즘과 마스터-슬레이브 백업 구현에 따르면 Redis는 Redis 클러스터를 형성하기 위해 총 3개의 마스터와 3개의 슬레이브가 필요합니다. 테스트 환경은 하나의 물리적 시스템에서 6개의 Redis 노드를 시작할 수 있습니다. , 그러나 프로덕션 환경에서는 최소 2~3대의 물리적 머신을 준비해야 합니다. (여기서는 3개의 가상 머신이 사용됩니다.)
클러스터 모드는 Sentinel 모드를 기반으로 합니다. 데이터가 너무 커서 동적으로 확장해야 할 경우 처음 두 개는 특정 규칙에 따라 데이터를 조각화해야 합니다. Redis 데이터를 여러 머신에 배포합니다. 
该模式就支持动态扩容，可以在线增加或删除节点，而且客户端可以连接任何一个主节点进行读写，不过此时的从节点仅仅只是备份的作用。至于为何能做到动态扩容，主要是因为Redis集群没有使用一致性hash,而是使用的哈希槽。Redis集群会有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，而集群的每个节点负责一部分hash槽。
那么这样就很容易添加或者删除节点， 比如如果我想新添加个新节点， 我只需要从已有的节点中的部分槽到过来；如果我想移除某个节点，就只需要将该节点的槽移到其它节点上，然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。
需要注意的是，该模式下不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为。
搭建集群
这里就直接搭建较为复杂的Cluster模式集群，也是企业级开发过程中使用最多的。
1.建redis各节点目录
最终目录结构如下
2.逐个修改redis配置
以 9001 的为例子，其余五个类似。
编辑 /data/redis-cluster/9001/redis.conf
redis.conf修改如下:
port 9001（每个节点的端口号） daemonize yes appendonly yes //开启aof bind 0.0.0.0（绑定当前机器 IP） dir "/data/redis-cluster/9001"（数据文件存放位置,,自己加到最后一行 快捷键 shift+g） pidfile /var/run/redis_9001.pid（pid 9001和port要对应） logfile "/data/redis-cluster/logs/9001.log" cluster-enabled yes（启动集群模式） cluster-config-file nodes9001.conf（9001和port要对应） cluster-node-timeout 15000
3.逐个启动redis节点
/data/redis-cluster/bin/redis-server /data/redis-cluster/9001/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9002/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9003/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9004/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9005/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9006/redis.conf
现在检查一下是否成功开启，如下图所示，都开启成功。
ps -el | grep redis
4.集群配置
此时的节点虽然都启动成功了，但他们还不在一个集群里面，不能互相发现，测试会报错：(error) CLUSTERDOWN Hash slot not served。
如下图所示
redis-cli --cluster create 10.32.176.80:9001 10.32.176.80:9002 10.32.176.80:9003 10.32.176.80:9004 10.32.176.80:9005 10.32.176.80:9006 --cluster-replicas 1
–cluster-replicas 1 这个指的是从机的数量，表示我们希望为集群中的每个主节点创建一个从节点。
红色选框是给三个主节点分配的共16384个槽点。
黄色选框是主从节点的分配情况。
蓝色选框是各个节点的详情。
5.测试
现在通过客户端命令连接上，通过集群命令看一下状态和节点信息等
/data/redis-cluster/bin/redis-cli -c -h 10.32.176.80 -p 9001 cluster info cluster nodes
效果图如下，集群搭建成功。
现在往9001这个主节点写入一条信息，我们可以在9002这个主节点取到信息，集群间各个节点可以通信。
6.故障转移
故障转移机制详解
集群中的节点会向其它节点发送PING消息（该PING消息会带着当前集群和节点的信息），如果在规定时间内，没有收到对应的PONG消息，就把此节点标记为疑似下线。当被分配了slot槽位的主节点中有超过一半的节点都认为此节点疑似下线（就是其它节点以更高的频次，更频繁的与该节点PING-PONG），那么该节点就真的下线。其它节点收到某节点已经下线的广播后，把自己内部的集群维护信息也修改为该节点已事实下线。
节点资格审查：然后对从节点进行资格审查，每个从节点检查最后与主节点的断线时间，如果该值超过配置文件的设置，那么取消该从节点的资格。准备选举时间：这里使用了延迟触发机制，主要是给那些延迟低的更高的优先级，延迟低的让它提前参与被选举，延迟高的让它靠后参与被选举。（延迟的高低是依据之前与主节点的最后断线时间确定的）
선거 투표: 슬레이브 노드가 선거 자격을 얻으면 슬롯이 있는 다른 마스터 노드에 선거 요청을 시작하고 우선순위가 높은 슬레이브 노드일수록 마스터 노드가 될 가능성이 높아집니다. 슬레이브 노드 획득한 투표 수가 특정 값에 도달하면(예를 들어 클러스터에 N개의 마스터 노드가 있는 경우 하나의 슬레이브 노드가 N/2+1 표를 얻는 한 승자로 간주됩니다) 마스터 노드로 교체됩니다.
마스터 노드 교체: 선출된 슬레이브 노드는 슬레이브를 실행하여 슬레이브에서 마스터로 상태를 변경한 다음, ClusterDelSlot 작업을 실행하여 실패한 마스터 노드를 담당하는 슬롯을 취소하고, ClusterAddSlot을 실행하여 이러한 슬롯을 자신에게 할당합니다. , 그리고 현재 슬레이브 노드가 마스터 노드가 되었음을 클러스터의 모든 노드에 알리기 위해 자체 pong 메시지를 클러스터에 브로드캐스트합니다.
관련 작업 인수: 새로운 마스터 노드는 이전에 실패한 마스터 노드의 슬롯 정보를 인수하고, 자신의 슬롯과 관련된 명령 요청을 수신하고 처리합니다.
페일오버 테스트
이전 클러스터의 특정 노드의 상황을 다음과 같이 단순화해 보았습니다.
여기서 포트 9001 프로세스를 닫습니다. 이는 마스터 노드가 끊기는 것을 시뮬레이션하는 것입니다.
죽은 Redis 노드에 로그인하면 서비스가 거부됩니다. 아직 정상적으로 실행 중인 마스터 노드를 통해 진입한 후 클러스터의 정보를 다시 확인하세요
간단히 이전 클러스터 정보 아래와 같이 됩니다
이제 방금 끊은 마스터 노드를 재시작하고 클러스터 내부의 노드 상황을 다시 확인합니다. 구체적인 상황은 아래 그림과 같습니다
간단히 말하면 지금입니다. 노드 상황은 다음과 같습니다
추천 학습:Redis 튜토리얼
위 내용은 Redis 클러스터 솔루션(마스터-슬레이브 모드, Sentinel 모드, Redis 클러스터 모드)에 대한 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!