Redis-哨兵机制及redis cluster

一、Redis主从复制

1.1、主从复制介绍

1)使用异步复制。

2)一个主服务器可以有多个从服务器。从服务器也可以有自己的从服务器。

3)复制功能不会阻塞主服务器

4)可以通过复制功能来让主服务器免于执行持久化操作,由从服务器去执行持久化操作即可

image

1.2、数据安全

当配置Redis复制功能时,强烈建议打开主服务器的持久化功能。否则的话,由于延迟等问题,部署的服务应该要避免自动拉起。为了帮助理解主服务器关闭持久化时自动拉起的危险性,参考一下以下会导致主从服务器数据全部丢失的例子:

1. 假设节点A为主服务器,并且关闭了持久化。 并且节点B和节点C从节点A复制数据

2. 节点A崩溃,然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了,所以重启之后没有任何数据

3. 节点B和节点C将从节点A复制数据,但是A的数据是空的, 于是就把自身保存的数据副本删除。

4)在关闭主服务器上的持久化,并同时开启自动拉起进程的情况下,即便使用Sentinel来实现Redis的高可用性,也是非常危险的。 因为主服务器可能拉起得非常快,以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启,然后还是会执行上面的数据丢失的流程。

无论何时,数据安全都是极其重要的,所以应该禁止主服务器关闭持久化的同时自动拉起

1.3、主从复制原理

image

原理说明

1. 副本库通过slaveof 10.0.0.51 6379命令,连接主库,并发送SYNC给主库
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从临时断开。从库数据没有被破坏的情况下,在下次重连之后,,从库发送PSYNC给主库 (2.8版本之后)
9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的

其他说明

1)SYNC 命令执行示例

image

2)命令传播

在主从服务器完成同步之后,主服务器每执行一个写命令,它都会将被执行的写命令发送给从服务器执行,这个操作被称为“命令传播”(command propagate)。命令传播是一个持续的过程:只要复制仍在继续,命令传播就会一直进行,使得主从服务器的状态可以一直保持一致

image

3)复制中的SYNC与PSYNC

①在 Redis 2.8 版本之前, 断线之后重连的从服务器总要执行一次完整重同步(full resynchronization)操作。

②从 Redis 2.8 开始,Redis 使用 PSYNC命令代替 SYNC 命令。PSYNC 比起 SYNC 的最大改进在于 PSYNC 实现了部分重同步(partial resync)特性:在主从服务器断线并且重新连接的时候,只要条件允许,PSYNC 可以让主服务器只向从服务器同步断线期间缺失的数据,而不用重新向从服务器同步整个数据库

SYNC 处理断线重连示例

image

PSYNC 处理断线重连示例

image

1.4、复制一致性

1.4.1、问题引出

image

1)在读写分离环境下,客户端向主服务器发送写命令 SET n 10086,主服务器在执行这个写命令之后,向客户端返回回复,并将这个写命令传播给从服务器。

2)接到回复的客户端继续向从服务器发送读命令 GET n ,并且因为网络状态的原因,客户端的 GET命令比主服务器传播的 SET 命令更快到达了从服务器

3)因为从服务器键 n 的值还未被更新,所以客户端在从服务器读取到的将是一个错误(过期)的 n值。

1.4.2、问题解决

从 Redis 2.8 开始, 为了保证数据的安全性, 可以通过配置, 让主服务器只在有至少 N 个当前已连接从服务器的情况下, 才执行写命令。不过, 因为 Redis 使用异步复制, 所以主服务器发送的写数据并不一定会被从服务器接收到,因此, 数据丢失的可能性仍然是存在的。

通过以下两个参数保证数据的安全:

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>

这个特性的运作原理:
从服务器以每秒一次的频率 PING 主服务器一次, 并报告复制流的处理情况。
主服务器会记录各个从服务器最后一次向它发送 PING 的时间。

1)用户可以通过配置, 指定网络延迟的最大值 min-slaves-max-lag ,以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。如果至少有 min-slaves-to-write 个从服务器, 并且这些服务器的延迟值都少于 min-slaves-max-lag秒,那么主服务器就会执行客户端请求的写操作。

2)另一方面, 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件, 那么写操作就不会被执行,主服务器会向请求执行写操作的客户端返回一个错误。

猜你喜欢

转载自www.cnblogs.com/hujinzhong/p/11620643.html