REDIS集群处理



原文是http://www.searchdatabase.com.cn/showcontent_78941.htm,叫做理想化REDIS集群，文中提到了REDIS集群的模型以及需要处理的问题。

一致性HASH

问题难点：

1. 为了达到高可用，需要HASH环上节点为邻居节点备份（意味着每份数据必须复制），redis无法处理这种复制问题(一旦开始复制，就会在环上无限循环复制)

之前的老系统一致hash的实现方式是在客户端实现一致性hash，每个hash环上的真实节点都设置有从节点来达到高可用，节点信息全部通过zookeeper下发，比较小的问题是部署节点必须double；比较大的问题的是在线扩容是个很悲剧的事情，如果有新增节点或者有删除节点，无法做到数据的自动化迁移。

基于中间层代理（Twemproxy ）

  问题难点：在现实来说应该是和一致性hash问题差不多，无法在线扩容，这是由redis造成的。

基于redis3.0 cluster

官方的集群方案，没太多突出的问题，为了高可用节点部署必须double；由于采用的gossip协议，信息延迟是必须的，这里redis3.0要求客户端有能处理（比如主节点挂掉，slot重新分配等），大体上和引用文章的说的理想化集群差不多只有有些功能放到客户端去做，有些放到节点集群agent去做；然后没有使用主从环。3.0的集群也是使用主从结构来达到高可用。至于写丢失，就不用管了。

参考redis集群规范http://redis.io/topics/cluster-spec

ps：解决负载均衡问题一般喜欢用分片，可用性问题喜欢用主从。模型简单。