「redis主从java」Redis主从复制原理

本篇文章给大家谈谈redis主从java，以及Redis主从复制原理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、详解Redis 主从复制及主从复制原理
• 2、Redis早期的主从架构原理分析，早期如何实现读写分离的？
• 3、redis主从集群 主挂掉 java怎样调用从
• 4、010.Redis 主从架构搭建及原理详解
• 5、Redis主从结构，主库宕机挂了，怎么办
• 6、如何通过java对redis进行性能测速

详解Redis 主从复制及主从复制原理

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。

概述

在现有企业中80%公司大部分使用的是redis单机服务，在实际的场景当中单一节点的redis容易面临风险。

2、容量瓶颈。 当我们有需求需要扩容 Redis 内存时，从 16G 的内存升到 64G，单机肯定是满足不了。当然，你可以重新买个 128G 的新机器。

解决办法

要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。

Redis 为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现 Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用。

主从复制

什么是主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用

1、数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2、故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3、负载均衡： 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4、读写分离： 可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量。

5、高可用基石： 除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制启用

从节点开启主从复制，有3种方式：

1、配置文件： 在从服务器的配置文件中加入 slaveofmasteripmasterport。

2、启动命令： redis-server启动命令后加入 --slaveofmasteripmasterport。

3、客户端命令： Redis服务器启动后，直接通过客户端执行命令 slaveofmasteripmasterport，则该Redis实例成为从节点。

通过 info replication 命令可以看到复制的一些信息。

主从复制原理

主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。

在从节点执行 slaveof 命令后，复制过程便开始运作，下面图示可以看出复制过程大致分为6个过程。

主从配置之后的日志记录也可以看出这个流程。

1、保存主节点（master）信息

执行 slaveof 后 Redis 会打印如下日志：

2、从节点与主节点建立网络连接

从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。

从节点与主节点建立网络连接。

从节点会建立一个 socket 套接字，从节点建立了一个端口为51234的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：

如果从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveofnoone 取消复制。

关于连接失败，可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志，方便发现问题：

3、发送 ping 命令

连接建立成功后从节点发送 ping 请求进行首次通信， ping 请求主要目的如下：

如果发送 ping 命令后，从节点没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。

从节点发送的 ping 命令成功返回，Redis 打印如下日志，并继续后续复制流程：

4、权限验证

如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证。如果验证失败复制将终止，从节点重新发起复制流程。

5、同步数据集

主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。

6、命令持续复制

当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

作者：LoyaltyLu

链接：

Redis早期的主从架构原理分析，早期如何实现读写分离的？

基于主从复制架构，实现读写分离，redis slave node节点只读，默认开启配置：slave-read-only yes。开启了只读的节点redis slave node，会拒绝所有写操作，这样可以强制搭建成读写分离的架构。

（1）redis采用异步方式复制数据到slave节点。

（2）一个master node是可以配置多个slave node的。

（3）slave node也可以连接其他的slave node。

（4）slave node做复制的时候，是不会block master node的正常工作的。

（5）slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了。

（6）slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量。

如果采用了主从架构，那么建议必须开启master node的持久化！不建议用slave node作为master node的数据热备，因为那样的话，如果你关掉master的持久化，可能在master宕机重启的时候数据是空的，然后可能一经过复制，salve node数据也丢了。

（1）当启动一个slave node的时候，它会发送一个 PSYNC 命令给master node。

（2）如果这是slave node 重新连接 master node，那么master node仅仅会 复制给slave部分缺少的数据 ，否则如果是slave node 第一次连接 master node，那么会触发一次 full resynchronization ，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令 缓存在内存中 。RDB文件生成完毕之后，master会先将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中 缓存的写命令 发送给slave，slave也会同步这些数据。

（3）slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制。master node会在内存中建一个 backlog ，master和slave都会保存一个 replica offset 还有一个 master id（run id） ，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制，但是如果没有找到对应的offset，那么就会执行一次full resynchronization全量同步。

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了。

repl-diskless-sync no 改为开启就可以了

repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来，用一分数据提供服务。

slave node不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

（1）slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是复制流程没开始。master host和ip是从哪儿来的？redis.conf里面的slaveof配置的。

（2）slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接。

（3）slave node发送ping命令给master node。

（4）口令认证，如果master设置了requirepass（master上启用安全认证配置，requirepass 自己取名 ），那么salve node必须发送masterauth的口令过去进行认证（masterauth 自己取名 ）

（5）master node第一次执行全量复制，将所有数据发给slave node。

（6）master node后续持续将写命令，增量异步复制给slave node。

指的就是第一次slave连接msater的时候，执行的全量复制，这个过程里面的一些细节的机制

（1）master和slave都会维护一个offset

master会在自身不断累加offset，slave也会在自身不断累加offset。slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset。这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况。

（2）backlog

master node有一个backlog，默认是1MB大小，master node给slave node复制数据时，也会将数据在backlog中同步写一份。backlog主要是用来做全量复制中断后的增量复制的。

（3）master run id

info server命令，可以看到master run id。如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制。如果需要不更改run id重启redis，可以使用redis-cli debug reload命令。

（4）psync

从节点使用psync从master node进行复制psync runid offset。master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是继续触发增量复制。

（1）master执行bgsave，在本地生成一份rdb快照文件。

（2）master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数。

（3）对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s。

（4）master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node。

（5）client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，或复制时间超过60秒，那么停止复制，复制失败。

（6）slave node接收到rdb之后，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务，写入后，清空自己的旧数据，用新的对外提供读服务。

（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF。在这个过程中，rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave node aof rewrite，很耗费时间的。

（1）如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制。

（2）master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB。

（3）master就是根据slave发送的psync中的offset来从backlog中获取数据的。

下节讲解哨兵架构，在讲之前，你能否处理下面两个问题呢？

1、异步复制导致的数据丢失

哨兵可以解决主从架构下，因master宕机后不能接收写请求而进行选举salve为新的master，达到高可用的效果。

因为master - slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了，此时应该怎么处理？

2、脑裂导致的数据丢失

脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着。

此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master这个时候，集群里就会有两个master，也就是所谓的脑裂。

此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据，导致数据丢失，怎么处理脑裂导致的数据丢失呢？

先考虑一下，我们下节进行讲解。

redis主从集群 主挂掉 java怎样调用从

从机的redis命令行输入slaveofnoone转换为主机，然后要么修改主机ip要么修改java程序中的主机ip地址。

另外建议看下redis sentinel 主从切换(failover)解决方案

010.Redis 主从架构搭建及原理详解

在redis主从架构中，Master节点负责处理写请求，Slave节点只处理读请求。对于写请求少，读请求多的场景，例如电商详情页，通过这种读写分离的操作可以大幅提高并发量，通过增加redis从节点的数量可以使得redis的QPS达到10W+。

Master节点接收到写请求并处理后，需要告知Slave节点数据发生了改变，保持主从节点数据一致的行为称为主从同步，所有的Slave都和Master通信去同步数据也会加大Master节点的负担，实际上，除了主从同步，redis也可以从从同步，我们在这里统一描述为主从同步。

redis 同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一边向主节点反馈自己同步到哪里了 (偏移量，这是redis-2.8之后才有的特性)。从节点同步数据的时候不会影响主节点的正常工作，也不会影响自己对外提供读服务的功能，从节点会用旧的数据来提供服务，当同步完成后，需要删除旧数据集，加载新数据，这个时候才会暂停对外服务。

因为内存的 buffer 是有限的，所以 redis 主节点不能将所有的指令都记录在内存 buffer 中。redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满

了，就会从头开始覆盖前面的内容。

如果节点间网络通信不好，那么当从节点同步的速度不如主节点接收新写请求的速度时，buffer 中会丢失一部分指令，从节点中的数据将与主节点中的数据不一致，此时将会触发快照同步。

快照同步是一个非常耗费资源的操作，它首先需要在主节点上进行一次 bgsave 将当前内存的数据全部快照到RDB文件中，然后再将快照文件的内容全部传送到从节点。从节点将RDB文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步。

在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。所以需要配置一个合适的复制 buffer 大小参数，避免快照复制的死循环。

主节点在进行快照同步时，会进行大量的文件 IO 操作，特别是对于非 SSD 磁盘存储时，快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync 操作时如果发生快照复制，fsync 将会被推迟执行，这就会严重影响主节点的服务效率。

从 Redis 2.8.18 版开始支持无盘复制。所谓无盘复制是主节点会一边遍历内存，一遍将序列化的内容发送到从节点，而不是生成完整的 RDB 文件后才进行 IO 传输从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中，再进行一次性加载。

(1) 在从节点的配置文件中的 slaveof 配置项中配置了主节点的IP和port后，从节点就知道自己要和那个主节点进行连接了。

(2) 从节点内部有个定时任务，会每秒检查自己要连接的主节点是否上线，如果发现了主节点上线，就跟主节点进行网络连接。注意，此时仅仅是取得连接，还没有进行主从数据同步。

(3) 从节点发送ping命令给主节点进行连接，如果设置了口令认证（主节点设置了requirepass），那么从节点必须发送正确的口令（masterauth）进行认证。

(4) 主从节点连接成功后，主从节点进行一次快照同步。事实上，是否进行快照同步需要判断主节点的 run id ，当从节点发现已经连接过某个 run id 的主节点，那么视此次连接为重新连接，就不会进行快照同步。相同IP和port的主节点每次重启服务都会生成一个新的 run id ，所以每次主节点重启服务都会进行一次快照同步，如果想重启主节点服务而不改变 run id ，使用 redis-cli debug reload 命令。

(5) 当开始进行快照同步后，主节点在本地生成一份rdb快照文件，并将这个rdb文件发送给从节点，如果复制时间超过60秒（配置项：repl-timeout），那么就会认为复制失败，如果数据量比较大，要适当调大这个参数的值。主从节点进行快照同步的时候，主节点会把接收到的新请求命令写在缓存 buffer 中，当快照同步完成后，再把 buffer 中的指令增量同步到从节点。如果在快照同步期间，内存缓冲区大小超过256MB，或者超过64MB的状态持续时间超过60s（配置项： client-output-buffer-limit slave 256MB 64MB 60 ），那么也会认为快照同步失败。

(6) 从节点接收到RDB文件之后，清空自己的旧数据，然后重新加载RDB到自己的内存中，在这个过程中基于旧的数据对外提供服务。如果主节点开启了AOF，那么在快照同步结束后会立即执行BGREWRITEAOF，重写AOF文件。

(7) 主节点维护了一个backlog文件，默认是1MB大小，主节点向从节点发送全量数据（RDB文件）时，也会同步往backlog中写，这样当发送全量数据这个过程意外中断后，从backlog文件中可以得知数据有哪些是发送成功了，哪些还没有发送，然后当主从节点再次连接后，从失败的地方开始增量同步。这里需要注意的是，当快照同步连接中断后，主从节点再次连接并非是第一次连接，所以进行增量同步，而不是继续进行快照同步。

(8) 快照同步完成后，主节点后续接收到写请求导致数据变化后，将和从节点进行增量同步，遇到 buffer 溢出则再触发快照同步。

(9) 主从节点都会维护一个offset，随着主节点的数据变化以及主从同步的进行，主从节点会不断累加自己维护的offset，从节点每秒都会上报自己的offset给主节点，主节点也会保存每个从节点的offset，这样主从节点就能知道互相之间的数据一致性情况。从节点发送 psync runid offset 命令给主节点从而开始主从同步，主节点会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，也可能是CONTINUE触发增量复制。

(10) 主从节点因为网络原因导致断开，当网络接通后，不需要手工干预，可以自动重新连接。

(11) 主节点如果发现有多个从节点连接，在快照同步过程中仅仅会生成一个RDB文件，用一份数据服务所有从节点进行快照同步。

(12) 从节点不会处理过期key，当主节点处理了一个过期key，会模拟一条del命令发送给从节点。

(13) 主从节点会保持心跳来检测对方是否在线，主节点默认每隔10秒发送一次heartbeat，从节点默认每隔1秒发送一个heartbeat。

(14) 建议在主节点使用AOF+RDB的持久化方式，并且在主节点定期备份RDB文件，而从节点不要开启AOF机制，原因有两个，一是从节点AOF会降低性能，二是如果主节点数据丢失，主节点数据同步给从节点后，从节点收到了空的数据，如果开启了AOF，会生成空的AOF文件，基于AOF恢复数据后，全部数据就都丢失了，而如果不开启AOF机制，从节点启动后，基于自身的RDB文件恢复数据，这样不至于丢失全部数据。RDB和AOF机制可以参考 详解 redis-4.x 持久化机制

使用3个虚拟机搭建一主二从的redis主从架构集群。首先参考 redis-4.0.12单节点安装 在每台机器上安装redis，然后修改redis配置文件，其中一个master节点的配置如下（未列出的保持默认即可）：

两个slave节点的配置如下：

启动3个redis服务：

查看master日志：

看日志发现一个问题，我们在原理中介绍说：

主节点如果发现有多个从节点连接，在快照同步过程中仅仅会生成一个RDB文件，用一份数据服务所有从节点进行快照同步。

然而这里master的日志显示写了两次RDB文件，这里我查一些资料再来更新。（！！！待完善）

查看slave日志（这里只列出一个slave的日志）：

测试主从架构：

(1) 使用 redis-cli 访问3个redis服务

(2) 在 master 节点上 set 一个数据

(3) 从节点上获取数据

(4) 尝试在slave上写入数据

redis主从架构搭建成功！

wait 提供两个参数，第一个参数是从节点的数量 m，第二个参数是时间 t，以毫秒

为单位。它表示等待 wait 指令之前的所有写操作同步到 n 个子节点 (也就是确保

m 个子节点的同步没有滞后)，最多等待时间 t。如果时间 t=0，表示无限等待直到

N 个从库同步完成达成一致。

假设此时某个子节点与主节点网络断开，wait 指令第二个参数时间 t = 0，主从同步无法继续

进行，wait 指令会永远阻塞，redis 服务器将丧失可用性。

Redis主从结构，主库宕机挂了，怎么办

连上从库，做save操作。将会在从库的data目录保存一份从库最新的dump.rdb文件。将这份dump.rdb文件拷贝到主库的data目录下。再重启主库。

如何通过java对redis进行性能测速

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。[1]

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

redis的官网地址，非常好记，是redis.io。（特意查了一下，域名后缀io属于国家域名，是british Indian Ocean territory，即英属印度洋领地）

目前，Vmware在资助着redis项目的开发和维护。

redis主从java的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于Redis主从复制原理、redis主从java的信息别忘了在本站进行查找喔。