Redis의 독립형, 마스터-슬레이브, 센티넬 및 클러스터 모드를 빠르게 이해

이 문서에서는 Redis의 4가지 모드인 독립 실행형, 마스터-슬레이브, 센티널 및 클러스터를 안내합니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.

적은 코드, 더 많은 머리카락

입사 첫 주에 속았습니다

최근에 새로운 회사에 입사했어요. 원래는 회사에 익숙해질 줄 알았거든요. 저는 회사에 처음 입사했습니다. 그룹의 엔지니어링 문서를 살펴보고 스스로 연습할 수 있는 몇 가지 데모를 찾아보세요.

기침기침 기침, 전혀 예상하지 못한 일, 모든 것이 내가 생각한 대로, 나는 아직도 너무 부드럽다.

입사한 날 오후, 팀장님이 저에게 문서 몇 개를 던지며 이들 프로젝트의 캐싱 시스템 문제를 살펴보라고 하시고 Redis를 Sentinel 모드로 업그레이드 해달라고 하셨습니다.

미션을 받고 속으로는 혼란스러웠습니다.

먼저 어떤 서비스가 Redis를 사용하는지 모르겠습니다.

둘째, redis 사용법을 모릅니다.

셋째, redis가 중단되면 사용자에게 영향을 미치나요?

넷째, 저는 Redis를 전혀 사용해 본 적이 없습니다.

한 번도 해본 적이 없는데도 아직은 소심하지 않아요. 결국, 매일 전에 했던 것과 똑같은 일을 한다면, 뭔가 잘못된 것이 있고 빨리 최적화될 것입니다. 사회모집과 학교모집은 아직은 다른 것 같습니다. 학교모집에는 입문훈련이나 새내기수업이 있을 것 같습니다.

이런 형태의 교육을 통해 첫째, 회사의 문화와 가치를 이해하고, 둘째, 업무 프로세스를 배우고 회사의 기술적인 분위기를 느껴보세요.

우리 부서의 모든 Redis 서비스를

모드로 업그레이드하세요. [관련 추천사항: Redis 영상 튜토리얼]

는 모두 센티넬 모드로 업그레이드한다고 언급되어 있습니다. 이전에 사용했던 것은 센티넬 모드가 아니었을 것입니다.

단일 머신 모드

이것이 가장 간단하고 한 눈에 이해될 수 있습니다.

Redis를 설치하고 시작한 후 업체에 전화하면 됩니다. 구체적인 설치 단계와 시작 단계에 대해 자세히 설명하지 않고 온라인으로 검색해 보세요.

단일 머신은 고가용성이 반드시 보장되지 않는 상황과 같은 다양한 시나리오에서도 사용됩니다.

아흠, 저희 서비스는 실제로 redis 독립형 모드를 사용하고 있어서 센티넬 모드로 변경해보겠습니다.

단일 기계의

에 대해 이야기해 보겠습니다. 장점:

• 저렴한 비용, 예비 노드 없음, 기타 비용이 필요하지 않습니다.
• 고성능, 단일 기계는 데이터를 동기화할 필요가 없으며 데이터는 자연스럽게 일관됩니다.
• 단점:

• 단일 머신의 고성능은 CPU의 처리 능력에 의해 제한되며 Redis는 단일 스레드입니다.
• 독립형 모드의 선택은 귀하의 비즈니스 시나리오에 따라 이루어져야 합니다. 고성능과 안정성이 요구되는 경우 독립형 모드는 적합하지 않습니다.

마스터-슬레이브 복제는 하나의 Redis 서버에서 다른 Redis 서버로 데이터를 복사하는 것을 의미합니다.

전자를 마스터 노드(master), 후자를 슬레이브 노드(slave)라고 합니다. 데이터 복제는 단방향이며 마스터 노드에서 슬레이브 노드로만 가능합니다.

마스터-슬레이브 모드 구성은 매우 간단합니다. 슬레이브 노드에 마스터 노드의 IP와 포트 번호만 구성하면 됩니다.

slaveof <masterip> <masterport>
# 例如
# slaveof 192.168.1.214 6379</masterport></masterip>

노드의 모든 서비스를 시작하고 로그를 확인하여 master-slave노드 간의 서비스 연결을 확인하세요. 위에서 문제를 생각하기 쉽습니다. 마스터-슬레이브 복제는 마스터와 슬레이브의 데이터가 동일하다는 의미이므로 데이터 중복 문제가 있습니다.

프로그램 설계에서는 고가용성과 고성능을 위해 중복성을 허용합니다. 모든 사람이 시스템을 설계할 때 이 점을 고려하고 회사를 위해 이 리소스를 절약하지 않기를 바랍니다.

궁극의

을 추구하는 제품의 경우 다운타임은 절대 허용되지 않습니다. 마스터-슬레이브 모델은 많은 시스템 설계에서 고려됩니다. 마스터는 여러 슬레이브 노드에 매달려 있습니다. 마스터 서비스가 중단되면 서비스의 고가용성을 보장하기 위해 새로운 마스터 노드가

. 마스터-슬레이브 모델의 장점:

마스터 노드가 다운되면 마스터 노드의
• 백업

  인 슬레이브 노드가 언제든지 다시 돌아올 수 있습니다.

마스터노드의 읽기 압력을 공유하기 위해
• 마스터 노드

  의 읽기 기능을 확장합니다.

고가용성의 초석: 위의 기능 외에도 마스터-슬레이브 복제는 센티넬 모드 및 클러스터 모드 구현의 기초이기도 합니다. 따라서 마스터-슬레이브 복제는 Redis 고가용성의 초석입니다.

에는 방금 언급한 데이터 중복 문제와 같은 그에 상응하는 단점도 있습니다.

• 일단 마스터 노드가 다운되면, 슬레이브 노드가 마스터 노드로 승격되고 애플리케이션 측 동시에 수정해야 합니다 마스터 노드 주소 도 모든 슬레이브 노드 에 명령하여 새 마스터 노드를 복사 해야 합니다. 전체 프로세스에는 수동 개입 이 필요합니다.
• 마스터 노드의 쓰기 기능은 단일 머신에 의해 제한됩니다.
• 마스터 노드의 저장 용량은 단일 머신에 의해 제한됩니다.

센티넬 모드

앞서 언급한 마스터-슬레이브 모드는 마스터 노드가 다운되면 슬레이브 노드가 마스터 노드로 올라와 계속해서 서비스를 제공할 수 있는 모드입니다.

하지만 문제가 있습니다. 이때, 애플리케이션 서비스는 여전히 마스터 노드의 원본주소를 사용하여 접속합니다...

그래서 도입되었습니다. Redis 버전 2.8에는 센트리 개념이 있습니다.

Sentinel은 복제를 기반으로 자동실패 복구를 구현합니다.

그림에 표시된 것처럼 센티넬 노드는 센티넬 노드와 데이터 노드의 두 부분으로 구성됩니다.

• 센티넬 노드: 센티넬 시스템은 하나 이상의 센티널 노드로 구성됩니다. 데이터를 저장하지 않는 redis 노드.
• 데이터 노드: 마스터 노드와 슬레이브 노드는 모두 데이터 노드입니다.

redis 클러스터에 액세스하는 데이터는 sentinel 클러스터를 통해 이루어지며, sentinel은 전체 redis 클러스터를 모니터링합니다.

방금 언급한 마스터 노드가 중단되는 등 Redis 클러스터에 문제가 있음이 발견되면 슬레이브 노드가 올라옵니다. 하지만 마스터 노드 주소가 변경되면 애플리케이션 서비스는 이때 이를 인식하지 못하며, 센티넬이 애플리케이션 서비스와 상호 작용하기 때문에 액세스 주소를 변경할 필요가 없습니다.

Sentinel은 장애 조치 문제를 매우 잘 해결하고 고가용성 측면에서 새로운 차원으로 끌어 올렸습니다. 물론 Sentinel에는 다른 기능도 있습니다.

예를 들어 마스터 노드 생존 감지, 마스터-슬레이브 실행 상태 감지, 마스터-슬레이브 전환 등이 있습니다.

Redis용 Sentinel의 최소 구성은 마스터 1개와 슬레이브 1개입니다.

센티넬 모드 모니터링의 원리에 대해 이야기해 보겠습니다

각 Sentinel은 초당 1회의 빈도로 모든 마스터 서버, 슬레이브 서버 및 기타 Sentinel인스턴스에 PING 명령을 보냅니다.

PING 명령에 대한 마지막 유효한 응답 이후의 시간이 down-after-milliseconds에 지정된 값을 초과하는 경우 이 인스턴스는 Sentinel에 의해

으로 표시됩니다.

가 주관적으로 오프라인으로 표시된 경우, 이 메인 서버를 모니터링하는 모든 Sentinel 노드는 메인 서버가 실제로 초당 1회의 빈도로 주관적으로 오프라인에 진입했는지 여부를 확인해야 합니다. 상태. 마스터 서버가 주관적으로 오프라인으로 표시되고

의 센티널(적어도 구성 파일에 지정된 수)이 지정된 시간 범위 내에서 이 판단에 동의하면 마스터 서버는 다음으로 표시됩니다. 오프라인 목표. 일반적인 상황에서 각 Sentinel은 10초마다 한 번씩 자신이 알고 있는 모든 마스터 서버와 슬레이브 서버에 INFO 명령을 보냅니다.

가 Sentinel에 의해 객관적으로 오프라인으로 표시되면 Sentinel이 오프라인 마스터 서버의 모든 슬레이브 서버에 INFO 명령을 보내는 빈도가 10초에 한 번에서 초당 한 번으로 변경됩니다. Sentinel은

의 상태를 다른 Sentinel과 협상합니다. 마스터 노드가 SDOWN`상태인 경우 투표를 통해 자동으로 새 마스터 노드가 선택됩니다. 데이터 복제를 위해 나머지 슬레이브 노드를 새 마스터 노드로 지정하세요. 메인 서버가 오프라인 상태가 되는 데 동의할 만큼 센티넬이 충분하지 않은 경우, 메인 서버의

가 제거됩니다. 메인 서버가 Sentinel의 PING 명령에 대해 유효한 응답을 반환하면 메인 서버의 주관적인 오프라인 상태가 제거됩니다.

장점:

• 마스터와 슬레이브를 자동으로 전환할 수 있어 시스템이 더욱 견고해지고 유용해집니다.
• Sentinel은 마스터 서버와 슬레이브 서버가 정상적으로 실행되고 있는지 지속적으로 확인합니다. 모니터링되는 Redis 서버에 문제가 발생하면 Sentinel은 API 스크립트를 통해 관리자나 다른 애플리케이션에 알림을 보냅니다.
• 단점:

• Redis较难支持在线扩容，对于集群，容量达到上限时在线扩容会变得很复杂。

我的任务

我部署的redis服务就如上图所示，三个哨兵节点，三个主从复制节点。

使用java的jedis去访问我的redis服务，下面来一段简单的演示代码(并非工程里面的代码)：

public static void testSentinel() throws Exception {
     //mastername从配置中获取或者环境变量，这里为了演示
         String masterName = "master";
         Set<String> sentinels = new HashSet<>();
     // sentinel的IP一般会从配置文件获取或者环境变量，这里为了演示
         sentinels.add("192.168.200,213:26379");
         sentinels.add("192.168.200.214:26380");
         sentinels.add("192.168.200.215:26381");
 
     //初始化过程做了很多工作
         JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); 
     //获取到redis的client
         Jedis jedis = pool.getResource();
     //写值到redis
         jedis.set("key1", "value1");
     //读取数据
     jedis.get("key1");
}

具体部署的配置文件这里太长了，需要的朋友可以公众号后台回复【redis配置】获取。

听起来是入职第二天就部署了任务感觉很难的样子。

其实现在看来是个so easy的任务，申请一个redis集群，自己配置下。在把工程里面使用到redis的地方改一下，之前使用的是一个两个单机节点。

干完，收工。

虽然领导的任务完成了，但并不意味着学习redis的路结束了。爱学习的龙叔，继续研究了下redis的集群模式。

集群模式

主从不能解决故障自动恢复问题，哨兵已经可以解决故障自动恢复了，那到底为啥还要集群模式呢？

主从和哨兵都还有另外一些问题没有解决，单个节点的存储能力是有上限，访问能力是有上限的。

Redis Cluster 集群模式具有 高可用、可扩展性、分布式、容错 等特性。

Cluster 集群模式的原理

通过数据分片的方式来进行数据共享问题，同时提供数据复制和故障转移功能。

之前的两种模式数据都是在一个节点上的，单个节点存储是存在上限的。集群模式就是把数据进行分片存储，当一个分片数据达到上限的时候，就分成多个分片。

数据分片怎么分？

集群的键空间被分割为16384个slots（即hash槽），通过hash的方式将数据分到不同的分片上的。

HASH_SLOT = CRC16(key) & 16384 复制代码

CRC16是一种循环校验算法，这里不是我们研究的重点，有兴趣可以看看。

这里用了位运算得到取模结果，位运算的速度高于取模运算。

有一个很重要的问题，为什么是分割为16384个槽？这个问题可能会被面试官随口一问

数据分片之后怎么查，怎么写？

读请求分配给slave节点，写请求分配给master，数据同步从master到slave节点。

读写分离提高并发能力，增加高性能。

如何做到水平扩展？

master节点可以做扩充，数据迁移redis内部自动完成。

当你新增一个master节点，需要做数据迁移，redis服务不需要下线。

举个栗子：上面的有三个master节点，意味着redis的槽被分为三个段，假设三段分别是0~7000，7001~12000、12001~16383。

现在因为业务需要新增了一个master节点，四个节点共同占有16384个槽。

槽需要重新分配，数据也需要重新迁移，但是服务不需要下线。

redis集群的重新分片由redis内部的管理软件redis-trib负责执行。redis提供了进行重新分片的所有命令，redis-trib通过向节点发送命令来进行重新分片。

如何做故障转移？

假如途中红色的节点故障了，此时master3下面的从节点会通过 选举 产生一个主节点。替换原来的故障节点。

此过程和哨兵模式的故障转移是一样的。

总结

每种模式都有各自的优缺点，在实际使用场景中要根据业务特点去选择合适的模式。

redis是一个非常常用的中间件，作为一个使用者来说，学习成本一点不高。

如果作为一个很好的中间件去研究的话，还是有很多值得学习和借鉴的地方。比如redis的各种数据结构(动态字符串、跳跃表、集合、字典等)、高效的内存分配(jemalloc)、高效的IO模型等等。

모든 사항을 심층적으로 연구하여 이후의 동시성 및 고가용성 시스템 설계에 통합할 수 있습니다.

더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 비디오를 방문하세요! !

위 내용은 Redis의 독립형, 마스터-슬레이브, 센티넬 및 클러스터 모드를 빠르게 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!