REdis 功能强大众所周知,能够大幅简化开发和提供大并发高性能,但截止到 REdis-5.0.5 仍然存在如下几大问题:
1) 一致性问题
这是由于 REdis 的主从复制采用的是异步复制,异常时可能发生主节点的数据未能复制到从节点,导致从节点提升为主节点后缺失部分数据。虽然 REdis 提供 WAIT 命令来使得主节点将数据同步给了从节点,但当前此命令可用性低。
2) 分布式事务问题
当前 REdis 只支持单机事务,从官方的文档来看,推荐使用“ EVAL+lua ”方式实现事务,而不是“ MULTI+EXEC ”方式。分布式事务对任何系统都是难点和挑战,短期内无实现可能,但如果只实现低级别的隔离性满足部分应用场景,则可大幅度降低实现的复杂性。
3) 从节点重启全量复制
REdis 虽然有部分复制能力,但针对的是网络连接断开后重连接。部分复制依赖“ repl ”信息,所以当前并不直接支持(可手工操作)。
本文专注探讨一致性问题的解决。受 Hadoop 的 NameNode HA 方案启发, REdis 也可采用相同的解决方案,此方案对 REdis 架构基本无影响,而且代码改动量小。
基于同样的思路,为 REdis 引入 QJM :
REdis 主节点接收和处理写( Write )操作,然后同步到 QJM ,只 QJM 写成功后才返回给 Client 。数据一旦写入到 QJM ,由一致性协议( PaxOS 或 Raft 等)可保证数据不会丢。
一般 QJM 的实现可基于一致性协议 PaxOS 或 Raft ,当前也有开源的 PaxOS 和 Raft 库可直接使用,比如微信开源的 PhxOS ,而开源的 Raft 则更多,比如百度的 braft 等。
考虑到单个 QJM 集群性能有限,可以分组,比如一组 REdis 节点(一个主节点,加一到多个从节点组成)一组 QJM 集群。由于 QJM 只需多数写成功,因此正常情况下,新增的性能开销多数应用场景可接受。
基于此方案,不需改变 REdis 现有架构,并且只需要少量代码修改,主要改动点在:
1) REdis 主节点不再直接同步数据到从节点,部分复制功能也不需要了(直接基于 QJM 做部分复制,可随意重启节点);
2) REdis 主节点同步数据到 QJM ,并且只有同步 QJM 成功后才向 Client 返回成功(相当于 WAIT 命令应用在 QJM 写);
3) REdis 从节点持续从 QJM 同步数据并回放;
4) REdis 从节点获得选举后,并不立即进入可服务状态,而是在提供服务之前先保证已取得了 QJM 上最新的数据,然后才进入可服务状态。由于从节点在选举之前持续同步 QJM 数据,因此在获得选举时一般已是或很快包含了最新数据。
如果是一个新的从节点加入,则可象 Hadoop NameNode 一样,从节点先从主节点下载 image 文件(或叫快照文件),然后再从 QJM 部分复制形成完整数据。
以上所述就是小编给大家介绍的《REdis一致性方案探讨》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 一致性哈希负载均衡算法的探讨
- 一致性哈希负载均衡算法的探讨
- 一致性哈希负载均衡算法的探讨
- 从LocalDateTime序列化探讨全局一致性序列化
- 数据一致性(一) - 接口调用一致性
- 一致性哈希算法(四):Maglev 一致性哈希法
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。