Redis 마스터-슬레이브 기술 사례 분석

Redis 복제

프로덕션 환경에서 Redis는 지속성 기능(RDB 및 AOF 기술)을 사용하여 서버가 다시 시작되더라도 데이터가 손실되지 않도록(또는 약간의 손실) 보장합니다. 그러나 데이터는 서버에 저장되므로 이 서버에 하드 디스크 오류(프로덕션 환경에서 여러 번 발생)와 같은 문제가 있는 경우 단일 오류 지점을 피하기 위해 일반적인 접근 방식은 다음과 같습니다. 데이터베이스를 복사하려면 여러 개의 복사본을 서로 다른 서버에 배포할 수 있으므로 한 서버에 장애가 발생하더라도 다른 서버가 최대한 빠르게 서비스를 제공할 수 있습니다. 이를 위해 Redis는 한 데이터베이스의 데이터가 업데이트되면 업데이트된 데이터를 다른 데이터베이스에 자동으로 동기화할 수 있는 복제 기능을 제공합니다.

데이터베이스의 복제 개념은 마스터 데이터베이스와 슬레이브 데이터베이스의 두 가지 범주로 나눌 수 있습니다. 슬레이브 데이터베이스는 마스터 데이터베이스에서 쓰기 작업이 발생하고 데이터가 변경될 때 자동으로 데이터를 동기화합니다. 슬레이브 데이터베이스는 일반적으로 읽기 전용이며 마스터 데이터베이스에서 동기화된 데이터를 받아들입니다. 마스터 데이터베이스에는 여러 개의 슬레이브 데이터베이스가 있을 수 있습니다.

Redis 복제는 간단하고 사용하기 쉬우며 구성을 통해 슬레이브 Redis 서버 또는 마스터 서버를 복제할 수 있습니다. 다음으로 Redis 복제에 대한 몇 가지 매우 중요한 기능이 있습니다.

마스터는 여러 슬레이브를 가질 수 있습니다.

슬레이브는 동일한 마스터에 속한 슬레이브의 링크를 수락하는 것 외에도 동일한 구조 다이어그램에 있는 다른 슬레이브의 링크를 수락할 수도 있습니다.

Redis 복제는 마스터 세그먼트에서 비차단입니다. 즉, 동일한 슬레이브 또는 여러 슬레이브에서 동기화를 수행하는 동안 마스터가 쿼리를 계속 수락할 수 있음을 의미합니다.

복제는 슬레이브 측에서도 비차단입니다. redis.conf에서 redis 기능을 구성한다고 가정하면 슬레이브가 새로운 동기화를 수행할 때 여전히 이전 데이터 정보를 사용하여 쿼리를 제공할 수 있습니다. Redis 슬레이브가 마스터와의 연결이 끊어지면 슬레이브는 클라이언트 오류를 ​​보냅니다.

읽기 전용 쿼리를 수행할 수 있는 여러 슬레이브를 갖기 위해 복제는 2번 또는 여러 번 반복될 수 있으며 이는 확장 가능합니다(예: 슬레이브 대화 및 반복 정렬 작업, 여러 복사본을 갖는 것은 비교적 간단합니다) 데이터 중복성).

복제를 통해 마스터의 전체 하드 디스크 쓰기 소비를 피할 수 있습니다. 마스터의 구성 파일 redis.conf를 "저장 방지"(모든 "저장" 명령 주석 처리)로 구성한 다음 데이터 유지를 위해 슬레이브에 연결하기만 하면 됩니다. . 하지만 마스터가 자동으로 다시 시작되지 않도록 해야 합니다(자세한 내용은 아래 참조)

Redis 복제 구성

Redis에서 복제 기능을 사용하는 것은 매우 쉽습니다. "마스터 데이터 복제 마스터 데이터베이스 포트의 슬레이브"만 추가하면 됩니다. 슬레이브 데이터베이스의 구성 파일에 있습니다.

기본 데이터베이스에는 구성이 필요하지 않습니다. 먼저 가장 단순화된 복제 시스템을 살펴보겠습니다. 하나의 서버에서 두 개의 Redis 예제를 시작하여 서로 다른 포트에서 수신 대기합니다. 그 중 하나는 마스터 데이터베이스 역할을 하고 다른 하나는 슬레이브 데이터베이스 역할을 합니다.

먼저 매개변수를 추가하지 않고 Redis 인스턴스를 마스터 데이터베이스로 시작합니다.

$ redis-server --port 6379 &

인스턴스는 기본적으로 포트 6379를 수신한 다음, Slaveof 매개변수를 추가하여 슬레이브 데이터베이스로 다른 Redis 인스턴스를 시작하고 포트를 수신하도록 합니다. 6380:

$ redis-server --port 6380 --slaveof 127.0.0.1 6379 &

인스턴스의 시작 상태를 확인하세요:

$ ps aux | grep redis
root      2886  0.0  0.0  38652  4448 pts/0    Sl   16:57   0:00 redis-server *:6379
root      2889  0.0  0.0  36604  4368 pts/0    Sl   16:57   0:00 redis-server *:6380

이때 마스터 데이터베이스의 모든 데이터 변경 사항은 자동으로 슬레이브 데이터베이스에 동기화됩니다. redis-cli 인스턴스 A를 열고 데이터베이스에 연결합니다.

$ redis-cli -p 6379

redis-cli 인스턴스 B를 다시 열고 슬레이브 데이터베이스에 연결합니다:

$ redis-cli -p 6380

이때 INFO 명령을 사용하여 인스턴스 A와 인스턴스 B 각각에서 복제 관련 정보를 얻습니다.

127.0.0.1:6379> INfo replication# Replicationrole:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=266,lag=1
master_repl_offset:266
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:265

인스턴스 A의 역할은 메인 데이터베이스인 master이고, 연결된 슬레이브 데이터베이스(connectd_slaves)의 개수가 1개임을 알 수 있습니다.

인스턴스 B에서도 얻은 응답 정보는 다음과 같습니다.

127.0.0.1:6380> INfo replication# Replicationrole:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:378
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

인스턴스 B의 역할은 슬레이브, 즉 슬레이브 데이터베이스임을 알 수 있으며, 메인 데이터베이스의 주소는 127.0.0.1이고 포트는 6379.

그런 다음 인스턴스 A에서 SET 명령을 사용하여 키 값을 설정합니다.

127.0.0.1:6379> set foo bar
OK

이때 값은 인스턴스 B에서 얻을 수 있습니다.

127.0.0.1:6380> get foo"bar"

두 Redis 인스턴스의 복제 기능이 이미 있음을 증명합니다. 사용 가능. 기본적으로 슬레이브 데이터베이스는 읽기 전용입니다. 슬레이브 데이터베이스의 데이터를 직접 수정하면 다음과 같은 오류가 발생합니다.

127.0.0.1:6380> set foo hey
(error) READONLY You can't write against a read only slave.

그러나 의 구성 파일에서 Slave-read-only=no를 설정할 수도 있습니다. 슬레이브 데이터베이스를 사용하여 슬레이브 데이터베이스를 쓰기 가능하게 만들지만, 슬레이브 데이터베이스에 대한 변경 사항은 다른 데이터베이스와 동기화되지 않으며 일단 마스터 데이터베이스에서 승리한 데이터가 업데이트되면 슬레이브 데이터베이스의 변경 사항을 덮어쓰게 됩니다. 잠재적으로 간과되는 애플리케이션 논리 오류를 방지하려면 슬레이브 데이터베이스를 쓰기 가능하게 설정해서는 안 됩니다.

여러 슬레이브 데이터베이스를 구성하는 데에도 동일한 방법이 사용됩니다. 동일한 마스터 데이터베이스를 가리키도록 모든 슬레이브 데이터베이스의 구성 파일에 salveof 매개변수를 추가하기만 하면 됩니다. 구성 파일이나 명령줄 매개변수를 통해 Slaveof 매개변수를 설정하는 것 외에도, Slaveof 명령을 사용하여 런타임에 다른 인스턴스 C(6381)를 추가해 보겠습니다.

$ redis-server --port 6381 &
$ redis-cli -p 6381
127.0.0.1:6381> slaveof 127.0.0.1 6379
127.0.0.1:6381> get foo"bar"

如果该数据库已经是其他主数据库的从数据库了，slaveof命令会停止和原来数据库的同步转而和新数据库同步，此外对于从数据库来说，还可以使用slaveof no one命令来使当前数据库停止接收其他数据库的同步并转换成为主数据库。如下测试，在从库实例C上写入数据时时不允许的，然后使用slaveof no one将此数据库转换为主数据库，然后再写入数据就没有问题了。一般用于但主节点挂掉的时候，立刻把从节点切换为主节点提供数据操作服务。

127.0.0.1:6381> set foo bar
(error) READONLY You can't write against a read only slave.
127.0.0.1:6381> SLAVEOF no one
5493:M 07 Aug 17:23:06.792 # Connection with master lost.
5493:M 07 Aug 17:23:06.792 * Caching the disconnected master state.
5493:M 07 Aug 17:23:06.792 * Discarding previously cached master state.
5493:M 07 Aug 17:23:06.792 * MASTER MODE enabled (user request from 'id=2 addr=127.0.0.1:40825 fd=6 name= age=348 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')
2886:M 07 Aug 17:23:06.792 # Connection with slave 127.0.0.1:6381 lost.
OK
127.0.0.1:6381> set foo bar
OK

复制常用参数

slaveof

将当前server做为slave，并为其指定master信息。

masterauth

以认证的方式连接到master，如果master中使用了”密码保护”，slave必须交付正确的授权密码，才能连接成功。”requirepas”配置项指定了当前server的密码。此配置项中值需要和master机器的”requirepas”保持一致。此参数配置在slave端。

slave-serve-stale-data yes

如果当前server是slave，那么当slave与master失去通讯时，是否继续为客户端提供服务，”yes”表示继续,”no”表示终止。如果在“yes”的情况下，从节点继续向客户端提供只读服务，数据有可能是过期的。在”no”情况下，任何向此server发送的数据请求服务(包括客户端和此server的slave)都将被告知”error”。

slave-read-only yes

slave是否为”只读”，强烈建议为”yes”。

repl-ping-slave-period 10

slave向指定的master发送ping消息的时间间隔(秒)，默认为10。

repl-timeout 60

slave与master通讯中，最大空闲时间，默认60秒，超时将导致连接关闭。

repl-disable-tcp-nodelay no

slave与master的连接，是否禁用TCP nodelay选项。”yes”表示禁用，那么socket通讯中数据将会以packet方式发送(packet大小受到socket buffer限制)，可以提高socket通讯的效率(tcp交互次数)，但是小数据将会被buffer，不会被立即发送，对于接受者可能存在延迟。”no”表示开启tcp nodelay选项，任何数据都会被立即发送，及时性较好，但是效率较低。建议为”no”。

slave-priority 100

适用Sentinel模块(unstable,M-S集群管理和监控)，需要额外的配置文件支持。slave的权重值，默认100。当master失效后，Sentinel将会从slave列表中找到权重值最低(>0)的slave，并提升为master。如果权重值为0，表示此slave为”观察者”，不参与master选举。

了解Redis的复制原理

了解Redis复制的原理有助于运维Redis过程中的规划节点和处理节点故障等问题。下面介绍Redis实现复制的工程。

当一个从数据库启动后，会向主数据库发送SYNC命令，同时主数据库接收到SYNC命令后会开始在后台保存快照（即RDB持久化的过程），并将保存快照期间接收到的命令缓存起来，当快照完成后，Redis Master会将快照文件发送给从数据库，从数据库收到后，会载入快照文件。之后Redis Master会以Redis命令协议的格式，将写命令缓冲区中积累的所有内容都发送给从服务器。以上过程称为复制初始化，复制初始化结束后，主数据库每当收到写命令时就会将命令同步给从数据库，从而保证主从数据库数据一致。

你可以通过telnet命令来亲自验证这个同步过程：首先连上一个正在处理命令请求的Redis服务器，然后向它发送SYNC命令，过一阵子，你将会看到telnet会话接收到服务器发来的大段数据（.rdb文件），之后还会看到，所有的服务器执行过的写命令，都会重新发送到telnet会话来。

当主从数据库之间的连接断开重连后，Redis 2.6以及之前的版本会重新进行复制初始化（即主数据库重新保存快照并传送给从数据库），即使从数据库可以仅有几条命令没有收到，主数据库也必须要将数据库里的所有数据重新传送给从数据库。这使得主从数据库断线重连后的数据恢复过程效率很低下，在网络环境不好的时候这一问题尤其明显，Redis 2.8版本的一个重要改进就是断线重连能够支持有条件的增量数据传输，当从数据库重新连接上主数据库后，主数据库只需要将断线期间执行的命令传送给从数据库，从而大大提高Redis复制的实用性。

增量复制的实现，基于以下3点：

1）从数据库会存储主数据库的运行ID（run id），每个Redis运行实例均会拥有一个唯一的运行ID，每当实例重启后，就会自动生成一个新的运行ID。

2）在复制同步阶段，主数据库每将一个命令传送给从数据库时，都会同时把该命令存放到一个积压队列（backlog）中，并记录下当前积压队列中存放的命令的偏移量范围。

3）同时，从数据库接收到主数据库传来的命令时，会记录下该命令的偏移量。

这三点是实现增量复制的基础，当主从连接准备就绪后，从数据库会发送一条SYNC命令来告诉主数据库可以开始把所有数据同步过来了。而2.8版本之后，不再发送SYNC命令，取而代之的是发送PSYNC，格式为“PSYNC 主数据库的运行ID 断开前最新的命令偏移量”。收到PSYNC命令的主数据库将执行以下检查来确定是否可以进行增量复制。

1）首先主数据库会判断从数据库传送来的运行ID是否和自己的运行ID相同，这一步骤的意义在于确保从数据库之前确实是和自己同步的，以免从数据库拿到错误的数据（如主数据库在断连期间重启过，会造成数据的不一致性）。

2）然后判断从数据库最后同步成功的命令偏移量是否在积压队列中，如果在则可以执行增量复制，并将积压队列中相应的命令发送给从数据库。

如果此次重连不满足增量复制的条件，主数据会进行一次全部同步（即与Redis 2.6的过程相同），大部分情况下，增量复制的过程对开发者来说是完全透明的，开发者不需要关心增量复制的具体细节，2.8版本的主数据库也可以正常地和旧版本的从数据库同步（通过接收SYNC命令），同样2.8版本的从数据库也可以与旧版本的主数据库同步（通过发送SYNC命令），唯一需要开发者设置的就是积压队列的大小了。

积压队列在本质上是一个固定长度的循环队列，默认情况下积压队列的大小为1MB，可以通过配置文件的repl-backlog-size选项来调整。随着积压队列的增大，主从数据库断线的可容忍时间也随之延长，这是比较容易理解的。根据主从数据库之间的网络状态，设置一个合理的积压队列很重要。因为积压队列存储的内容是命令本身，如 SET FOO BAR，所以估算积压队列的大小只需要估计主从数据库断线的时间中主从数据库可能执行的命令的大小即可。与积压队列相关的另一个配置选项是repl-backlog-ttl，即当所有主从数据库与主数据断开连接后，经过多久时间可以释放积压队列的内存空间，默认时间是1小时。

从数据库持久化

另一个相对耗时的操作是持久化，为了提高性能，可以通过复制功能建立一个或多个从数据库，并在从数据库中启用持久化，同时在主数据库禁用持久化，当从数据库崩溃重启后主数据库会自动将时间同步过来，所以无需担心数据丢失。

然后当主数据库崩溃时，情况就稍显复杂了。手工通过从数据库数据恢复主数据库数据时，需要严格按照以下两步进行：

1）在从数据库中使用SLAVEOF NO ONE命令将从数据库提升为主数据库继续服务。

2）启动之前崩溃的主数据库，然后使用SLAVEOF命令将其设置成新的主数据库的从数据库，即可将数据同步回来。

注意，当开启复制且主数据库关闭持久化的时候，一定不要使用supervisor以及类似的进程管理工具令主数据库崩溃后自动重启。同样当主数据库所在的服务器因故关闭时，也要避免直接重新启动。这是因为当主数据库重新启动后，因为没开持久化功能，所以数据库中所有数据都被清空，这时从数据库依然会从主数据库中接收数据，使得所有从数据库也被清空，导致从数据库的持久化失去意义。

无论哪种情况，手工维护从数据库或主数据的重启以及数据恢复都相对麻烦，好在Redis提供了一种自动化方案哨兵来实现这一过程，避免了手工维护的麻烦和容易出错的问题。

无硬盘复制

上面介绍了Redis复制的工作原理时介绍了复制是基于RDB方式的持久化实现的，即主数据库端在后台保存了RDB快照，从数据库端则接收并载入快照文件，这样的实现有点是可以显著地简化逻辑，复用已有的代码，但是缺点也很明显。

1）当主数据库禁用RDB快照时（即删除了所有的配置文件中的save语句），如果执行了复制初始化操作，Redis依然会生成RDB快照，所以下次启动后主数据库会以该快照恢复数据。恢复的数据可能对应于任何时间点，因为无法确定复制发生的确切时间。

这个过程会对性能产生影响，因为复制初始化需要在硬盘中生成RDB快照文件，如果硬盘性能较慢。举例来说，当使用Redis做缓存系统时，因为不需要持久化，所以服务器的硬盘读写速度可能较差。但是当该缓存系统使用一主多从的集群架构时，每次和从数据库同步，Redis都会执行一次快照，同时对硬盘进行读写，导致性能下降。

因此从2.8.18版本开始，Redis引入了无硬盘复制选项，开启该选项时，Redis在与从数据库进行复制初始化时将不会将快照内容存储到硬盘上，而是直接通过网络发送给从数据库，避免了硬盘的性能瓶颈。可以在配置文件中使用如下配置来开启该功能：

repl-diskless-sync yes

PS：当需要把Slave转换为Master时可以使用”SLAVEOF ON ONE”指令。

위 내용은 Redis 마스터-슬레이브 기술 사례 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!