面试官:你们Redis故障过吗,怎么解决?

存储 存储设备 Redis
Redis 4.0 开始,当一个实例在故障转移后被提升为 master,它仍能与旧 master 的 Replica 进行部分重同步。

 [[392661]]

1 重启和故障转移后的部分重同步

Redis 4.0 开始,当一个实例在故障转移后被提升为 master,它仍能与旧 master 的 Replica 进行部分重同步。为此,Replica 会记住旧 master 的旧 replication ID 和复制偏移量,因此即使询问旧的 replication ID,也可以将部分复制缓冲提供给连接的 Replica 。

但升级的 Replica 的新 replication ID 将不同,因为它构成了数据集的不同历史记录。例如,master 可以返回可用,并且可以在一段时间内继续接收写命令,因此在被提升的 Replica 中使用相同的 replication ID 将违反 一对复制标识和偏移对只能标识单一数据集 规则。

Replica 在关机并重启后,能够在 RDB 文件中存储所需信息,以便与 master 进行重同步。这在升级的情况下很有用。当需要时,最好使用 SHUTDOWN 命令执行 Replica 的保存和退出操作。

2 主从数据不一致

很显然,这是由于主从网络延时。

2.1 主多从少

部分重同步。可通过命令 PSYNC master_run_id offset 执行。

2.2 主少从多

全量复制,覆盖。这种情况是因为 Replica 是读写模式,因此:

关闭 Replica 的读写模式

或删除 Replica 的数据,重新从 Master 全量复制

3 数据延迟

编写外部程序监听主从节点的复制偏移量,延迟较大时发出报警或通知客户端,切换到 Master 或其他节点。

设置 Replica:

  1. slave-serve-stale-data = no 

除 INFO 和 SLAVOF 命令之外的任何请求都会返回一个错误“SYNC with master in progress”。

当 Replica 失去与Master 的连接时或仍在进行复制时,Replica 可以如下方式起作用:

  • 若 replica-serve-stale-data 为 yes(默认值),则 Replica 仍会回复客户端请求,可能带有过期数据,或者说,若这是第一次同步,则数据集可能只是空的

  • 若将 replica-serve-stale-data 设为no,则该 Replica 将对除以下信息以外的所有命令返回错误“SYNC with master in progress”:INFO,REPLICAOF,AUTH,PING,SHUTDOWN,REPLCONF,ROLE,CONFIG ,SUBSCRIBE,UNSUBSCRIBE,PSUBSCRIBE,PUNSUBSCRIBE,PUBLISH,PUBSUB,COMMAND,POST,HOST和LATENCY

4 脏数据

4.1 脏数据产因

4.1.1 Redis 删除策略

因为读到了过期数据,而读到过期数据就是 Redis 删除策略所导致的:

惰性删除

Master 每次读取命令时都会检查K是否超时,若超时,则执行 del 命令删除K,之后异步把 del 命令同步给 Replica,即可保证数据复制的一致性。切记 Replica 永远不会主动去删除超时数据。

定时删除

Redis 的 Master 在内部有定时任务,会循环采样一定数量的K,当发现采样K过期,会执行 del,之后再同步给每个 Replica。

主动删除

当前已用内存超过 maxmemory 限定时,触发主动清理策略。主动设置的前提是设置了 maxMemory 的值 注:如果数据大量超时,master 节点采样速度跟不上过期的速度,而且 master 节点没有读取过期键的操作,那 slave 节点是无法收到 del 命令的,这时从节点上读取的数据已经是超时的了。

4.1.2 从节点可写

如果从节点(默认读模式)是读写模式,可能误写入从节点的数据,后期就会成为脏数据。

4.2 解决方案

4.2.1 忽略

比如 12306 查余票、双十一秒杀的库存,你会发现经常就是前后不一致的数据。因为你查询时得到的数据,就是需要允许写错误。

4.2.2 选择性强制读主

但是真正下单扣库存时,你就必须确保数据的正确性 选择强制读 master,slave间接变为备份服务器(某个业务)。

4.2.3 从节点只读

防止 slave 写入脏数据。

4.2.4 Redis自身优化

Redis3.2 版本解决了 Redis 删除策略导致的过期数据,在此版本中 slave 读数据前,会检查K过期时间,以决定是否返回数据。

5 数据安全性

5.1 关闭主节点持久化

为提升Redis性能,一般会关闭 Master 持久化的功能(这样所有数据都会持久化在 slave),因为主从同步时,Master 都会 bgsave rdb。但这样也会带来复制的安全性问题。

在使用 Redis 复制功能时的设置中,推荐在 master 和在 slave 中启用持久化。当不可能启用时,例如由于非常慢的磁盘性能而导致的延迟问题,应该禁用主节点自动重启功能。

风险场景

关闭 Master 的持久化设置,Replica1 和 Replica2 从 Master 复制数据。Master 只有内存数据,没有磁盘数据了。

当 Master 宕机,由于自动重启机制重启了,但重启后由于持久化被关闭了,Master数据集为空!

重启后的 Master,发现 runId 发生变化,也会重新和从节点建立连接,两个从节点会发起复制请求,从Master 复制数据,但 Master 此时数据集为空,因此复制的结果是它们会销毁自身之前的数据副本而变成空数据集。 图片

5.1.1 解决方案

牺牲性能,开启 Master 的持久化功能。

为了性能,依旧选择关闭,那就让主节点不自动重启,比如不要有Docker或脚本等自动重启机制。

本文转载自微信公众号「JavaEdge」,可以通过以下二维码关注。转载本文请联系JavaEdge公众号。

 

 

责任编辑:武晓燕 来源: JavaEdge
相关推荐

2022-08-02 06:31:32

Java并发工具类

2022-07-26 08:40:42

Java并发工具类

2022-07-11 10:47:46

容器JAVA

2022-06-30 08:14:05

Java阻塞队列

2023-01-26 00:25:09

JVM设置技术

2024-01-22 10:07:48

Redis持久化功能缓存击穿

2022-06-10 13:56:42

Java

2022-06-30 14:31:57

Java阻塞队列

2021-09-08 08:06:57

Redis原子性数据类型

2020-03-06 15:36:01

Redis内存宕机

2022-07-18 14:18:26

Babel代码面试

2023-02-08 07:04:20

死锁面试官单元

2021-11-02 09:05:25

Redis

2022-06-09 11:20:44

volatile关键字

2022-06-15 15:14:17

Java公平锁非公平锁

2022-06-08 13:54:23

指令重排Java

2019-06-21 15:20:05

Redis数据结构数据库

2024-02-28 10:14:47

Redis数据硬盘

2022-07-06 13:48:24

RedisSentinel机制

2021-07-09 10:11:34

Redis云数据技术
点赞
收藏

51CTO技术栈公众号