Redis作为一个分布式的存储服务,集群的工作模式几乎是标配,Redis目前的主从模式也是大多人使用的模型,那Redis的主机和从机是如何保证数据同步一致的呢?
RDB 与 AOF 文件
Redis本身,数据的持久化有两种形式,一种是AOF,另一种就是RDB文件的格式,作为主从同步的模型,Redis采用的就是RDB的文件格式。这里简单介绍一下RDB 和 AOF。
AOF
这种存储模式非常高效,他所存储的是Redis本身执行的所有写命令,比如说set key value
, 所有的写相关的命令,都会被加载到AOF里面。
但是有两点点要注意一下:
- 写入文件的过程不是实时的,毕竟写入文件是有性能消耗的,所以会有一个AOF缓冲区来存储最近的操作,然后定时写入文件。
- 对于一些命令,比如说反复对list的操作,结果集会越来越大,极端的例子是我们for循环一组数据,逐一添加到list里面,对于AOF来说,就是几千条命令,所以AOF会有一个重写的过程,具体的内容在这里不介绍了,可以参阅官网和相关书籍。
RDB
相较于AOF的快照行为,RDB是对于内存中的数据,直接进行一次压缩和文件写入的过程,这种形式还原数据对于Redis来说,比AOF要快很多,但是对于生成来讲,可能性能就不尽如人意了,他是将数据,按照对应的类型(string,list,set,map,zset)按照特定的格式,存入文件里面,添加一些版本号和唯一标示,来识别RDB文件。
生成的命令有两种,一个是SAVE
,一个是BGSAVE
, 区别就是前者是整个Redis不工作来生成数据,后者是开启另一个线程来处理,不影响Redis的正常工作。但同样的是RDB文件生成的时候,性能低下,注定他不能实时存储,通常情况下都是设置一些条件触发生成操作。这里篇幅有限,以后有机会再慢慢介绍。
两者对比
首先第一点,AOF存储的是操作,而RDB存储的是实际的数据库内容,所以注定的是存储上,AOF肯定更加便捷,RDB更加耗费性能。但相反的是,对于大量数据,RDB还原的速度就快很多了,而AOF由于包含了大量的命令,需要逐一执行,整个过程对于Redis而言,肯定不如RDB来得好。
数据丢失的问题上,RDB由于不是实时的,所以注定的在宕机的时候,会有一段时间空隙,数据会产生丢失的情况,而AOF采用的是缓冲区的形式,后台线程进行AOF重写,所以缓冲区也有可能因为宕机而存在丢失的问题,但是对比于RDB,肯定丢失的情况更加少。
主从同步的基本原理
聊了文件存储之后,回到主题上面,Redis的主从模式采用的是RDB文件同步的方式,因为Redis的服务端,数据量有可能非常的大,所以从性能考虑,没有采用AOF快照来同步。
过程大概如下:
- 从机上线,主动链接主机,发送
SYNC
命令 - 主机接到命令后,执行
BGSAVE
命令,生成RDB文件 - 主机向从机发送RDB文件,开始同步数据
- 同步之后,主机将最近的更新,采用命令的形式同步到从机上面。
旧版复制的缺陷
上述的过程对于一个从机,新加入到集群里面的时候,比较合适,但是如果因为断线重连,则需要重新复制主机上所有的内容,主机也因此要进行一次全量级的RDB,比较耗费性能。
在2.8版本之后,采用了一个新的增量复制的过程,流程如下:
- 前面的
sync
的过程还是一样,没有差异 - 当从机断线重连之后,会发送
PSYNC
,要求增量同步,并包括一个offset - 主机根据offset的位置,对之后的数据进行一次增量同步,到从机上面
这里面的offset是由主机和从机共同维护的,相当于一个乐观锁,描述了两方的版本差异。
那决定能否增量同步的主要因素,包括如下三个:
- 是否具备偏移量,与主机进行对比
- 主服务器的复制积压缓冲区(Replication backlog)
- 从服务器的ID
第一条不难理解,重点解释一下第二和第三条
复制积压缓冲区
Redis每分钟都会处理很多的数据,不可能一直把更新的操作存起来,等待从机上线在传输,AOF也不是都在内存中一直保存,所以Redis有一个缓冲区,采用队列的模式来存储这些写操作。
所有的更新操作以队列的形式放入里面,内存大小默认是1MB,超过1MB之后,前面进入队列的写操作就会被移除。
所以当从机上线之后,如果offset与主机版本差距的内容还在缓冲区内,则可以从缓冲区进行增量同步。否则依然还是全量同步(RDB),这里就好比你的机器宕机了一天,在上线,你不能要求我把这一天的数据都给你吧,你直接全量同步得了。
这里我就想到了一个问题,如果我们反复对Redis更新特别大的K-V的话,超过1M,会使得这个缓冲区失效,因为每次的更新都超过这个缓冲区大小了,所以同步操作对于从机来说,都是全量同步,如果太频繁的话,则会产生很大的问题。
当然这个缓冲区的大小也是可以设置调整的饿,可以根据需求配置。
从服务器ID
这个不难理解,因为Redis有一个Slot的概念,每个机器负责一部分的Key,所以如果你之前不是我的从机,那你内存内的数据肯定都不是我的值,就不能只看offset了,还要看一下你之前是不是我的从机,这里主机会维护从机的唯一ID,来校验。
整个复制流程
1. 设置端口号进行连接
SLAVEOF master_ip master_port
命令,或者通过配置文件配置均可。
2. 建立套接字连接
建立连接之后,从服务器会负责处理后续的RDB文件和写命令,主服务器将从服务器作为一个客户端进行响应
3. 发送PING请求
连接之后,通过PING请求检查相互的状态,类似心跳校测的内容。
4. 身份验证
这里需要主服务器和从服务器都设置校验选项,然后校验密码。
- 如果两方都没有设置,则这一步可以忽略
- 如果从服务器设置了,主服务没有设置,则会返回
no password is set
- 如果都设置了,则会进行验证
- 如果主服务器设置了,但是从服务器没有设置,则会返回
NOAUTH
5. 发送端口
由于从服务类似于客户端,等待接受信息,所以需要告知主服务器自己接受所用的端口号,方便未来接受RDB和写命令。
6. 同步
这个时候就进入到我们上面描述的同步机制里面了,SYNC
or PSYNC
等等的内容。
7. 命令传播
后续的写命令,都会通过上面配置的端口号不停传输。
其他内容
心跳检测
进行了套接字连接,执行过PING
命令之后,虽然保证了连接,但是后续的写同步操作,依然需要实时连接。所以从服务器会定期发送自己的offset到主服务器上,检测是否需要同步写操作。
检测从服务状态
主服务器在一个时间周期内没有收到从服务器上述的心跳检测内容,则察觉从服务器可能异常了,所以这个时候会需要查看从服务器的信息。
Redis会配置一些拒绝写操作的内容,在一些特定情况下会认为写操作不安全,这里的不安全是通过配置决定的:
- min-slaves-to-write 3
- min-slaves-max-lag 10
以上的信息表示从节点不能少于3个,或者3个从服务延迟不能超过10秒。否则拒绝写操作,只执行读操作。
命令丢失
由于定期的心跳检测的存在,所以定期检测版本,发现消息丢失这种内容就自动实现了,可以通过offset准确的了解到从服务器哪些信息没有接受到,及时的作出响应。
感谢
以上内容参考Redis官方网站,以及《Redis的设计与实现》一书,如有纰漏,欢迎指出。