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部分复制形成完整数据。
转载请注明原文链接：redis一致性方案简介
