专业的网站建设收费标准,网页编辑怎么打开,网站推广的主要方法有哪些?,网络品牌推广Redis的持久化功能在一定程度上保证了数据的安全性#xff0c;即便是服务器宕机的情况下#xff0c;也可以保证数据的丢失非常少。通常#xff0c;为了避免服务的单点故障#xff0c;会把数据复制到多个副本放在不同的服务器上#xff0c;且这些拥有数据副本的服务器可以用…Redis的持久化功能在一定程度上保证了数据的安全性即便是服务器宕机的情况下也可以保证数据的丢失非常少。通常为了避免服务的单点故障会把数据复制到多个副本放在不同的服务器上且这些拥有数据副本的服务器可以用于处理客户端的读请求扩展整体的性能
下面会介绍Redis的主从复制配置和实现原理后续还会有Redis的高可用方案哨兵机制Sentinel、分区集群Cluster
什么是主从复制
我们可以通过slaveof host port命令或者通过配置slaveof选项来使当前的服务器slave复制指定服务器master的内容被复制的服务器称为主服务器master对主服务器进行复制操作的为从服务器slave
主服务器master可以进行读写操作当主服务器的数据发生变化master会发出命令流来保持对salve的更新而从服务器slave通常是只读的可以通过slave-read-only指定在主从复制模式下即便master宕机了slave是不能变为主服务器进行写操作的
一个master可以有多个slave即一主多从而slave也可以接受其他slave的连接形成“主从链”层叠状结构cascading-like structure自 Redis 4.0 起所有的sub-slave也会从master收到完全一样的复制流。如下图 主从复制的好处
数据冗余实现数据的热备份故障恢复避免单点故障带来的服务不可用读写分离负载均衡。主节点负载读写从节点负责读提高服务器并发量高可用基础是哨兵机制和集群实现的基础
主从复制的配置
使用和配置主从复制是比较简单的在从服务器slave的配置文件中设置slaveof选项或者直接使用slaveof masterip masterport命令
这里我使用3台虚拟机来搭建一下主服务器的ip为192.168.249.20两个从服务器的ip分别为192.168.249.21和192.168.249.21端口号都为6379具体的配置如下
主服务器并不需要额外多配置什么这里我们先把三台服务器的都需要改的地方列一下 复制代码
# 设置为后台运行 daemonize yes # 保存pid的文件如果是在一台机器搭建主从需要区分一下 pidfile /var/run/redis_6379.pid # 绑定的主机地址这里注释掉开放ip连接 #bind 127.0.0.1 # 指定日志文件 logfile 6379.log
在从服务器中添加配置slaveof masterport masterport选项在5.0版本中使用了replicaof代替了slaveofgithub.com/antirez/red…slaveof还可以继续使用不过建议使用replicaof。如果是使用命令行来复制的话重启之后会无效 复制代码
# replicaof masterip masterport replicaof 192.168.249.20 6379
配置好redis.conf之后我们分别启动3台服务器可以用户命令info replication查看复制信息 复制代码
192.168.249.20:6379 info replication # Replication role:master connected_slaves:2 slave0:ip192.168.249.22,port6379,stateonline,offset700,lag0 slave1:ip192.168.249.21,port6379,stateonline,offset700,lag0 master_replid:b80a4720c0001efb62940f5ad6abaf9cdaf7a813 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:700 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:700 192.168.249.21:6379 info replication # Replication role:slave master_host:192.168.249.20 master_port:6379 master_link_status:up master_last_io_seconds_ago:3 master_sync_in_progress:0 slave_repl_offset:854 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:b80a4720c0001efb62940f5ad6abaf9cdaf7a813 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:854 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:57 repl_backlog_histlen:798 192.168.249.22:6379 info replication # Replication role:slave master_host:192.168.249.20 master_port:6379 master_link_status:up master_last_io_seconds_ago:6 master_sync_in_progress:0 slave_repl_offset:854 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:b80a4720c0001efb62940f5ad6abaf9cdaf7a813 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:854 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:854
接下来我们可以在主服务器中写入数据然后可以在其他的从服务器中读取数据 复制代码
192.168.249.20:6379 set test Hello World OK 192.168.249.21:6379 get test Hello World 192.168.249.22:6379 get test Hello World
然后我们试着在从服务器中写入数据会提示不能在只读的从服务器中写入数据 复制代码
192.168.249.21:6379 set test2 hello (error) READONLY You cant write against a read only replica. 如果我们需要slave对master的复制进行验证可以在master中配置requirepass password选项设置密码 那么需要在从服务器中使用该密码可以使用命令config set masterauth password或者在配置文件中设置masterauth password 主从复制的实现原理
主从复制的配置还是比较简单的下面来了解下主从复制的实现原理
Redis的主从复制过程大体上分3个阶段建立连接、数据同步、命令传播
建立连接
这个阶段主要是从服务器发出slaveof命令之后与主服务器如何建立连接为数据同步做准备的过程。
1在slaveof命令执行之后从服务器根据设置的master的ip地址和端口创建连向主服务器的socket套接字连接连接成功后从服务器会为这个套接字关联一个专门的处理器用于处理后续的复制工作
2建立连接之后从服务器会向主服务器发送ping命令确认主服务器是否可用以及当前是否可用接受处理命令。如果收到主服务器的pong回复说明是可用的否则有可能是网络超时或主服务器阻塞从服务器会断开连接发起重连
3身份验证。如果主服务器设置了requirepass选项那么从服务器必须配置masterauth选项且保证密码一致才能通过验证
4身份验证完成之后从服务器会发送自己的监听端口主服务器会保存下来 复制代码
192.168.249.20:6379 info replication ... slave0:ip192.168.249.22,port6379,stateonline,offset700,lag0 slave1:ip192.168.249.21,port6379,stateonline,offset700,lag0 ...
数据同步
在主从服务器建立连接确认各自身份之后就开始数据同步从服务器向主服务器发送PSYNC命令执行同步操作并把自己的数据库状态更新至主服务器的数据库状态
Redis的主从同步分为完整重同步full resynchronization和部分重同步partial resynchronization
完整重同步
有两种情况下是完整重同步一是slave连接上master第一次复制的时候二是如果当主从断线重新连接复制的时候有可能是完整重同步这个在后面说
下面是完整重同步的步骤 从服务器连接主服务器发送SYNC命令主服务器接收到SYNC命名后开始执行bgsave命令生成RDB文件并使用缓冲区记录此后执行的所有写命令主服务器basave执行完后向所有从服务器发送快照文件并在发送期间继续记录被执行的写命令从服务器收到快照文件后丢弃所有旧数据载入收到的快照主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令从服务器完成对快照的载入开始接收命令请求并执行来自主服务器缓冲区的写命令
部分重同步
部分重同步是用于处理断线后重复制的情况先介绍几个用于部分重同步的部分
runid(replication ID)主服务器运行idRedis实例在启动时随机生成一个长度40的唯一字符串来标识当前节点offset复制偏移量。主服务器和从服务器各自维护一个复制偏移量记录传输的字节数。当主节点向从节点发送N个字节数据时主节点的offset增加N从节点收到主节点传来的N个字节数据时从节点的offset增加Nreplication backlog buffer复制积压缓冲区。是一个固定长度的FIFO队列大小由配置参数repl-backlog-size指定默认大小1MB。需要注意的是该缓冲区由master维护并且有且只有一个所有slave共享此缓冲区其作用在于备份最近主库发送给从库的数据
当slave连接到master会执行PSYNC runid offset发送记录旧的master的runidreplication ID和偏移量offset这样master能够只发送slave所缺的增量部分。但是如果master的复制积压缓存区没有足够的命令记录或者slave传的runid(replication ID)不对就会进行完整重同步即slave会获得一个完整的数据集副本 PSYNC命令执行完整重同步和部分重同步的流程图 命令传播
当完成数据同步之后主从服务器的数据暂时达到一致状态当主服务器执行了客户端的写命令之后主从的数据便不再一致。为了能够使主从服务器的数据保持一致性主服务器会对从服务器执行命令传播操作即每执行一个写命令就会向从服务器发送同样的写命令
在命令传播阶段从服务器会默认以每秒一次的频率向主服务器发送心跳检测 复制代码
REPLCONF ACK replication_offset
其中replication_offset是当前从服务器的复制偏移量该命令的作用有三个
检测主从服务器的网络连接状态辅助实现min-slaves选项检测命令丢失
关闭持久化时复制的安全性
关于关闭持久化时复制的安全性问题我这里摘入官网的一段描述www.redis.cn/topics/repl…
在使用Redis复制功能时的设置中强烈建议在master和在slave中启用持久化。当不可能启用时例如由于非常慢的磁盘性能而导致的延迟问题应该配置实例来避免重置后自动重启。
为了更好地理解为什么关闭了持久化并配置了自动重启的 master 是危险的检查以下故障模式这些故障模式中数据会从 master 和所有 slave 中被删除
我们设置节点 A 为 master 并关闭它的持久化设置节点 B 和 C 从 节点 A 复制数据。节点 A 崩溃但是他有一些自动重启的系统可以重启进程。但是由于持久化被关闭了节点重启后其数据集合为空。节点 B 和 节点 C 会从节点 A 复制数据但是节点 A 的数据集是空的因此复制的结果是它们会销毁自身之前的数据副本。
当 Redis Sentinel 被用于高可用并且 master 关闭持久化这时如果允许自动重启进程也是很危险的。例如 master 可以重启的足够快以致于 Sentinel 没有探测到故障因此上述的故障模式也会发生。
任何时候数据安全性都是很重要的所以如果 master 使用复制功能的同时未配置持久化那么自动重启进程这项应该被禁用
参考《Redis设计与实现》、redis replication 作者TurboSnail 链接https://juejin.cn/post/6844903943764443149 来源稀土掘金 著作权归作者所有。商业转载请联系作者获得授权非商业转载请注明出处。
