이 문서에서는 Redis의 4가지 모드인 독립 실행형, 마스터-슬레이브, 센티널 및 클러스터를 안내합니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.
적은 코드, 더 많은 머리카락
최근에 새로운 회사에 입사했어요. 원래는 회사에 익숙해질 줄 알았거든요. 저는 회사에 처음 입사했습니다. 그룹의 엔지니어링 문서를 살펴보고 스스로 연습할 수 있는 몇 가지 데모를 찾아보세요.
기침기침 기침, 전혀 예상하지 못한 일, 모든 것이 내가 생각한 대로, 나는 아직도 너무 부드럽다.
입사한 날 오후, 팀장님이 저에게 문서 몇 개를 던지며 이들 프로젝트의 캐싱 시스템 문제를 살펴보라고 하시고 Redis를 Sentinel 모드로 업그레이드 해달라고 하셨습니다.
미션을 받고 속으로는 혼란스러웠습니다.
먼저 어떤 서비스가 Redis를 사용하는지 모르겠습니다.
둘째, redis 사용법을 모릅니다.
셋째, redis가 중단되면 사용자에게 영향을 미치나요?
넷째, 저는 Redis를 전혀 사용해 본 적이 없습니다.
한 번도 해본 적이 없는데도 아직은 소심하지 않아요. 결국, 매일 전에 했던 것과 똑같은 일을 한다면, 뭔가 잘못된 것이 있고 빨리 최적화될 것입니다. 사회모집과 학교모집은 아직은 다른 것 같습니다. 학교모집에는 입문훈련이나 새내기수업이 있을 것 같습니다.
이런 형태의 교육을 통해 첫째, 회사의 문화와 가치를 이해하고, 둘째, 업무 프로세스를 배우고 회사의 기술적인 분위기를 느껴보세요.
Task모드로 업그레이드하세요. [관련 추천사항: Redis 영상 튜토리얼]
Redis의 다중 모드단일 머신 모드
Redis를 설치하고 시작한 후 업체에 전화하면 됩니다. 구체적인 설치 단계와 시작 단계에 대해 자세히 설명하지 않고 온라인으로 검색해 보세요.
단일 머신은 고가용성이 반드시 보장되지 않는 상황과 같은 다양한 시나리오에서도 사용됩니다.
아흠, 저희 서비스는 실제로 redis 독립형 모드를 사용하고 있어서 센티넬 모드로 변경해보겠습니다.
단일 기계의
장점과 단점에 대해 이야기해 보겠습니다. 장점:
배포가 쉽고 비용이 들지 않습니다.전자를 마스터 노드(master), 후자를 슬레이브 노드(slave)라고 합니다. 데이터 복제는 단방향이며 마스터 노드에서 슬레이브 노드로만 가능합니다.
slaveof <masterip> <masterport> # 例如 # slaveof 192.168.1.214 6379</masterport></masterip>
master-slave
노드의 모든 서비스를 시작하고 로그를 확인하여 master-slave노드 간의 서비스 연결을 확인하세요. 위에서 문제를 생각하기 쉽습니다. 마스터-슬레이브 복제는 마스터와 슬레이브의 데이터가 동일하다는 의미이므로 데이터 중복 문제가 있습니다.
프로그램 설계에서는 고가용성과 고성능을 위해 중복성을 허용합니다. 모든 사람이 시스템을 설계할 때 이 점을 고려하고 회사를 위해 이 리소스를 절약하지 않기를 바랍니다.
궁극의
사용자 경험을 추구하는 제품의 경우 다운타임은 절대 허용되지 않습니다. 마스터-슬레이브 모델은 많은 시스템 설계에서 고려됩니다. 마스터는 여러 슬레이브 노드에 매달려 있습니다. 마스터 서비스가 중단되면 서비스의 고가용성을 보장하기 위해 새로운 마스터 노드가
선택됩니다. 마스터-슬레이브 모델의 장점:
인 슬레이브 노드가 언제든지 다시 돌아올 수 있습니다.
의 읽기 기능을 확장합니다.
에는 방금 언급한 데이터 중복 문제와 같은 그에 상응하는 단점도 있습니다.
앞서 언급한 마스터-슬레이브 모드는 마스터 노드가 다운되면 슬레이브 노드가 마스터 노드로 올라와 계속해서 서비스를 제공할 수 있는 모드입니다.
하지만 문제가 있습니다. 이때, 애플리케이션 서비스는 여전히 마스터 노드의 원본주소를 사용하여 접속합니다...
그래서 도입되었습니다. Redis 버전 2.8에는 센트리 개념이 있습니다.
Sentinel은 복제를 기반으로 자동실패 복구를 구현합니다.
그림에 표시된 것처럼 센티넬 노드는 센티넬 노드와 데이터 노드의 두 부분으로 구성됩니다.
redis 클러스터에 액세스하는 데이터는 sentinel 클러스터를 통해 이루어지며, sentinel은 전체 redis 클러스터를 모니터링합니다.
방금 언급한 마스터 노드가 중단되는 등 Redis 클러스터에 문제가 있음이 발견되면 슬레이브 노드가 올라옵니다. 하지만 마스터 노드 주소가 변경되면 애플리케이션 서비스는 이때 이를 인식하지 못하며, 센티넬이 애플리케이션 서비스와 상호 작용하기 때문에 액세스 주소를 변경할 필요가 없습니다.
Sentinel은 장애 조치 문제를 매우 잘 해결하고 고가용성 측면에서 새로운 차원으로 끌어 올렸습니다. 물론 Sentinel에는 다른 기능도 있습니다.
예를 들어 마스터 노드 생존 감지, 마스터-슬레이브 실행 상태 감지, 마스터-슬레이브 전환 등이 있습니다.
Redis용 Sentinel의 최소 구성은 마스터 1개와 슬레이브 1개입니다.
각 Sentinel은 초당 1회의 빈도로 모든 마스터 서버, 슬레이브 서버 및 기타 Sentinel인스턴스에 PING 명령을 보냅니다.
으로 표시됩니다.
메인 서버가 주관적으로 오프라인으로 표시된 경우, 이 메인 서버를 모니터링하는 모든 Sentinel 노드는 메인 서버가 실제로 초당 1회의 빈도로 주관적으로 오프라인에 진입했는지 여부를 확인해야 합니다. 상태. 마스터 서버가 주관적으로 오프라인으로 표시되고
충분한 수의 센티널(적어도 구성 파일에 지정된 수)이 지정된 시간 범위 내에서 이 판단에 동의하면 마스터 서버는 다음으로 표시됩니다. 오프라인 목표. 일반적인 상황에서 각 Sentinel은 10초마다 한 번씩 자신이 알고 있는 모든 마스터 서버와 슬레이브 서버에 INFO 명령을 보냅니다.
마스터 서버
가 Sentinel에 의해 객관적으로 오프라인으로 표시되면 Sentinel이 오프라인 마스터 서버의 모든 슬레이브 서버에 INFO 명령을 보내는 빈도가 10초에 한 번에서 초당 한 번으로 변경됩니다. Sentinel은
마스터 노드의 상태를 다른 Sentinel과 협상합니다. 마스터 노드가 SDOWN`상태인 경우 투표를 통해 자동으로 새 마스터 노드가 선택됩니다. 데이터 복제를 위해 나머지 슬레이브 노드를 새 마스터 노드로 지정하세요. 메인 서버가 오프라인 상태가 되는 데 동의할 만큼 센티넬이 충분하지 않은 경우, 메인 서버의
객관적인 오프라인 상태가 제거됩니다. 메인 서버가 Sentinel의 PING 명령에 대해 유효한 응답을 반환하면 메인 서버의 주관적인 오프라인 상태가 제거됩니다.
센티넬 모드의 장점과 단점我部署的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 集群模式具有 高可用、可扩展性、分布式、容错 等特性。
通过数据分片的方式来进行数据共享问题，同时提供数据复制和故障转移功能。
之前的两种模式数据都是在一个节点上的，单个节点存储是存在上限的。集群模式就是把数据进行分片存储，当一个分片数据达到上限的时候，就分成多个分片。
集群的键空间被分割为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 중국어 웹사이트의 기타 관련 기사를 참조하세요!
