REdis一致性方案探讨

栏目: 数据库 · 发布时间: 4年前

REdis 功能强大众所周知,能够大幅简化开发和提供大并发高性能,但截止到 REdis-5.0.5 仍然存在如下几大问题:

1) 一致性问题

这是由于 REdis 的主从复制采用的是异步复制,异常时可能发生主节点的数据未能复制到从节点,导致从节点提升为主节点后缺失部分数据。虽然 REdis 提供 WAIT 命令来使得主节点将数据同步给了从节点,但当前此命令可用性低。

2) 分布式事务问题

当前 REdis 只支持单机事务,从官方的文档来看,推荐使用“ EVAL+lua ”方式实现事务,而不是“ MULTI+EXEC ”方式。分布式事务对任何系统都是难点和挑战,短期内无实现可能,但如果只实现低级别的隔离性满足部分应用场景,则可大幅度降低实现的复杂性。

3) 从节点重启全量复制

REdis 虽然有部分复制能力,但针对的是网络连接断开后重连接。部分复制依赖“ repl ”信息,所以当前并不直接支持(可手工操作)。

本文专注探讨一致性问题的解决。受 Hadoop NameNode HA 方案启发, REdis 也可采用相同的解决方案,此方案对 REdis 架构基本无影响,而且代码改动量小。

REdis一致性方案探讨

基于同样的思路,为 REdis 引入 QJM

REdis一致性方案探讨

REdis 主节点接收和处理写( Write )操作,然后同步到 QJM ,只 QJM 写成功后才返回给 Client 。数据一旦写入到 QJM ,由一致性协议( PaxOS Raft 等)可保证数据不会丢。

REdis一致性方案探讨

一般 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一致性方案探讨》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Lighttpd

Lighttpd

Andre Bogus / Packt Publishing / 2008-10 / 39.99

This is your fast guide to getting started and getting inside the Lighttpd web server. Written from a developer's perspective, this book helps you understand Lighttpd, and get it set up as securely an......一起来看看 《Lighttpd》 这本书的介绍吧!

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

随机密码生成器
随机密码生成器

多种字符组合密码

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具