当前位置: 首页 > redis, 分布式系统, 缓存系统 > 正文

redis集群方案介绍

1 星2 星3 星4 星5 星 (1 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

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中,除了数据迁移和节点增减未实现,其他已经完成初步实现,目前具备高可用的分布式缓存系统的基本能力。

本文固定链接: http://www.chepoo.com/redis-cluster-introduction.html | IT技术精华网

redis集群方案介绍:等您坐沙发呢!

发表评论