Redis 5.x——主从复制（二）

3、Redis复制的注意事项

3.1、复制的注意事项

1. Redis主从节点默认使用异步复制，从节点和主节点之间以异步方式确认处理的数据量。
2. 一个主节点可以有多个从节点。
3. 从节点可以接受其他从节点的连接。除了多个从节点可以连接到同一个主节点之外，从节点之间也可以以层叠状的结构(cascading-like structure)连接到其他从节点。自Redis 4.0起，所有子从节点(sub-slave)将会从主节点收到完全一样的复制流。
4. Redis复制在主节点一侧是非阻塞式的，这意味着主节点在一个或多个从节点进行初次同步或者是部分重新同步时可以继续处理查询请求。
5. 复制在从节点一侧大部分也是非阻塞式的。当从节点进行初次同步时，它可以使用旧数据集处理查询请求，假设我们在redis.conf中配置了让Redis这样做。如果复制流断开了，Redis从节点会返回一个错误给客户端导致客户端抛出异常。在初次同步之后，旧数据集必须被删除，同时加载新的数据集。从节点在这个短暂的时间窗口内（如果数据集很大，就会持续较长时间）会阻塞持续到来的连接请求。自Redis 4.0开始，可以配置Redis使之在另一个不同的线程中执行删除旧数据集的操作，但是加载新数据集的操作依然需要在主线程中进行并且会阻塞从节点。
6. 复制以可伸缩性方式来实现，以便只读查询可以有多个从节点（例如O(N)复杂度的慢操作可以被下放到从节点去执行）​，或者指定的从节点仅用于数据安全（备份作用）​。
7. 可以使用复制来避免主节点一次性将全部数据集写入磁盘而造成系统短时的巨大开销：一种典型的技术是配置主节点的Redis.conf以避免主节点对磁盘执行持久化操作，然后连接一个从节点，将其配置为不定期保存或是启用AOF。但是，这个设置必须小心处理，因为重新启动的主节点的程序将从一个空数据集开始：如果一个从节点试图与它同步，那么这个从节点的数据集也会被清空。

3.2、复制的安全性

在设置Redis复制功能时，强烈建议在主节点和从节点中启用持久化。当不可能启用持久化时（例如由于非常慢的磁盘性能而导致的延迟问题）​，就应该通过配置文件来避免主节点被重置后自动重启。为了更好地理解为什么关闭了持久化并配置了自动重启的主节点是危险的，检查以下故障模式，这些故障模式中的数据会从主节点和所有从节点中被删除掉：

1. 我们把节点A设置为主节点并关闭了它的持久化设置，节点B和C从主节点A复制数据。
2. 当节点A崩溃，但是它有一些自动重启的系统可以重启进程。由于持久化被关闭了，节点重启后其数据集合为空。
3. 节点B和节点C会从主节点A复制数据，但是主节点A的数据集是空的，因此复制的结果是它们会销毁自身之前的数据副本。

任何时候数据安全性都是很重要的，所以如果主节点使用复制功能的同时未配置持久化，那么自动重启进程这项设置应该被禁用。

3.3、无须磁盘参与的复制

正常情况下，一个全量重新同步要求在磁盘上创建一个RDB文件，然后将它从磁盘加载到内存中，然后从节点以此进行数据同步。如果磁盘性能很低，那么对主节点是一个压力很大的操作。Redis 2.8.18是第一个支持无磁盘复制的版本。在此设置中，子进程直接发送RDB文件给从节点，无须使用磁盘作为中间存储介质。相关配置如下：

// 主节点在内存中直接创建RDB文件，然后发送给从节点，不会在自己的本地磁盘“落地”了
// 参数配置
// 是否无磁盘
repl-diskless-sync no
// 主节点发送RDB文件给从节点，等待一定时长再开始复制，因为要等更多从节点重新连接到主节点，这样就可以更好地利用资源提升性能
repl-diskless-sync-delay 5s

3.4、只读性质的从节点

在Redis 2.6之后，从节点支持只读模式且默认开启。redis.conf文件中的slave-read-only变量用来控制这个功能的开启，可以在运行时使用config set命令来随时开启或者关闭这个功能。

只读模式下的从节点将会拒绝所有写入命令，因此实践中不可能由于某种错误而将数据写入从节点。这并不意味着该特性旨在将一个从节点实例暴露到Internet，或者说将之暴露在不可信的客户端网络中，因为debug或者config这样的管理员命令仍在启用。不过，在redis.conf文件中使用rename-command命令可以禁用上述管理员命令以提高只读实例的安全性。

读到这里，也许有读者想知道为什么可以还原只读设置并可以通过写入操作来设置从节点实例。如果从节点与主节点在同步或者从节点在重启，那么这些写操作将会无效，但是将短暂数据存储在可写的从节点(writable slave)中还是有一些合理用例的。比如，执行slow Set或者Sorted Set的操作并将它们存储在本地键(key)中，就是多次要使用可写的从节点(writable slave)的用例。

Redis 4.0 RC3及更高版本彻底解决了这个问题，现在可写的从节点能够像主节点一样驱逐设置过生存时间值的键，不过DB编号大于63（默认情况下，Redis实例只有16个数据库）的键除外。

另请注意，Redis 4.0的可写从节点(writable slaves)仅能在本地使用，并且不会将数据传播到与该实例相连的子从节点(sub-slave)上，子从节点将总是接收与最顶层主节点向中间从节点(intermediate slaves)发送的复制流相同的复制流。例如，在设置节点A→节点B→节点C中，即使节点B是可写的，节点C也不会看到节点B的写入，但还是拥有与主节点实例A相同的数据集。

3.5、主从多种模式下的问题

3.5.1、一主一从

一主一从是最基础的主从复制模型，主节点负责处理写请求，从节点负责处理读请求，将读写分离以提升性能。一主一从架构图如图所示。

3.5.2、一主多从

一个主节点可以有多个从节点，但每个从节点只能有一个主节点。一主多从适用于写少读多的应用场景，多个从节点可以分担读请求的负载以提升并发性。一主多从架构图如图所示。

3.5.3、树状主从

上面的一主多从可以实现读请求的负载均衡，当从节点数量多的时候，主节点的同步压力是线性提升的，因此可以使用树状主从来分担主节点的同步压力。树状主从架构图如图所示。

上面三种主从架构在很大程度上都提升了性能，但是也面临了一个很大的问题，因为从节点的数据是由主节点写入之后推送过来的，如果主从复制出现长时间的延时就会造成从节点很多数据的不一致。在Redis 2.8版本之前我们是无法解决这一问题的，在Redis 2.8版本之后这一问题可以得到控制。

3.5.4、主从复制超时后控制写命令

从Redis 2.8开始，只有当至少有N个从节点连接到主节点时才有可能配置Redis主节点接受写命令。由于Redis使用异步复制，因此无法确保从节点是否实际接收到指定的写命令，因此总会有一个数据丢失窗口。

该特性的工作原理如下：

• Redis从节点每秒钟都会ping主节点，确认已处理的复制流的数量。
• Redis主节点会记得上一次从每个从节点收到ping的时间。
• 用户可以配置一个最小的从节点数量，使得它们的滞后小于等于最大秒数。

如果至少有N个从节点，并且滞后小于M秒，那么写命令将被接受。可能有读者认为这是一个尽力而为的数据安全机制，对于指定的写命令来说不能保证数据的一致性，但是至少数据丢失的时间窗限制在指定的秒数内。如果条件不满足，主节点将会回复一个错误同时不接受写命令。

这个特性有如下两个配置参数：

min-slaves-to-write <slave 数量>
min-slaves-max-lag <秒数>

比如min-slaves-to-write和min-slaves-max-lag分别是6和10，含义是如果从节点数量小于6个或所有从节点的延迟值都大于10秒，则主节点拒绝执行写命令并给客户端返回错误。

3.5.5、Redis复制处理键的过期

Redis的过期机制可以限制键的生存时间。此功能取决于Redis实例计算时间的能力，即使使用Lua脚本更改了这些键，Redis从节点也能正确地复制具有过期时间的键。

Redis不能通过主从节点使用同步时钟来实现这样的功能，因为无法解决数据不一致的问题并且会导致竞态条件（race condition，又称为资源竞争）​，所以Redis使用以下三种主要技术使过期的键的复制能够正确工作：

• 从节点不会让键过期，而是等待主节点让键过期。当一个主节点让一个键到期（或由于LRU算法将之驱逐）时，它会合成一个del命令并传输到所有的从节点。
• 由于这是主节点驱动的键过期行为，如果主节点无法及时提供del命令，那么从节点的内存中仍然可能存在逻辑上已经过期的键。为了处理这个问题，从节点使用它的逻辑时钟来保证只有在不违反数据集一致性的读取操作中才存在键。采用这种方法，从节点避免逻辑过期的键仍然存在的可能。
• 在Lua脚本执行期间，不执行任何键过期操作。当一个Lua脚本运行时，从概念上讲，主节点中的时间是被冻结的，这样在脚本运行的时候，一个给定的键要么存在要么不存在。这可以防止键在脚本运行中间过期，保证将相同的脚本发送到从节点，从而确保主从节点的数据集是一致的。

一旦一个从节点被提升为一个主节点，就将开始独立地让键过期，而不需要任何它曾经的主节点帮忙。

4、搭建主从节点的实例

搭建主从节点可以通过两种方式：一种是通过命令行方式，一种是通过配置文件方式。下面我们将实现两种不同方式的主从模式。

4.1、以命令行方式搭建主从节点

需要执行如下命令：

// 启动Redis实例myredis1为主节点
docker run  -d -p 6379:6379 --name myredis1 redis
// 如果启动需要挂载配置文件，则可以执行下面的命令，把宿主机的配置文件挂载到容器中
#docker run -v /myredis/conf:/usr/local/etc/redis --name myredis1 redis
redis-server /usr/local/etc/redis/redis.conf
// 启动Redis实例myredis2为主节点
docker run  -d -p 6380:6379 --name myredis2 redis
// 启动Redis实例myredis3为主节点
docker run  -d -p 6381:6379 --name myredis3 redis
// 进入myredis2从节点容器
docker exec -it myredis2 /bin/bash
// 客户端连接
redis-cli
// 执行脚本，让myredis1作为自己的主节点
slaveof  192.168.3.214 6379
// 进入myredis3从节点容器
docker exec -it myredis3 /bin/bash
// 客户端连接
redis-cli
// 执行脚本，让myredis1作为自己的主节点
slaveof  192.168.3.214 6379
// 进入myredis1主节点容器
docker exec -it myredis1 /bin/bash
// 客户端连接
redis-cli
// 验证数据是否同步
set name clay
// 查看主从信息
info replication

主节点搭建的过程如图所示，从中可以看到主节点的详细信息。

第一个从节点搭建的过程如图所示，启动了第一个从节点，并建立了主从关系。

第二个从节点搭建的过程如图所示，启动第二个从节点，并建立了主从关系。

由上面的几个图可以看到主从节点的信息，通过inforeplication命令可以查看主从结构的详细信息：主节点执 行该命令，可以看到自己的角色是主节点(master)而且拥有两个从节点；myredis2和myredis3实例执行该命令，可以看到各自都是从节点(slave)，还可以看到主节点的IP和端口号。

在主节点写入信息后，在两个从节点也可以查询到写入主节点的信息，如图所示。

当两个从节点都可以查询到主节点写入键的值时，表示此主从架构的主从同步没有问题。

4.2、以配置文件方式搭建主从节点

相关配置文件如下：

# 在从节点配置文件中添加下面的两个配置项即可指定成为某个主节点的从节点
# slaveof 主节点地址 主节点端口
slaveof  host port
# 从服务器只读
slave-read-only yes

下面将在Windows 10系统上利用不同端口号来示范搭建主从架构的过程。首先启动三个实例，端口号为6379的实例为主节点，端口号为6380和6381的为从节点。

6380端口实例的配置文件修改如下：

port 6380
slaveof 127.0.0.1 6379

6381端口实例的配置文件修改如下：

port 6381
slaveof 127.0.0.1 6379

文件目录如图所示，从中可以看到各个实例的配置文件的名称及文件保存的位置。

1)依次启动6379主节点、6380从节点和6381从节点，结果如图所示。

2)依次使用redis-cli.exe连接到6379、6380、6381各个实例，然后执行info replication命令来查看主从节点的信息。

以上是登录主节点查询到的主从信息，从中可以看到6380和6381这两个从节点，如图所示。

下图所示是两个从节点查询到的主从节点信息，从中可以看到主节点的信息以及主从节点各自的数据同步信息。

从下图可以看出主从数据复制没有问题，而且从节点默认不能进行写操作。从中可以看到修改了6380实例的配置文件中slave-read-only的参数值(slave-read-onlyno)。

6380可以进行写操作，但会造成主从数据不一致，如图所示。

非特殊业务不需要修改此配置参数。主从节点的日志信息如图所示，从中可以看出数据连接和数据全量复制的相关操作信息。

4.3、以身份验证模式搭建主从架构

在Windows 10系统上利用不同端口号的实例（代表不同身份）来搭建主从架构。首先开启三个实例：端口号为6379的实例为主节点，端口号为6380和6381的实例为从节点。

主节点（端口号为6379的实例）的配置文件修改如下：

// 主节点开启身份验证模式
requirepass master123456

从节点（端口号为6380的实例）的配置文件修改如下：

// 设置端口号
port 6380
// 主节点信息
slaveof 127.0.0.1 6379
// 主节点的密码
masterauth master123456

从节点（端口号为6381端口的实例）的配置文件修改如下：

// 设置端口号
port 6381
// 主节点信息
slaveof 127.0.0.1 6379
// 主节点的密码
masterauth master123456

按照前面的方式启动节点实例，然后登录主节点（简称6379实例）​，查看主从信息，结果如图所示。

从图可以看出主从架构搭建成功。需要注意的是，主节点设置了密码认证，登录的时候需要通过-a传递密码。如果从节点配置的主节点密码不正确，那么查看主从信息时主节点连接会被断开，结果如图所示。

从输出日志信息（见图）可以看出，主从在不断地尝试重新建立主从节点之间的连接。

5、主从架构的“坑”和优化技巧

5.1、复制超时问题

主从节点复制超时是导致复制中断的重要原因之一。在复制连接建立过程中及之后，主从节点都有机制判断连接是否超时，作用如下：

1. 如果主节点判断连接超时，就会释放相应从节点的连接，从而释放各种资源，否则无效的从节点仍会占用主节点的各种资源（输出缓冲区、带宽、连接等）​。此外，连接超时的判断可以让主节点更准确地知道当前有效从节点的个数，有助于保证数据安全。
2. 如果从节点判断连接超时，则可以及时重新建立连接，避免与主节点数据长期不一致。

知道以上两个作用之后，下面对一些在实际业务中需要注意的问题进行说明：

• 在数据同步阶段，也就是主从节点进行全量复制（执行bgsave命令）时，主节点首先需要复刻(fork)一个子进程，然后将当前数据保存到RDB文件中，再将RDB文件通过网络传输到从节点。如果RDB文件过大，主节点在复刻子进程和保存RDB文件时耗时过多，就可能导致从节点长时间收不到数据而触发超时，此时从节点会重连主节点，然后再次全量复制，再次超时，这样会进入一个无限循环。为了避免这种情况的发生，除了需要注意Redis单机数据量不要过大之外，另一方面就是适当增大repl-timeout值，具体的时间值可以根据bgsave执行的耗时来做一些调整。
• 在命令传播阶段主节点会向从节点发送ping命令，频率由repl-ping-slave-period控制，该参数应该要小于repl-timeout值。如果两个参数相等或接近，因为网络抖动导致个别ping命令丢失，恰巧主节点没有向从节点发送数据，那么从节点很容易判断超时。
• 如果主节点或从节点执行了一些慢查询，如keys*等大数据查询命令而导致服务器阻塞，阻塞期间无法响应复制连接中对方节点的请求，就可能导致复制超时，所以要慎重使用这些慢查询命令。

5.2、主从架构数据应用问题

在主从复制基础上实现的读写分离可以实现Redis的读负载均衡：由主节点提供写服务，由一个或多个从节点提供读服务。利用多个从节点既可以提高数据冗余程度，还可以最大化读负载的能力。在读数据负载较大的应用场景下，可以大大提高Redis服务器的并发量。在读写分离时，我们需要注意以下几个问题。

5.2.1、数据延迟与不一致问题

主从复制的命令传播是异步的，因此数据的延迟与数据的不一致是不可避免的。如果应用对数据不一致的接受程度较低，则需要优化主从节点之间的网络环境。通过监控主从节点的偏移量来延迟判断，如果从节点延迟过大，就要通知应用不再通过该从节点读取数据，使用集群同时扩展写负载和读负载等。

在命令传播阶段以外的其他情况下，从节点数据不一致的情况可能更加严重，比如连接发生在数据同步阶段或从节点失去与主节点的连接时等。可以通过设置从节点的slave-serve-stale-data参数来控制这种情况下从节点的表现。如果为yes（默认值）​，就表示从节点仍可以响应客户端的命令；如果为no，那么从节点只能响应info、slaveof等少数命令。如果对数据一致性要求很高，就应设置为no。

5.2.2、数据过期问题

在单机版Redis中，存在如下的两种删除策略：

• 惰性删除：服务器不会主动删除数据，只有当客户端查询某个数据时服务器才判断该数据是否过期，如果过期就删除相应的数据。
• 定期删除：服务器定时执行删除过期数据的任务，但是考虑到内存和CPU的性能，该删除任务执行的频率和时间都受到了限制。

在主从架构场景下，为了主从节点的数据一致性，从节点不会主动删除数据，而是由主节点控制从节点中过期数据的删除。因为主节点的惰性删除和定期删除策略都不能保证主节点及时对从节点中的过期数据执行了删除操作，所以当客户端通过Redis从节点读取数据时很容易读取到已经过期的数据。不过在Redis 3.2之后的版本，从节点在读取数据时增加了对数据是否过期的判断：如果该数据已过期，就不会把这些数据返回给客户端。

5.2.3、故障切换问题

在没有使用哨兵(sentinel)模式的读写分离应用场景中，应用针对读和写分别连接不同的Redis节点。当主节点或从节点出现问题而发生更改时，需要及时修改应用程序读写Redis数据的连接。连接的切换需要手动进行，或者编写监控程序进行自动切换，但是前者响应慢、容易出错，后者实现复杂，因此可以根据自己的应用情况选择不同的方式去处理。

5.3、主从复制中断问题

主从节点超时是复制中断的原因之一，除此之外，还有其他情况可能导致复制中断，其中最主要的是复制缓冲区溢出问题。

在全量复制阶段，主节点会将执行的写命令放到复制缓冲区中，而该缓冲区存放的数据包括了以下几个主节点内执行的写命令。

1. bgsave生成RDB文件、RDB文件由主节点发往从节点、从节点清空旧数据并载入RDB文件中数据。
2. 当主节点数据量较大或者主从节点之间网络延迟较大时，可能会导致该缓冲区的大小超过限制，此时主节点会断开与从节点之间的连接。这种情况可能引发全量复制而导致复制缓冲区溢出，最终造成连接中断，然后进行重新连接，再次进行全量复制，重新连接、全量复制，复制缓冲区溢出导致连接中断，……，不断地循环往复。

需要关注的是，复制缓冲区（复制缓冲区是客户端输出缓冲区的一种，主节点会为每一个从节点分别分配复制缓冲区。复制积压缓冲区则是一个主节点只有一个，无论它有多少个从节点）的大小由client-output-buffer-limit slave{hard limit}{soft limit}{soft seconds}配置，默认值为client-output-buffer-limit slave 256MB64MB 60，其含义是：如果在复制期间内存缓冲区持续60秒超过64MB，或者一次性超过256MB，那么停止复制，复制失败，主从节点进入重连状态。该参数可以通过config set命令来动态配置（不重启Redis也可以生效）​，如果用户是由于这一原因造成主从复制中断，则可以相应地调整此参数。

5.4、主从复制应用中的优化技巧

在我们了解Redis主从复制的种种细节之后，再来看看在实际应用中需要注意的问题。

1. 第一次建立复制连接时全量复制不可避免，但仍有几点 需要注意。如果主节点的数据量较大，用户应该尽量避开网络流量的高峰期，避免造成阻塞。如果有多个从节点需要建立对主节点的复制连接，则可以考虑将几个从节点的复制错开，避免主节点带宽占用过大。如果从节点过多，用户也可以调整主从复制的拓扑结构，由一主多从结构变为树状结构（参考第7.3.6节的内容）​。不过使用树状结构应该特别注意这些问题，虽然树状结构中因主节点的直接从节点减少了而降低了主节点的负担，但是树状结构中因具有多层从节点而使延迟增大，数据一致性将变得更差。另外树状结构复杂，维护起来相当麻烦。
2. 主节点宕机重启后，runid会发生变化，因此不能进行部分复制，只能全量复制。实际上在主节点宕机的情况下我们应进行故障转移处理，将其中的一个从节点升级为主节点，其他从节点转而从新的主节点进行复制。故障转移应尽量自动化，有需要的话可以搭建Redis哨兵模式
3. 在一些应用场景下，可能希望重启主节点，比如主节点内存碎片率过高，或者希望调整一些只能在启动时生效的参数。如果使用普通的手段重启主节点，就会使得runid发生变化，导致不必要的全量复制。为了解决这个问题，Redis提供了debug reload的重启方式：重启后，主节点的runid和offset都不受影响，避免了全量复制。不过，这种方式会清空当前内存中的数据，重新从RDB文件中加载，易导致主节点的阻塞，因此也需要谨慎操作。

通过debug reload方式重启主节点之后run_id没有发生改变，如图所示。

4. 从节点重启后会丢失其保存的主节点的runid，即使再次执行slaveof也无法进行部分复制，因此在非特殊情况下尽量不要重启。
5. 网络问题：如果时间极为短暂，只造成了短暂的丢包，主从节点都没有判定超时（未触发repl-timeout）​，那么此时只需要通过replconf ack命令来补充丢失的数据即可。如果网络问题时间很长，主从节点判断超时（触发了repl-timeout）​，且丢失的数据过多，超过了复制积压缓冲区所能存储的范围，那么主从节点将无法进行部分复制，只能进行全量复制。为了尽可能避免这种情况发生，应该根据实际情况适当调整复制积压缓冲区的大小以及判断超时的参数（减少全量复制）​。

5.5、主从架构重要配置总结

• slaveof<masterip><masterport>: slaveof主节点的IP主节点的端口号。Redis启动时起作用，作用是建立复制关系，开启了该配置的Redis服务器在启动后成为从节点。
• repl-timeout 60与各个阶段主从节点连接超时判断有关。此例的设置表示超过60秒为超时。
• repl-diskless-sync no作用于全量复制阶段，控制主节点是否使用无盘(diskless)复制。所谓无盘复制，是指在全量复制时主节点不再是把数据写入RDB文件，而是直接写入从节点的socket中，整个过程中不涉及硬盘。无盘复制在磁盘IO很慢而网速很快时更有优势，这个配置项默认是关闭的。
• repl-diskless-sync-delay 5该配置作用于全量复制阶段，当主节点使用无盘复制时，该配置决定主节点向从节点发送之前停顿的时间，单位是秒；只有当无盘复制启用时有效，默认为5秒。之所以设置停顿时间，是基于两个考虑：一是向从节点的socket传输一旦开始，新连接的从节点只能等待当前数据传输结束才能进行新的数据传输；二是多个从节点有较大的概率在短时间内建立主从复制。
• client-output-buffer-limit slave 256MB 64MB 60与全量复制阶段主节点的缓冲区大小有关，如果在复制期间内存缓冲区持续消耗超过64MB或者一次性超过256MB，就会停止复制，造成复制失败，主从就要重新建立连接。
• repl-disable-tcp-nodelay no与命令传播阶段的延迟有关，默认为关闭。
  • 关闭：无论数据大小都会及时同步到从节点，消耗带宽，适用于主从网络稳定的应用场景。
  • 开启：主节点每隔指定的时间就把数据合并为TCP包，节省带宽，默认为40毫秒同步一次，适用于网络环境复杂或带宽紧张的应用场景，如跨机房。
• masterauth<master-password>与连接建立阶段的身份验证有关，需要输入在主节点设置的密码。
• repl-ping-slave-period 10命令传播阶段主从节点的超时判断，默认为10秒。
• repl-backlog-size 1mb复制积压缓冲区的大小，默认为1mb。
• repl-backlog-ttl 3600当主节点没有从节点时，复制积压缓冲区保留的时间，这样当断开的从节点重新连进来时可以进行部分复制，默认为3600秒。如果设置为0，则永远不会释放复制积压缓冲区。
• min-slaves-to-write 3与min-slaves-max-lag 10用于设定主节点的最小从节点数目及对应的最大延迟，含义是如果从节点数量小于3个或所有从节点的延迟都大于10秒，那么主节点在拒绝执行写命令时会给客户端返回错误。
• slave-serve-stale-data yes与从节点数据陈旧时是否响应客户端命令有关，它用于控制在这种情况下从节点的表现。如果为yes（默认值）​，则从节点仍能够响应客户端的命令；如果为no，则从节点只能响应info、slaveof等少数命令。该参数的设置与应用数据一致性的要求有关，如果对数据一致性要求很高，就应设置为no。
• slave-read-only yes从节点是否只读：默认是只读的。由于从节点开启写操作容易导致主从节点的数据不一致，因此尽量不要修改该配置。

6、主从架构的作用

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际上是一种服务的冗余。
• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载，尤其是在写少读多的应用场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
• 哨兵模式和集群模式的重要部分：主从复制是哨兵和集群模式能够实施的基础，因此可以说主从复制是Redis高可用的基础。