Redis分布式存储管理软件有，代理实现的Twemproxy，客户端实现的Jedis，还有官方正在实现的Redis Cluster。

　　Twemproxy的问题?

　　Twemproxy是目前较为成熟的分布式管理的成品，但是由于它本身是将Redis定位于缓存管理而不是持久存储，所以只能成为分布式缓存管理软件，因为它缺乏必要的高可用性和一致性保证。而Jedis由于客户端所限，无法具备易伸缩的扩展能力。Twemproxy的说明见存储分片和Twemproxy

　　Redis Cluster是Redis的未来?

　　Redis Cluster是值得期待的官方的集群管理组件，但在Master-Slave特性上，令人惊讶的是作者将slave纯粹作为备份组件而使Master成为脆弱的单点，同时Slave无疑对于内存而言是极大的浪费，并且缺乏高可用性。

　　试想Master节点由于系统阻塞或者网络阻塞导致较长时间的不可见，会影响整个系统的可用性。虽然在客户端方面可以retry连接到slave节点发送读命令。但是写命令仍然不能保证。Redis-sentinel可以作为高可用的补充来帮助Slave转换为新的Master，但是整个过程存在较长的延迟。Redis作为内存数据库，如果不能有高写保证和短的延迟那么就只能充当缓存系统。

　　WheatRedis的方案

　　WheatRedis是采用Dynamo风格的基于Wheatserver分布式存储系统，它使用类似于Redis Cluster的固定slots数目方式来保证当加入新节点和节点下线时的最小数据震荡。WheatRedis可以指定数据的备份数来保证数据持久，并且采用全写随机读的方式来保证数据一致性。

　　设计思想

　　Redis作为一款内存数据库，高并发和低延时是其特点，。作为Redis的集群分片管理组件，保持高并发和低延时是WheatRedis主要目标。高可用性和数据一致性上，WheatRedis牺牲了强一致性，选择了高可用性。但是，WheatRedis对于一致性是在高可用和低延时下尽可能保证，通过可信度，不一致检测等策略来保障。WheatRedis能保证通信故障，系统崩溃、断电等寻常异常下的数据一致性。另外，WheatRedis认为网络分区(Network Partition)是高可用性下需要考虑一个情况，由于WheatRedis组件是无状态组件，在网络分区情况下，WheatRedis对于处在能探查到的网络内节点给予可用性。

　　对于集群扩展性，WheatRedis能保证渐进式扩展，即节点加入和下线保持一定的间隔时间来让WheatRedis这个无状态保证一定通信时间和迁移时间。

　　高可用和一致性的保证和权衡

　　在可用性上，WheatRedis坚持可读可写原则。写命令在保证最长延迟时间的情况下执行。比如三个数据备份节点ABC来存储同一份key，节点A由于网络问题被阻塞，在WheatRedis保证的最长延迟时间内如果A节点仍然没有回应请求，WheatRedis会放弃等待选择发送成功写回应给客户端。在A节点恢复的时间内(请注意，A节点仍然只是网络阻塞，发送的请求和回应并未丢失)，请求仍然会发送给A节点，并等待最长延迟时间同样执行之前步骤。如果在一定时间后，A节点仍然处于网络不稳定状态，A节点会被标记为Dirty，并且读命令会选择性跳过Dirty节点。在节点A恢复可用性后，Dirty节点标志会使得系统分析不一致数据并且同步到节点A。在完成一致性后，系统恢复正常。

　　当写命令写入但是检测到异常不一致时(Redis对写命令的回应不同，可能由通信故障，Redis存储Bug，系统故障，硬件故障和宇宙射线?!导致)，选择高可信节点写入和读取。所谓高可信节点是WheatRedis衡量Redis实例的一个参数，通过对回应时间，超时数，被动离线数等等因素采集Redis实例的可信度。这时，WheatRedis会记录下异常不一致的键，由于这类异常情况是极端例子()，因此会留给运维人员发现进行强制校正。

　　在读命令执行上，WheatRedis同样采取类似写命令的最长延迟时间保证来回应请求。在读取节点的选择上，会优先选取非脏节点。如果全为脏节点(极端情况下)，WheatRedis被迫选取高可信节点读取。

　　如果节点A系统崩溃或者被管理人员下线维护，那么该节点A的信息仍然被保证，并且在恢复上线仍然可以得到一致性恢复的措施。

　　在备份三个节点全部崩溃下线的极端例子下，重要的应用案例可以通过Redis aof机制来保证数据的一致。

　　无论是读命令还是写命令，WheatRedis都采用关联请求的方式的执行来强调小的延迟时间而不需要客户端retry请求来重新获取。

　　扩展性

　　在集群扩展上，WheatRedis采用固定小容量大Slots数目的方案，每个节点包含大量的Slots而Slots又随机分配在环上，单个节点数据迁移量保证最小，而使整个系统的数据迁移无热点。

　　WheatRedis状态存储

　　在数据存储采用全分布式，WheatRedis的代理组件反而可能成为瓶颈。因此，为了避免成为瓶颈，WheatRedis采用无状态运行，所有配置信息存储在后端的Redis上。因此能够轻松实现线性扩展。并且不会成为系统不可用的点。

　　而状态的改变(如节点加入、下线、异常)都通过与状态服务器通信保持，在大部分时间内，状态服务器是没有与WheatRedis的负载。为了保证状态的一致性，在改变状态时采取谨慎行为，总是确保自己是唯一修改的人，而这是通过WheatRedis利用Paxos算法选取临时Master来进行。并且由于需要进行节点改变导致的数据迁移，这是集群需要一定时间去恢复Stable。因此，以上导致了WheatRedis在涉及对状态修改时的缓慢反应。但是由于节点增减是罕见行为，通常这是可以忍受的(Really?)

　　为了防止状态服务器(同样也是Redis数据节点)的状态丢失，状态会定期同步的固定位置保证不丢失(由于数据节点已经保证了一致性，因此状态丢失可能性同样微乎其微)。

　　第一次运行的WheatRedis选择从配置文件中生成配置数据并存储到后端的Redis中，在接下来所有的WheatRedis都可以选择从后端Redis中得到配置数据并且使得WheatRedis保证一致性。

　　实现

　　在上述的WheatRedis Spec中，除了数据迁移和节点增减未实现，其他已经完成初步实现，目前具备高可用的分布式缓存系统的基本能力。

　　WheatRedis相关: www.wzxue.com/wheatserver-2/