redis集群的搭建

1、redis集群概念

将数据进行切片，把数据根据某种规则放入多个不同的服务器节点，来降低单节点服务器的压力。集群要实现的目的是要将不同的 key 分散放置到不同的 redis 节点。

一致性哈希有四个重要特征：

均衡性：也有人把它定义为平衡性，是指哈希的结果能够尽可能分布到所有的节点中去，这样可以有效的利用每个节点上的资源。

单调性：对于单调性是当节点数量变化时哈希的结果应尽可能的保护已分配的内容不会被重新分派到新的节点。

分散性和负载：要求一致性哈希算法对 key 哈希应尽可能的避免重复。

2、Redis 哈希槽（hash slot） 的概念

Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。使用哈希槽的好处就在于可以方便的添加或移除节点。当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了。

3、架构变化与CAP理论

在单机版的Redis中，每个Master之间是没有任何通信的， 单机版的Redis属于保证CP(Consistency & Partition-Tolerancy)而牺牲A(Availability) ， 也就说Redis能够保证所有用户看到相同的数据（一致性，因为Redis不自动冗余数据）和网络通信出问题时，暂时隔离开的子系统能继续运行（分区容忍性，因为Master之间没有直接关系，不需要通信），但是不保证某些结点故障时，所有请求都能被响应（可用性，某个Master结点挂了的话，那么它上面分片的数据就无法访问了）。

有了Cluster功能后， Redis从一个单纯的NoSQL内存 数据库 变成了分布式NoSQL数据库，CAP模型也从CP变成了AP 。 也就是说，通过自动分片和冗余数据，Redis具有了真正的分布式能力，某个结点挂了的话，因为数据在其他结点上有备份，所以其他结点顶上来就可以继续提供服务，保证了Availability。然而，也正因为这一点，Redis无法保证曾经的强一致性了。这也是CAP理论要求的，三者只能取其二。

4、集群配置

cluster-enabled yes：单机版本Redis实例不能作为集群的一部分；只有以cluster node启动的节点可以加入集群，为了以集群启动Redis实例需要开启下列参数。

cluster-config-file nodes-6379.conf：集群中每个节点都有一个配置文件，这个文件并不需要手动配置，这个配置文件有Redis生成并更新，每个Redis集群节点需要一个单独的配置文件，请确保与实例运行的系统中配置文件名称不冲突。

cluster-node-timeout ：结点超时多久则认为它宕机了。

cluster-require-full-coverage no。默认是yes， 只要有结点宕机导致16384个槽没全被覆盖，整个集群就全部停止服务 。默认情况下Redis集群各节点在检测到至少一个hash槽位遗漏的情况下会停止处理查询请求（不可达节点会处理这个遗漏的槽位），在这种情况下如果集群部分节点宕机(例如部分hash槽位没有被分配)，会造成整个集群不可用。集群直到所有槽位均被分配时才自动回复为可用状态。但是有时我们希望集群的一个子集正常工作,对active的部分keyspace继续接收并执行请求。为达到这种效果, 请将cluster-require-full-coverage。设置为no。

5、集群重启

目前redis-trib的功能还比较弱，需要重启集群的话先手动kill掉各个进程，然后重新启动就可以 。

安装gem-redis注意：

• 使用gem install redis --version 3.0.0，不过可能由于源的原因不能安装成功

到官网 http://rubygems.org/gems/redis/versions/3.0.0 下载对应的gem文件。

或者需要手工下载并安装：

wget https://rubygems.global.ssl.fastly.net/gems/redis-3.0.7.gem

gem install redis （ 安装redis-rb library ）