• 欢迎访问搞代码网站,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站!
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏搞代码吧

redis一致性方案简介

redis 海叔叔 5小时前 2次浏览 已收录 0个评论

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

1) 一致性问题

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

2) 分布式事务问题

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

3) 从节点重启全量复制

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

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

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部分复制形成完整数据。


喜欢 (0)
[搞代码]
分享 (0)
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址