南阳微网站开发,网络营销典型企业,网页编辑岗位职责和任职要求,坪山网站建设策划复制
概述
在Redis中#xff0c;用户可以通过执行SLAVEOF命令或者设置slaveof选项#xff0c;让一个服务器去复制(replicate)另一个服务器#xff0c;我们称呼被复制的服务器为主服务器(master)#xff0c;而对主服务器进行复制的服务器则被称为从服务器(slave),如图所示…复制
概述
在Redis中用户可以通过执行SLAVEOF命令或者设置slaveof选项让一个服务器去复制(replicate)另一个服务器我们称呼被复制的服务器为主服务器(master)而对主服务器进行复制的服务器则被称为从服务器(slave),如图所示。
例子
举个例子。假设现在有两个Redis服务器地址分别为127.0.0.1:6379和127.0.0.1:12345如果我们向服务器127.0.0.1:12345发送以下命令:
127.0.0.1:12345 SLAVEOF 127.0.0.1 6379
OK那么服务器127.0.0.1:12345将称为127.0.0.1:6379的从服务器而服务器6379则会称为12345的主服务器。进行复制中的主从服务器双方的数据库将保存相同的数据概念上将这种现象乘坐为数据库状态一致,或者 简称一致。比如说在主服务器上执行以下命令:
127.0.0.1:6379 SET msg hello world
OK那么我们应该既可以在主服务器上获取msg键的值:
127.0.0.1:6379 GET msg
hello world又可以在从服务器上获取msg键的值:
127.0.0.1:12345 GET msg
hello world另一方面如果我们在主服务器中删除了键msg:
127.0.0.1:6379 DEL msg
(integer) 1那么不仅主服务器上的msg键会被删除
127.0.0.1:6379 EXISTS msg
(integer) 0从服务器上的msg键也应该会被删除:
127.0.0.1:12345 EXISTS msg
(integer) 0旧版复制功能的实现
Redis的复制宫嗯那个分为同步(sync)和命令传播(command propagate)两个操作:
1.同步操作用于将从服务器的数据库状态更新至主服务器当前所处的数据库状态2.命令传播则用于在主服务器的数据库状态被修改导致主从服务器的数据库状态出现不一致时让主从服务器的数据库重新回到一致性
同步
当客户端向从服务器发送SLAVEOF命令要求从服务器复制主服务器时从服务器首先需要执行同步操作也即是将从服务器的数据库状态更新至主服务器当前所处的数据库状态。从服务器对主服务器的同步操作需要通过向主服务器发送SYNC命令来完成以下是SYNC命令的 执行步骤:
1.从服务器向主服务器发送SYNC命令2.收到SYNC命令的主服务器执行BGSAVE命令在后台生成一个RDB文件,并使用一个缓冲区记录从现在开始执行的所有写命令3.当主服务器的BGSAVE命令执行完毕时主服务器会将BGSAVE命令生成的RDB文件发送给从服务器,从服务器接收并载入这个RDB文件将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态4.主服务器将记录在缓冲区里面的所有写ing零发送给从服务器从服务器执行这些写命令将自己的数据库状态更新至主服务器数据库当前所处的状态
例子 命令传播
在同步操作执行完毕之后主从服务器两者的数据库将达到一致状态但这种一致并不是一成不变的每当主服务器执行客户端发送的写命令时主服务器的数据库就有可能会被修改并导致主从服务器状态不再一致。
例子
举个例子假设一个主服务器和一个从服务器刚刚完成同步操作它们的数据库都保存了相同的五个键k1至k5,如图所示如果这是客户端向主服务器发送命令DEL k3那么主服务器在执行完这个DEL命令之后主从服务器的数据库将出现不一致:主服务器的数据库已经不再包含键 k3,但这个键却仍然包含在从服务器的数据库里面如图所示. 为了让主从服务器再次回到一致状态主服务器需要对从服务器执行命令传播操作:主服务器会将自己执行的写命令也即是造成主从服务器不一致的那条写命令发送给从服务器执行当从服务器执行了相同的写命令之后主从服务器将再次回到y一致状态。
在上面的例子中主服务器因为执行了命令DEL k3而导致主从服务器不一致所以主服务器将向从服务器发送相同的命令DEL k3。当从服务器执行完这个命令之后主从服务器将再次回到一致状态现在主从服务器两者的数据库都不再包含键k3
旧版复制功能的缺陷
在Redis2.8以前从服务器对主服务器的复制可以分为以下两种情况:
1.初次复制:从服务器以前没有复制过任何主服务器或者从服务器当前要复制的主服务器和上一次复制的主服务器不同.2.断线后重复制:处于命令传播阶段的主从服务器因为网络原因而中断了复制但从服务器通过自动重连接重新连上了主服务器并继续复制主服务器。对于初次复制来说旧版复制功能能够很好地完成任务但对于断线后重复制来说旧版复制功能虽然也能让主服务器重新回到一致状态但效率却非常低。
例子 举个例子。在时间10091,从服务器终于重新连接上主服务器因为这是主从服务器的状态已经不再一致所以从服务器将向主服务器发送SYNC命令而主服务器会将包含键k1至键k10089的RDB文件发送给从服务器从服务器通过接收和载入这个RDB文件来将自己的数据库更新至主服务器数据库当前所处的状态。
虽然再次发送SYNC命令可以让主从服务器重新回到一致状态但如果仔细研究过这个断线重复制过程就会发现传送RDB文件这一步实际上并不是非做不可的:
1.主从服务器在时间T0至T10086中一致处于一致状态这连个服务器保存的数据大部分都是相同的。2.从服务器想要将自己更新至主服务器当前所处的状态真正需要的是主从服务器连接中断期间主服务器新添加的k10086/k10088/k10089三个键的数据3.可惜的是旧版复制功能并没有利用以上列举的两点条件而是继续让主服务器生成并向从服务器发送包含键k1至键k10089的RDB文件但实际上RDB文件包含的键1至键k10086的数据对于从服务器来说都是不必要的。在主从服务器断线期间主服务器执行的写命令可能会有成百上千之多而不仅仅是两三个写命令。但总的来说主从服务器断开的时间 越短主服务器在断线期间执行的写命令就越少而执行少量写命令所产生的数据量通常比整个数据库的数据量要少的多在这种情况下为了让从服务器不足一小部分缺失的数据却要让主从服务器重新再执行一次SYNC命令这种做法无疑是非常低效的。
注意
SYNC命令是一个非常耗费资源的操作。每次执行SYNC命令主从服务器需要执行以下动作:
1.主服务器需要执行BGSAVE命令来生成RDB文件这个生成操作会耗费主服务器大量的CPU、内存和磁盘IO资源2.主服务器需要将自己生成的RDB文件发送给从服务器这个发送操作会耗费主从服务器大量的网络资源(带宽和流量),并对主服务器相应命令请求的时间产生影响3.接收到RDB文件的从服务器需要载入主服务器发来的RDB文件并且在载入期间从服务器会因为阻塞而么没办法处理命令请求。 因为SYNC命令是一个如此耗费资源的操作所以Redis有必要保证在真正有需要时才执行SYNC命令
