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

主从复制一3、Redis复制的注意事项3.1、复制的注意事项3.2、复制的安全性3.3、无须磁盘参与的复制3.4、只读性质的从节点3.5、主从多种模式下的问题3.5.1、一主一从3.5.2、一主多从3.5.3、树状主从3.5.4、主从复制超时后控制写命令3.5.5、Redis复制处理键的过期4、搭建主从节点的实例4.1、以命令行方式搭建主从节点4.2、以配置文件方式搭建主从节点4.3、以身份验证模式搭建主从架构5、主从架构的“坑”和优化技巧5.1、复制超时问题5.2、主从架构数据应用问题5.2.1、数据延迟与不一致问题5.2.2、数据过期问题5.2.3、故障切换问题5.3、主从复制中断问题5.4、主从复制应用中的优化技巧5.5、主从架构重要配置总结6、主从架构的作用3、Redis复制的注意事项3.1、复制的注意事项Redis主从节点默认使用异步复制从节点和主节点之间以异步方式确认处理的数据量。一个主节点可以有多个从节点。从节点可以接受其他从节点的连接。除了多个从节点可以连接到同一个主节点之外从节点之间也可以以层叠状的结构(cascading-like structure)连接到其他从节点。自Redis 4.0起所有子从节点(sub-slave)将会从主节点收到完全一样的复制流。Redis复制在主节点一侧是非阻塞式的这意味着主节点在一个或多个从节点进行初次同步或者是部分重新同步时可以继续处理查询请求。复制在从节点一侧大部分也是非阻塞式的。当从节点进行初次同步时它可以使用旧数据集处理查询请求假设我们在redis.conf中配置了让Redis这样做。如果复制流断开了Redis从节点会返回一个错误给客户端导致客户端抛出异常。在初次同步之后旧数据集必须被删除同时加载新的数据集。从节点在这个短暂的时间窗口内如果数据集很大就会持续较长时间会阻塞持续到来的连接请求。自Redis 4.0开始可以配置Redis使之在另一个不同的线程中执行删除旧数据集的操作但是加载新数据集的操作依然需要在主线程中进行并且会阻塞从节点。复制以可伸缩性方式来实现以便只读查询可以有多个从节点例如O(N)复杂度的慢操作可以被下放到从节点去执行​或者指定的从节点仅用于数据安全备份作用​。可以使用复制来避免主节点一次性将全部数据集写入磁盘而造成系统短时的巨大开销一种典型的技术是配置主节点的Redis.conf以避免主节点对磁盘执行持久化操作然后连接一个从节点将其配置为不定期保存或是启用AOF。但是这个设置必须小心处理因为重新启动的主节点的程序将从一个空数据集开始如果一个从节点试图与它同步那么这个从节点的数据集也会被清空。3.2、复制的安全性在设置Redis复制功能时强烈建议在主节点和从节点中启用持久化。当不可能启用持久化时例如由于非常慢的磁盘性能而导致的延迟问题​就应该通过配置文件来避免主节点被重置后自动重启。为了更好地理解为什么关闭了持久化并配置了自动重启的主节点是危险的检查以下故障模式这些故障模式中的数据会从主节点和所有从节点中被删除掉我们把节点A设置为主节点并关闭了它的持久化设置节点B和C从主节点A复制数据。当节点A崩溃但是它有一些自动重启的系统可以重启进程。由于持久化被关闭了节点重启后其数据集合为空。节点B和节点C会从主节点A复制数据但是主节点A的数据集是空的因此复制的结果是它们会销毁自身之前的数据副本。任何时候数据安全性都是很重要的所以如果主节点使用复制功能的同时未配置持久化那么自动重启进程这项设置应该被禁用。3.3、无须磁盘参与的复制正常情况下一个全量重新同步要求在磁盘上创建一个RDB文件然后将它从磁盘加载到内存中然后从节点以此进行数据同步。如果磁盘性能很低那么对主节点是一个压力很大的操作。Redis 2.8.18是第一个支持无磁盘复制的版本。在此设置中子进程直接发送RDB文件给从节点无须使用磁盘作为中间存储介质。相关配置如下// 主节点在内存中直接创建RDB文件然后发送给从节点不会在自己的本地磁盘“落地”了 // 参数配置 // 是否无磁盘 repl-diskless-sync no // 主节点发送RDB文件给从节点等待一定时长再开始复制因为要等更多从节点重新连接到主节点这样就可以更好地利用资源提升性能 repl-diskless-sync-delay 5s3.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-writeslave 数量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为主节点dockerrun-d-p6379:6379--namemyredis1 redis // 如果启动需要挂载配置文件则可以执行下面的命令把宿主机的配置文件挂载到容器中#docker run -v /myredis/conf:/usr/local/etc/redis --name myredis1 redisredis-server /usr/local/etc/redis/redis.conf // 启动Redis实例myredis2为主节点dockerrun-d-p6380:6379--namemyredis2 redis // 启动Redis实例myredis3为主节点dockerrun-d-p6381:6379--namemyredis3 redis // 进入myredis2从节点容器dockerexec-itmyredis2 /bin/bash // 客户端连接 redis-cli // 执行脚本让myredis1作为自己的主节点 slaveof192.168.3.2146379// 进入myredis3从节点容器dockerexec-itmyredis3 /bin/bash // 客户端连接 redis-cli // 执行脚本让myredis1作为自己的主节点 slaveof192.168.3.2146379// 进入myredis1主节点容器dockerexec-itmyredis1 /bin/bash // 客户端连接 redis-cli // 验证数据是否同步setname clay // 查看主从信息 info replication主节点搭建的过程如图所示从中可以看到主节点的详细信息。第一个从节点搭建的过程如图所示启动了第一个从节点并建立了主从关系。第二个从节点搭建的过程如图所示启动第二个从节点并建立了主从关系。由上面的几个图可以看到主从节点的信息通过inforeplication命令可以查看主从结构的详细信息主节点执 行该命令可以看到自己的角色是主节点(master)而且拥有两个从节点myredis2和myredis3实例执行该命令可以看到各自都是从节点(slave)还可以看到主节点的IP和端口号。在主节点写入信息后在两个从节点也可以查询到写入主节点的信息如图所示。当两个从节点都可以查询到主节点写入键的值时表示此主从架构的主从同步没有问题。4.2、以配置文件方式搭建主从节点相关配置文件如下# 在从节点配置文件中添加下面的两个配置项即可指定成为某个主节点的从节点# slaveof 主节点地址 主节点端口slaveofhostport# 从服务器只读slave-read-onlyyes下面将在Windows 10系统上利用不同端口号来示范搭建主从架构的过程。首先启动三个实例端口号为6379的实例为主节点端口号为6380和6381的为从节点。6380端口实例的配置文件修改如下port6380slaveof127.0.0.163796381端口实例的配置文件修改如下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、复制超时问题主从节点复制超时是导致复制中断的重要原因之一。在复制连接建立过程中及之后主从节点都有机制判断连接是否超时作用如下如果主节点判断连接超时就会释放相应从节点的连接从而释放各种资源否则无效的从节点仍会占用主节点的各种资源输出缓冲区、带宽、连接等​。此外连接超时的判断可以让主节点更准确地知道当前有效从节点的个数有助于保证数据安全。如果从节点判断连接超时则可以及时重新建立连接避免与主节点数据长期不一致。知道以上两个作用之后下面对一些在实际业务中需要注意的问题进行说明在数据同步阶段也就是主从节点进行全量复制执行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、主从复制中断问题主从节点超时是复制中断的原因之一除此之外还有其他情况可能导致复制中断其中最主要的是复制缓冲区溢出问题。在全量复制阶段主节点会将执行的写命令放到复制缓冲区中而该缓冲区存放的数据包括了以下几个主节点内执行的写命令。bgsave生成RDB文件、RDB文件由主节点发往从节点、从节点清空旧数据并载入RDB文件中数据。当主节点数据量较大或者主从节点之间网络延迟较大时可能会导致该缓冲区的大小超过限制此时主节点会断开与从节点之间的连接。这种情况可能引发全量复制而导致复制缓冲区溢出最终造成连接中断然后进行重新连接再次进行全量复制重新连接、全量复制复制缓冲区溢出导致连接中断……不断地循环往复。需要关注的是复制缓冲区复制缓冲区是客户端输出缓冲区的一种主节点会为每一个从节点分别分配复制缓冲区。复制积压缓冲区则是一个主节点只有一个无论它有多少个从节点的大小由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主从复制的种种细节之后再来看看在实际应用中需要注意的问题。第一次建立复制连接时全量复制不可避免但仍有几点 需要注意。如果主节点的数据量较大用户应该尽量避开网络流量的高峰期避免造成阻塞。如果有多个从节点需要建立对主节点的复制连接则可以考虑将几个从节点的复制错开避免主节点带宽占用过大。如果从节点过多用户也可以调整主从复制的拓扑结构由一主多从结构变为树状结构参考第7.3.6节的内容​。不过使用树状结构应该特别注意这些问题虽然树状结构中因主节点的直接从节点减少了而降低了主节点的负担但是树状结构中因具有多层从节点而使延迟增大数据一致性将变得更差。另外树状结构复杂维护起来相当麻烦。主节点宕机重启后runid会发生变化因此不能进行部分复制只能全量复制。实际上在主节点宕机的情况下我们应进行故障转移处理将其中的一个从节点升级为主节点其他从节点转而从新的主节点进行复制。故障转移应尽量自动化有需要的话可以搭建Redis哨兵模式在一些应用场景下可能希望重启主节点比如主节点内存碎片率过高或者希望调整一些只能在启动时生效的参数。如果使用普通的手段重启主节点就会使得runid发生变化导致不必要的全量复制。为了解决这个问题Redis提供了debug reload的重启方式重启后主节点的runid和offset都不受影响避免了全量复制。不过这种方式会清空当前内存中的数据重新从RDB文件中加载易导致主节点的阻塞因此也需要谨慎操作。通过debug reload方式重启主节点之后run_id没有发生改变如图所示。从节点重启后会丢失其保存的主节点的runid即使再次执行slaveof也无法进行部分复制因此在非特殊情况下尽量不要重启。网络问题如果时间极为短暂只造成了短暂的丢包主从节点都没有判定超时未触发repl-timeout​那么此时只需要通过replconf ack命令来补充丢失的数据即可。如果网络问题时间很长主从节点判断超时触发了repl-timeout​且丢失的数据过多超过了复制积压缓冲区所能存储的范围那么主从节点将无法进行部分复制只能进行全量复制。为了尽可能避免这种情况发生应该根据实际情况适当调整复制积压缓冲区的大小以及判断超时的参数减少全量复制​。5.5、主从架构重要配置总结slaveofmasteripmasterport: 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毫秒同步一次适用于网络环境复杂或带宽紧张的应用场景如跨机房。masterauthmaster-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高可用的基础。