REdis一致性方案探讨

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