Redis 고가용성 솔루션에 대한 자세한 그래픽 설명

Redis 클러스터 이해 및 구축

일부 개발자는 애플리케이션에서만 Redis를 사용합니다. 예를 들어 데이터 결과를 캐시하는 데 사용됩니다. 그리고 이제는 redis 명령에 주의를 기울이지 않고도 기본적으로 상당한 수의 기능을 완료할 수 있는 좋은 redis 클라이언트 도구(redisson)가 많이 있습니다. 따라서 다음 사항에 대한 관심이 부족할 수 있습니다.

재해 복구 방법은 무엇입니까? 즉, 특정 Redis 노드에 문제가 있는 경우 서비스의 고가용성을 어떻게 보장할 수 있을까요?

어떻게 수평적으로 확장할 수 있을까요? 데이터 양이 특히 많은 경우 단일 redis의 성능 문제를 해결하는 방법

클러스터에는 최소한 몇 대의 머신이 필요합니까? 아니면 여러 개의 redis 노드

클러스터를 구축하는 데 어떤 기술과 도구가 사용됩니까?

재해 복구를 제공하는 방법은 무엇입니까?

Redis는 마스터-슬레이브 핫 스탠바이 메커니즘을 제공합니다. 마스터 서버의 데이터는 슬레이브 서버에 동기화되며 마스터 서버의 상태는 Sentry를 통해 실시간으로 모니터링되며 선택을 담당합니다. 마스터 서버. 메인 서버에 이상이 발견되면 특정 알고리즘에 따라 메인 서버를 재선출하여 문제가 발생한 서버를 사용 가능 목록에서 제거한 후 최종적으로 클라이언트에 통보합니다. 마스터-슬레이브는 아래와 같이 일대다 트리 구조입니다. ##🎜🎜 #Sentinel은 sentinel의 중국어 이름입니다. redis에서 개발한 고가용성 아키텍처 도구로, 동시에 하나 이상의 Redis 클러스터를 모니터링할 수 있습니다.

Sentinel Cluster

고가용성 고려 사항에 따라 Sentinel 자체도 클러스터를 지원해야 합니다. 단일 문제가 됩니다.

Sentinel Decision

Sentinel은 특정 마스터 서비스를 동시에 사용할 수 없다고 생각하는 수량 구성이 있을 때, 예를 들어 마스터-슬레이브 전환이 수행됩니다. 예를 들어 센티널은 총 5개입니다. 3개의 센티널이 서비스를 사용할 수 없다고 판단하면 마스터와 슬레이브 간 전환을 결정합니다. 이를 통해 일부 잘못된 전환을 방지하고 순간적인 네트워크 이상과 같은 전환 비용을 줄일 수 있습니다.

가로로 확장하는 방법은 무엇인가요?

Redis든 다른 데이터베이스 제품이든 단일 노드의 데이터 용량이 일정 상한선에 도달하면 외부 세계에 서비스를 제공하는 능력은 점점 약해집니다. . Redis는 클러스터 기능을 구현하기 위해 상위 버전에서 redis-trib.rb를 제공하며 타사 도구 twemproxy를 사용할 수도 있습니다.

탈중앙화, 모든 노드는 동일함

Redis 클러스터는 중앙화를 염두에 두고 설계되지 않았으므로 중앙 노드를 피할 수 있습니다. 단일 지점 및 기타 노드 문제. 각 노드는 전체 클러스터의 상태를 파악할 수 있으며, 여기에 연결된 모든 노드는 단일 노드 Redis와 마찬가지로 모든 키에 액세스할 수 있습니다.

클러스터 개략도

제가 이해한 대로 그렸습니다. 오해가 있는 경우 지적해 주세요.

키와 Redis 노드의 관계

이해할 수 있는 hasy solt를 소개합니다. 해시 슬롯으로 중국어로. 우리가 작동하는 키는 총 16384개입니다. 모듈로 알고리즘을 사용하여 키가 어느 슬롯에 있는지 확인합니다.

HASH_SLOT = CRC16(key) mod 16384

해시 슬롯과 노드 사이에는 일정한 관계가 있으므로 특정 Redis 노드에 키를 할당할 수 있습니다.

자세한 관계를 다시 연구할 수 있습니다. 예를 들어 노드 A는 0~5000번 해시 슬롯을 담당하고, 노드 B는 5001~1000

#🎜🎜 #Step by step Build

3개의 마스터와 3개의 슬레이브로 클러스터 구축을 시작합니다. 시스템은 ubuntu이고 redis에서 제공하는 클러스터 도구 redis-trib.rb를 사용합니다.

최신 redis 설치

redis_cluster 디렉터리를 생성하고 7000~7005 디렉터리 6개 생성

redis 디렉터리의 redis.conf를 다음 위치에 복사 위에 생성된 6개의 디렉토리 중

分别修改redis.conf文件,对6个文件做类似的修改。

port  7000                                       //端口7000       
bind  127.0.0.1                                  //默认ip为127.0.0.1 需要改为其他节点机器可访问的ip
daemonize    yes                                 //后台运行
pidfile  /var/run/redis_7000.pid                 //pidfile文件对应7000
cluster-enabled  yes                             //开启集群
cluster-config-file  nodes_7000.conf             //集群的配置
cluster-node-timeout  15000                      //请求超时  默认15秒，可自行设置

bind需要注意的就是需要配置为其它机器可以访问的ip，否则无论是创建集群还是客户端连接都会有问题。

启动6个redis

redis-server redis_cluster/7000/redis.conf
redis-server redis_cluster/7001/redis.conf
redis-server redis_cluster/7002/redis.conf
redis-server redis_cluster/7003/redis.conf
redis-server redis_cluster/7004/redis.conf
redis-server redis_cluster/7005/redis.conf

创建集群
redis的src目录下有个redis-trib.rb，将它复制到/usr/local/bin中，然后执行如下脚本：

redis-trib.rb  create  --replicas  1  127.0.0.1:7000 127.0.0.1:7001  127.0.0.1:7002 127.0.0.1:7003  127.0.0.1:7004  127.0.0.1:7005

--replicas后面的1代表从服务器的个数，上面可以理解为前面3个为主服务器，后面三个分别做为从服务器，即三对主从。

执行过程中会遇到提示需要安装ruby，安装完成之后又会提示安装 gem redis。

安装gem redis，折腾了好久，最终发现是因为在国内访问不了某些网站导致通过apt-get install安装不成功，最后通过下载源码的方式安装成功。

再次执行创建集群的脚本,出现如下提示：

输入yes，继续

最少需要多少个主服务器？

可能是基于某些约定，集群约定只有当可用节点数大于半数以上时才具备对外提供服务的能力。首先数量一定是奇数，其实必须大于1，所以最少的主服务器数量为3。

测试集群
连接客户端，由于我的所有节点都是在本地，所以不需要输入ip，但需要加-c的参数。redis-cli -c -p 7000

连接成功后，增加一个key

set mykey 123

有一行提示语，指向到端口7002，这说明虽然我们连接的是7000的实例，但通过hash算法最终会将key分配到7002的实例上。

再连接7005端口查询下key，测试下是否任意一个实例都可以查询到key

get mykey

显示指向到端口7002

更多redis知识请关注redis数据库教程栏目。

위 내용은 Redis 고가용성 솔루션에 대한 자세한 그래픽 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!