全面剖析Redis Cluster原理和应用 （good）

redis

redis cluster注意的问题 ：

一、‘cluster-require-full-coverage’参数的设置。该参数是redis配置文件中cluster模式的一个参数，从字面上基本就能看出它的做用：须要所有覆盖！
具体点是redis cluster须要16384个slot都正常的时候才能对外提供服务，换句话说，只要任何一个slot异常那么整个cluster不对外提供服务。
redis默认是‘yes’，即须要全覆盖！建议设置成‘no’。

二、阻塞命令产生failover。因为一些阻塞命令（flushall, del key1 key2 …）会形成redis在‘cluster-node-timeout’时间内没法响应其余节点的ping请求，
从而致使其余节点都把该redis标记出了pfail状态，进而产生failover。redis做者计划使用lazy redis解决。

三、链接创建。当redis cluster的节点数多了之后，client对每一个节点创建一个tcp链接须要花比较多的时间。若是是长链接，用户只需忍受一次链接创建的过程，
若是是短链接，那么频繁创建链接将会极大的下降效率。但即使是短链接，只要每次请求只涉及到一个key，有些客户端可能只须要与一个节点创建链接。

四、Jedis。Jedis是redis最流行的Java客户端，支持redis cluster。
‘MaxRedirectionsException’异常，出现该异常说明刚刚执行的那条命令通过屡次重试，没有执行成功，须要用户再次执行。
在cluster扩容或者slot迁移的时候比较容易出现。建议捕获该异常并采起相应重试工做。
Pipeline，Jedis目前不支持cluster模式的pipeline，建议采用多并发代替pipeline。

五、Multi-key。Redis cluster对多key操做有限，要求命令中全部的key都属于一个slot，才能够被执行。客户端能够对multi-key命令进行拆分，再发给redis。
另一个局限是，在slot迁移过程当中，multi-key命令特别容易报错(CROSSSLOT Keys in request don’t hash to the same slot)。建议不用multi-key命令。

六、扩容速度慢。redis官方提供了redis cluster管理脚本redis-trib.rb。使用该脚本进行扩容cluster的时候，是串行的迁移slot中的每一个key，这样致使了
扩容的速度很是慢，百G的数据要数小时。扩容时间越长，越容易出现异常。

http://www.ithao123.cn/content-10677390.html

先有鸡仍是先有蛋？

最近有朋友问了一个问题，说毕业后去大城市仍是小城市？去大公司仍是小公司？个人回答都是大城市！大公司！
为何这么说呢，你想一下，不管女孩男孩找朋友都喜欢找个子高胸大的。一样的道理嘛，「大」总有大的好。
固然，若是你要有能力找一个胸大个子高就更完美了。

Redis 集群简介

Redis 是一个开源的 key-value 存储系统，因为出众的性能，大部分互联网企业都用来作服务器端缓存。Redis 在3.0版本前只支持单实例模式，虽然支持主从模式、哨兵模式部署来解决单点故障，可是如今互联网企业动辄大几百G的数据，可彻底是无法知足业务的需求，因此，Redis 在 3.0 版本之后就推出了集群模式。

Redis 集群采用了P2P的模式，彻底去中心化。Redis 把全部的 Key 分红了 16384 个 slot，每一个 Redis 实例负责其中一部分 slot 。集群中的全部信息（节点、端口、slot等），都经过节点之间按期的数据交换而更新。
Redis 客户端能够在任意一个 Redis 实例发出请求，若是所需数据不在该实例中，经过重定向命令引导客户端访问所需的实例。

随随便便搭建一个集群

安装部署任何一个应用其实都很简单，只要安装步骤一步一步来就好了。下面说一下 Redis 集群搭建规划，因为集群至少须要6个节点（3主3从模式），因此，没有这么多机器给我玩，我本地也起不了那么多虚拟机（电脑太烂），如今计划是在一台机器上模拟一个集群，固然，这和生产环境的集群搭建没本质区别。

我如今就要在已经有安装了 Redis 的一个 CentOS 下开始进行集群搭建，若是你还不是很清楚 Linux 下如何安装 Redis ，能够去看这一篇文章《了解一下 Redis 并在 CentOS 下进行安装配置》。请注意，下面全部集群搭建环境都基于已安装好的 Redis 作的。

1.建立文件夹
咱们计划集群中 Redis 节点的端口号为 9001-9006 ，端口号即集群下各实例文件夹。数据存放在 端口号/data 文件夹中。

mkdir /usr/local/redis-cluster
cd redis-cluster/
mkdir -p 9001/data 9002/data 9003/data 9004/data 9005/data 9006/data

 

2.复制执行脚本
在 /usr/local/redis-cluster 下建立 bin 文件夹，用来存放集群运行脚本，并把安装好的 Redis 的 src 路径下的运行脚本拷贝过来。看命令：

mkdir redis-cluster/bin
cd /usr/local/redis/src
cp mkreleasehdr.sh redis-benchmark redis-check-aof redis-check-dump redis-cli redis-server redis-trib.rb /usr/local/redis-cluster/bin

3.复制一个新 Redis 实例
咱们如今从已安装好的 Redis 中复制一个新的实例到 9001 文件夹，并修改 redis.conf 配置。

cp /usr/local/redis/* /usr/local/redis-cluster/9001

 

注意，修改  配置和单点惟一区别是下图部分，其他仍是常规的这几项：redis.conf

port 9001（每一个节点的端口号）
daemonize yes
bind 192.168.119.131（绑定当前机器 IP）
dir /usr/local/redis-cluster/9001/data/（数据文件存放位置）
pidfile /var/run/redis_9001.pid（pid 9001和port要对应）
cluster-enabled yes（启动集群模式）
cluster-config-file nodes9001.conf（9001和port要对应）
cluster-node-timeout 15000
appendonly yes

集群搭建配置重点就是取消下图中的这三个配置：

4.再复制出五个新 Redis 实例
咱们已经完成了一个节点了，其实接下来就是机械化的再完成另外五个节点，其实能够这么作：把 9001 实例 复制到另外五个文件夹中，惟一要修改的就是 redis.conf 中的全部和端口的相关的信息便可，其实就那么四个位置。开始操做，看图：

\cp -rf /usr/local/redis-cluster/9001/* /usr/local/redis-cluster/9002
\cp -rf /usr/local/redis-cluster/9001/* /usr/local/redis-cluster/9003
\cp -rf /usr/local/redis-cluster/9001/* /usr/local/redis-cluster/9004
\cp -rf /usr/local/redis-cluster/9001/* /usr/local/redis-cluster/9005
\cp -rf /usr/local/redis-cluster/9001/* /usr/local/redis-cluster/9006

\cp -rf 命令是不使用别名来复制，由于 cp 实际上是别名 cp -i，操做时会有交互式确认，比较烦人。

5.修改 9002-9006 的 redis.conf 文件
其实很是简单了，你经过搜索会发现其实只有四个点须要修改，咱们全局替换下吧，进入相应的节点文件夹，作替换就行了。命令很是简单，看图：

vim redis.conf
:%s/9001/9002g

回车后，就会有替换几个地方成功的提示，不放心能够手工检查下：

其实咱们也就是替换了下面这四行：

port 9002
dir /usr/local/redis-cluster/9002/data/
cluster-config-file nodes-9002.conf
pidfile /var/run/redis_9002.pid

到这里，咱们已经把最基本的环境搞定了，接下来就是启动了。

其实咱们已经几乎搭建好了

1.启动 9001-9006 六个节点
少废话，直接看图：

/usr/local/bin/redis-server /usr/local/redis-cluster/9001/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9002/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9003/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9004/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9005/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9006/redis.conf

 

能够检查一下是否启动成功：ps -el | grep redis
看的出来，六个节点已经所有启动成功了。

2.随便找一个节点测试试

/usr/local/redis-cluster/bin/redis-cli -h 192.168.119.131 -p 9001

set name mafly

 

链接成功了，但好像报错了阿？？？
(error) CLUSTERDOWN Hash slot not served（不提供集群的散列槽），这是什么鬼？
这是由于虽然咱们配置并启动了 Redis 集群服务，可是他们暂时还并不在一个集群中，互相直接发现不了，并且尚未可存储的位置，就是所谓的slot（槽）。

3.安装集群所需软件
因为 Redis 集群须要使用 ruby 命令，因此咱们须要安装 ruby 和相关接口。

yum install ruby
yum install rubygems
gem install redis 

 

这才是真正的建立集群

先不废话，直接敲命令：

/usr/local/redis-cluster/bin/redis-trib.rb create --replicas 1 192.168.119.131:9001 192.168.119.131:9002 192.168.119.131:9003 192.168.119.131:9004 192.168.119.131:9005 192.168.119.131:9006

简单解释一下这个命令：调用 ruby 命令来进行建立集群，--replicas 1 表示主从复制比例为 1:1，即一个主节点对应一个从节点；而后，默认给咱们分配好了每一个主节点和对应从节点服务，以及 solt 的大小，由于在 Redis 集群中有且仅有 16383 个 solt ，默认状况会给咱们平均分配，固然你能够指定，后续的增减节点也能够从新分配。

M: 10222dee93f6a1700ede9f5424fccd6be0b2fb73 为主节点Id

S: 9ce697e49f47fec47b3dc290042f3cc141ce5aeb 192.168.119.131:9004 replicates 10222dee93f6a1700ede9f5424fccd6be0b2fb73 从节点下对应主节点Id

目前来看，9001-9003 为主节点，9004-9006 为从节点，并向你确认是否赞成这么配置。输入 yes 后，会开始集群建立。

上图则表明集群搭建成功啦！！！

验证一下：
依然是经过客户端命令链接上，经过集群命令看一下状态和节点信息等。

/usr/local/redis-cluster/bin/redis-cli -c -h 192.168.119.131 -p 9001 cluster info cluster nodes

经过命令，能够详细的看出集群信息和各个节点状态，主从信息以及链接数、槽信息等。这么看到，咱们已经真的把 Redis 集群搭建部署成功啦！

设置一个 mafly：
你会发现，当咱们 set name mafly 时，出现了 Redirected to slot 信息并自动链接到了9002节点。这也是集群的一个数据分配特性，这里不详细说了。

总结一下

这一篇 Redis 集群部署搭建的文章真的是一步一步的走下来的，只要你安装个人步骤来，就保证你能成功搭建一个 Redis 集群玩玩，也能够这么说，除了步骤繁琐外，几乎不存在技术含量，估计能看完的人都感受累（说真的，写这种文章真的很累人）。

接下来可能就是动态扩容、增长节点和减小节点，从新分配槽大小等，固然，还有最重要的就是怎么和咱们程序结合起来，以及如何更好的把 Redis 缓存集群发挥出应有的效果，这些才是最重要的。

http://www.cnblogs.com/mafly/p/redis_cluster.html

 

 

redis3.0 cluster功能介绍

redis从3.0开始支持集群功能。redis集群采用无中心节点方式实现，无需proxy代理，客户端直接与redis集群的每一个节点链接，根据一样的hash算法计算出key对应的slot，而后直接在slot对应的redis上执行命令。在redis看来，响应时间是最苛刻的条件，增长一层带来的开销是redis不缘由接受的。所以，redis实现了客户端对节点的直接访问，为了去中心化，节点之间经过gossip协议交换互相的状态，以及探测新加入的节点信息。redis集群支持动态加入节点，动态迁移slot，以及自动故障转移。

集群架构
每一个节点都会跟其余节点保持链接，用来交换彼此的信息。节点组成集群的方式使用cluster meet命令，meet命令可让两个节点相互握手，而后经过gossip协议交换信息。若是一个节点r1在集群中，新节点r2加入的时候与r1节点握手，r1节点会把集群内的其余节点信息经过gossip协议发送给r2，r2会一一与这些节点完成握手，从而加入到集群中。
节点在启动的时候会生成一个全局的标识符，并持久化到配置文件，在节点与其余节点握手后，这些信息也都持久化下来。节点与其余节点通讯，标识符是它惟一的标识，而不是IP、PORT地址。若是一个节点移动位置致使IP、PORT地址发生变动，集群内的其余节点能把该节点的IP、PORT地址纠正过来。

集群数据分布
集群数据以数据分布表的方式保存在各个slot上。默认的数据分布表默认含有16384个slot。
key与slot映射使用的CRC16算法，即：slot = CRC16(key) mod 16384。
集群只有在16384个slot都有对应的节点才能正常工做。slot能够动态的分配、删除和迁移。
每一个节点会保存一份数据分布表，节点会将本身的slot信息发送给其余节点，发送的方式使用一个unsigned char的数组，数组长度为16384/8。每一个bit标识为0或者1来标识某个slot是不是它负责的。

使用这样的方式传输，就能大大减小数据分布表的字节。这种方式使用的字节为2048，若是纯粹的传递数据分布表，那边一个slot至少须要2字节的slot值+2字节port+4字节ip，共8*16384=131072字节，或者以ip、port为键，把节点对应的slot放在后面，那么也至少须要2*16384加上节点的数量，也远远大于2048字节。因为节点间不停的在传递数据分布表，因此为了节省带宽，redis选择了只传递本身的分布数据。但这样的方式也会带来管理方面的麻烦，若是一个节点删除了本身负责的某个slot，这样该节点传递给其余节点数据分布表的slot标识为0，而redis采用了bitmapTestBit方法，只处理slot为1的节点，而并未把每一个slot与收到的数据分布表对比，从而产生了节点间数据分布表视图的不一致。这种问题目前只能经过使用者来避免。

redis目前还支持slot的迁移，能够把一个slot从一个节点迁移到另外一个节点，节点上的数据须要使用者经过cluster getkeysinslot去除迁移slot上的key，而后执行migrate命令一个个迁移到新节点。具体细节会在下面的slot迁移章节介绍。

集群访问
客户端在初始化的时候只须要知道一个节点的地址便可，客户端会先尝试向这个节点执行命令，好比“get key”，若是key所在的slot恰好在该节点上，则可以直接执行成功。若是slot不在该节点，则节点会返回MOVED错误，同时把该slot对应的节点告诉客户端。客户端能够去该节点执行命令。目前客户端有两种作法获取数据分布表，一种就是客户端每次根据返回的MOVED信息缓存一个slot对应的节点，可是这种作法在初期会常常形成访问两次集群。还有一种作法是在节点返回MOVED信息后，经过cluster nodes命令获取整个数据分布表，这样就能每次请求到正确的节点，一旦数据分布表发生变化，请求到错误的节点，返回MOVED信息后，从新执行cluster nodes命令更新数据分布表。

在访问集群的时候，节点可能会返回ASK错误。这种错误是在key对应的slot正在进行数据迁移时产生的，这时候向slot的原节点访问，若是key在迁移源节点上，则该次命令能直接执行。若是key不在迁移源节点上，则会返回ASK错误，描述信息会附上迁移目的节点的地址。客户端这时候要先向迁移目的节点发送ASKING命令，而后执行以前的命令。

这些细节通常都会被客户端sdk封装起来，使用者彻底感觉不到访问的是集群仍是单节点。

集群支持hash tags功能，便可以把一类key定位到同一个节点，tag的标识目前支持配置，只能使用{}，redis处理hash tag的逻辑也很简单，redis只计算从第一次出现{，到第一次出现}的substring的hash值，substring为空，则仍然计算整个key的值，这样对于foo{}{bar}、{foo}{bar}、foo这些冲突的{}，也能取出tag值。使用者需遵循redis的hash tag规范。

127.0.0.1:6379> CLUSTER KEYSLOT foo{hash_tag}
(integer) 2515
127.0.0.1:6379> CLUSTER KEYSLOT fooadfasdf{hash_tag}
(integer) 2515
127.0.0.1:6379> CLUSTER KEYSLOT fooadfasdfasdfadfasdf{hash_tag}
(integer) 2515
集群版本的redis可以支持所有的单机版命令。不过仍是有些命令会有些限制。

订阅在使用上与单机版没有任何区别。订阅功能经过集群间共享publish消息实现的，客户端能够向任意一个节点（包括slave节点）订阅消息，而后在一个节点上执行的publish命令，该节点会把该命令传播给集群内的每一个节点，这样订阅该消息的客户端就能收到该命令。

redis集群版只使用db0，select命令虽然可以支持select 0。其余的db都会返回错误。
127.0.0.1:6379> select 0
OK
127.0.0.1:6379> select 1
(error) ERR SELECT is not allowed in cluster mode
redis集群版对多key命令的支持，只能支持多key都在同一个slot上，即便多个slot在一个节点上也不行。

127.0.0.1:6379> mget key7 key28
(error) CROSSSLOT Keys in request don't hash to the same slot
事务的支持只能在也一个slot上完成。MULTI命令以后的命令的key必须都在同一个slot上，若是某条命令的key对应不在相同的slot上，则事务直接回滚。迁移的时候，在迁移源节点执行命令的key必须在移原节点上存在，不然事务就会回滚。在迁移目的节点执行的时候须要先执行ASKING命令再执行MULTI命令，这样接下来该slot的命令都能被执行。能够看出，对于单key和相同hash tags的事务，集群仍是能很好的支持。

在迁移的时候有个地方须要注意，对于多key命令在迁移目的节点执行时，若是多个key全在该节点上，则命令没法执行。以下所示，key和key14939对应的slot为12539，执行命令的节点是迁移目的节点：

127.0.0.1:6379> asking
OK
127.0.0.1:6379> mget key key14939
(error) TRYAGAIN Multiple keys request during rehashing of slot

集群消息
集群间互相发送消息，使用另外的端口，全部的消息在该端口上完成，能够成为消息总线，这样能够作到不影响客户端访问redis，可见redis对于性能的追求。目前集群有以下几种消息：

CLUSTERMSG_TYPE_PING：gossip协议的ping消息。
CLUSTERMSG_TYPE_PONG：gossip协议的pong消息。
CLUSTERMSG_TYPE_MEET：握手消息。
CLUSTERMSG_TYPE_FAIL：master节点检测到，超过半数master认为某master离线，则发送fail消息。
CLUSTERMSG_TYPE_PUBLISH：publish消息，向其余节点推送消息。
CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST：故障转移时，slave发送向其余master投票请求。
CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK：故障转移时，其余master回应slave的请求。
CLUSTERMSG_TYPE_UPDATE：通知某节点，它负责的某些slot被另外一个节点替换。
CLUSTERMSG_TYPE_MFSTART：手动故障转移时，slave请求master中止访问，从而对比二者的数据偏移量，能够达到一致。
集群节点间相互通讯使用了gossip协议的push/pull方式，ping和pong消息，节点会把本身的详细信息和已经和本身完成握手的3个节点地址发送给对方，详细信息包括消息类型，集群当前的epoch，节点本身的epoch，节点复制偏移量，节点名称，节点数据分布表，节点master的名称，节点地址，节点flag为，节点所处的集群状态。节点根据本身的epoch和对方的epoch来决定哪些数据须要更新，哪些数据须要告诉对方更新。而后根据对方发送的其余地址信息，来发现新节点的加入，从而和新节点完成握手。

节点默认每秒在集群中的其余节点选择一个节点，发送ping消息。选择节点步骤是：

随机 5 个节点。
跳过断开链接和已经在ping还没收到pong响应的节点。
从筛选的节点中选择最近一次接收pong回复距离如今最旧的节点。
除了常规的选择节点外，对于那些一直未随机到节点，redis也有所支持。当有节点距离上一次接收到pong消息超过节点超时配置的一半，节点就会给这些节点发送ping消息。

ping消息会带上其余节点的信息，选择其余节点步骤是：

最多选择3个节点。
最多随机遍历6个节点，若是由于一些条件不能被选出，可能会不满3个。
忽略本身。
忽略正在握手的节点。
忽略带有 NOADDR 标识的节点。
忽略链接断开并且没有负责任何slot的节点。
ping消息会把发送节点的ping_sent改为当前时间，直到接收到pong消息，才更新ping_sent为0。当ping消息发送后，超过节点超时配置的一半，就会把发送节点的链接断开。超过节点超时配置，就会认为该节点已经下线。

接收到某个节点发来的ping或者pong消息，节点会更新对接收节点的认识。好比该节点主从角色是否变化，该节点负责的slot是否变化，而后获取消息带上的节点信息，处理新节点的加入。

slot更新这里要细说下。假设这里是节点A接收到节点B的消息。A节点会取出保存的B节点的分布表与消息的分布表进行对比，B节点若是是slave，则比较的是A节点保存的B的master的分布表和消息中的分布表。比较只是使用memcmp简单的比较两份数据是否同样，同样则无需处理，不同就处理不一致的slot。更新的时候，这里只是处理消息中分布表为1的slot。若是和A节点保持一致或者该slot正准备迁移到A节点，则继续处理。若是slot产生了冲突，则以epoch大的为准。若是冲突的slot中有A本身负责的节点，并且B比A的epoch大致使须要更新slot为B负责，此时A负责的slot为0的时候，能够认为B是A的slave。这种状况常常发生在A由原来的master变成slave，B提高为master的场景下。

前面说到slot更新的时候，若是B比A的epoch大，则A更新对slot的认识。若是A比B的epoch大， 在redis接下来的逻辑会再次处理，A会给B发送update消息，B收到A发送的update消息，执行slot更新方法。这种状况也常常发生在主从切换的时候。第一种状况发生在新master把数据分布表推给旧master。第二种状况发生在旧master给新master发消息的时候，新master给旧master发送update消息。

slot迁移
redis cluster支持slot的动态迁移，迁移须要按照指定步骤进行，否则可能破坏当前的集群数据分布表。cluster setslot <slot> IMPORTING <node ID>命令在迁移目的节点执行，表示须要把该slot迁移到本节点。redis的cluster setslot命令提供了对迁移的支持。cluster setslot <slot> MIGRATING <node ID>命令在迁移源节点执行，表示须要把该slot迁出。cluster setslot <slot> NODE <node ID>在迁移完成后在迁移源节点和迁移目的节点执行后，表示迁移完成，数据分布表恢复稳定。若是须要取消迁移操做，在迁移源节点和迁移目的节点上执行cluster setslot <slot> STABLE。

下面先来看一下完整的迁移流程：

在迁移目的节点执行cluster setslot <slot> IMPORTING <node ID>命令，指明须要迁移的slot和迁移源节点。
在迁移源节点执行cluster setslot <slot> MIGRATING <node ID>命令，指明须要迁移的slot和迁移目的节点。
在迁移源节点执行cluster getkeysinslot获取该slot的key列表。
在迁移源节点执行对每一个key执行migrate命令，该命令会同步把该key迁移到目的节点。
在迁移源节点反复执行cluster getkeysinslot命令，直到该slot的列表为空。
在迁移源节点和目的节点执行cluster setslot <slot> NODE <node ID>，完成迁移操做。

迁移过程当中该slot容许继续有流量进来，redis保证了迁移过程当中slot的正常访问。在迁移过程当中，对于该slot的请求，若是key在源节点，则表示该key尚未迁移到目的节点。源节点会返回ASK错误，告诉客户端去迁移目的节点请求。这样新的key就直接写入到迁移目的节点了。客户端写入目的节点前须要发送ASKING命令，告诉迁移目的节点我是写入增量数据，没有ASKING命令，迁移目的节点会不认此次请求，返回MOVED错误，告诉客户端去迁移源节点请求。

凭借ASK机制和migrate命令，redis能保证slot的全量数据和增量数据都能导入目的节点。由于对于源节点返回了ASK错误，就能保证该key不在源节点上，那么它只会出如今目的节点或者不存在。因此客户端获取ASK错误到向目的节点无需保证原子性。而后migrate命令是个原子操做，它会等待目的节点写入成功才在源节点返回，保证了迁移期间不接受其余请求，从一个外部客户端的视角来看，在某个时间点上，迁移的键要么存在于源节点，要么存在于目的节点，但不会同时存在于源节点和目的节点。

迁移过程当中几乎不影响用户使用，除了在多key的命令在迁移目的节点没法执行，这个在集群访问已经说明。

不过因为migrate命令是同步阻塞执行的，因此若是key对应的value很大，会增长阻塞时间，特别对于list、set、zset等结构若是value很大的话，redis并不关心这些结构的长度，而是直接以key为单位一次性迁移。同时迁移过程当中大量执行migrate命令，会增长客户端的响应时间。

迁移的时候在master出现异常的时候，迁移工做须要作些处理。
若是在迁移过程当中，源节点宕机，此时需作以下调整:
目的节点执行cluster setslot <slot> IMPORTING <node ID>命令，node ID为源节点group的新master
源节点group内的新master执行cluster setslot <slot> MIGRATING <node ID>命令，迁移该slot到目的节点。
这样能够继续完成迁移操做。

若是在迁移过程当中，目的节点宕机，此时需作以下调整:
目的节点group内的新master执行cluster setslot <slot> IMPORTING <node ID>命令，node ID为源节点。
源节点执行cluster setslot <slot> MIGRATING <node ID>命令，迁移该slot到目的节点group内的新master。
这样也能够继续完成迁移操做。

主从复制
集群间节点支持主从关系，复制的逻辑基本复用了单机版的实现。不过仍是有些地方须要注意。
首先集群间节点创建主从关系再也不使用原有的SLAVEOF命令和SLAVEOF配置，而是经过cluster replicate命令，这保证了主从节点须要先完成握手，才能创建主从关系。
集群是不能组成链式主从关系的，也就是说从节点不能有本身的从节点。不过对于集群外的没开启集群功能的节点，redis并不干预这些节点去复制集群内的节点，可是在集群故障转移时，这些集群外的节点，集群不会处理。
集群内节点想要复制另外一个节点，须要保证本节点再也不负责任何slot，否则redis也是不容许的。
集群内的从节点在与其余节点通讯的时候，传递的消息中数据分布表和epoch是master的值。

故障转移

集群主节点出现故障，发生故障转移时，其余主节点会把故障主节点的从节点自动提为主节点，原来的主节点恢复后，自动成为新主节点的从节点。

这里先说明，把一个master和它的所有slave描述为一个group，故障转移是以group为单位的，集群故障转移的方式跟sentinel的实现很相似。某个节点一段时间没收到心跳响应，则集群内的master会把该节点标记为pfail，相似sentinel的sdown。集群间的节点会交换相互的认识，超过一半master认为该异常master宕机，则这些master把异常master标记为fail，相似sentinel的odown。fail消息会被master广播出来。group的slave收到fail消息后开始竞选成为master。竞选的方式跟sentinel选主的方式相似，都是使用了raft协议，slave会从其余的master拉取选票，票数最多的slave被选为新的master，新master会立刻给集群内的其余节点发送pong消息，告知本身角色的提高。其余slave接着开始复制新master。等旧master上线后，发现新master的epoch高于本身，经过gossip消息交互，把本身变成了slave。大体就是这么个流程。自动故障转移的方式跟sentinel很像，

redis还支持手动的故障转移，即经过在slave上执行cluster failover命令，可让slave提高为master。failover命令支持传入FORCE和TAKEOVER参数。

FORCE：使用FORCE参数与sentinel的手动故障转移流程基本相似，强制开始一次故障转移。
不传入额外参数：若是主节点异常，则不能进行failover，主节点正常的状况下须要先比较从节点和主节点的偏移量，此时会让主节点中止客户端请求，直到超时或者故障转移完成。主从偏移量相同后开始手动故障转移流程。
TAKEOVER：这种手动故障转移的方式比较暴力，slave直接提高本身的epoch为最大的epoch。并把本身变成master。这样在消息交互过程当中，旧master能发现本身的epoch小于该slave，同时二者负责的slot一致，它会把本身降级为slave。

均衡集群的slave（Replica migration）

在集群运行过程当中，有的master的slave宕机，致使了该master成为孤儿master（orphaned masters），而有的master有不少slave。此处孤儿master的定义是那些原本有slave，可是所有离线的master，对于那些原来就没有slave的master不能认为是孤儿master。redis集群支持均衡slave功能，官方称为Replica migration，而我以为均衡集群的slave更好理解该概念。集群能把某个slave较多的group上的slave迁移到那些孤儿master上，该功能经过cluster-migration-barrier参数配置，默认为1。slave在每次定时任务都会检查是否须要迁移slave，即把本身变成孤儿master的slave。 知足如下条件，slave就会成为孤儿master的slave：

本身所在的group是slave最多的group。
目前存在孤儿master。
本身所在的group的slave数目至少超过2个，只有本身一个的话迁移到其余group，本身原来的group的master又成了孤儿master。
本身所在的group的slave数量大于cluster-migration-barrier配置。
与group内的其余slave基于memcmp比较node id，本身的node id最小。这个能够防止多个slave并发复制孤儿master，从而原来的group失去过多的slave。

网络分区说明

redis的集群模式下，客户端须要和所有的节点保持链接，这样可能出现网络分区问题，客户端和一些节点在一个网络分区，另外一部分节点在另外一个网络分区。在分区期间，客户端仍然能执行命令，直到集群通过cluster-node-timeout发现分区状况，节点探测到有slot没法提供服务，才开始禁止客户端执行命令。

这时候会出现一种现象，假设客户端和一个master在小分区，其余节点在大分区。超时后，其余节点共同投票把group内的一个slave提为master，等分区恢复。旧的master会成为新master的slave。这样在cluster-node-timeout期间对旧master的写入数据都会丢失。
这个问题能够经过设置cluster-node-timeout来减小不一致。若是对一致性要求高的应用还能够经过min-slaves-to-write配置来提升写入的要求。

slot保存key列表

redis提供了cluster countkeysinslot和cluster getkeysinslot命令，能够得到某个slot的所有key列表。经过该列表，能够实现slot的迁移。该功能是经过skiplist实现的，skiplist是redis内部用来实现zset的数据结构，在slot保持key的时候也派上了用场。redis全部在db层对hash表的操做，也会在skiplist上执行相应的操做。好比往hash表增长数据，redis也会往skiplist也写一份数据，该skiplist的score就是slot的值，value对应了具体的key。这等因而redis在数据分布表上冗余了全部的key。不过相比skiplist所带来迁移的方便，冗余的结果是能够接受的，这也指望客户端，不要使用过长的key，从而增长内存的消耗。

附录1：集群相关命令

cluster meet ip:port
集群间相互握手，加入彼此所在的集群。（将指定节点加入到集群）

cluster nodes
获取集群间节点信息的列表，以下所示，格式为<node ID> <node IP:PORT> <node role> [master node ID|-] <node ping_sent> <node pong_received> <node epoch> <node status>。

127.0.0.1:6379> cluster nodes
a15705fdb7cac60e07ff699bf4c514e80f245a2c 10.180.157.205:6379 slave 2b5603326d0fca28031467727fae4558115a99d8 0 1450854214289 11 connected
6477541e4594e60e095c8f440882636236545936 10.180.157.202:6379 slave 9b35a393fa6623887215023b761d531dde452d3c 0 1450854211276 12 connected
ecf9ae60e87ea3358d9c5f1f269e0ed9a387ea40 10.180.157.201:6379 master - 0 1450854214788 5 connected 10923-16383
2b5603326d0fca28031467727fae4558115a99d8 10.180.157.200:6379 master - 0 1450854213283 11 connected 5461-10922
f31f6ce49b3a2f3a246b2d97349c8f8614cf3a2c 10.180.157.208:6379 slave ecf9ae60e87ea3358d9c5f1f269e0ed9a387ea40 0 1450854212286 9 connected
9b35a393fa6623887215023b761d531dde452d3c 10.180.157.199:6379 myself,master - 0 0 12 connected 0-5460

cluster myid
返回节点的id。
127.0.0.1:6379> cluster myid
"9b35a393fa6623887215023b761d531dde452d3c"

cluster slots
返回集群间节点负责的数据分布表。
127.0.0.1:6379> cluster slots
1) 1) (integer) 10923
2) (integer) 16383
3) 1) "10.180.157.201"
2) (integer) 6379
4) 1) "10.180.157.208"
2) (integer) 6379
2) 1) (integer) 5461
2) (integer) 10922
3) 1) "10.180.157.200"
2) (integer) 6379
4) 1) "10.180.157.205"
2) (integer) 6379
3) 1) (integer) 0
2) (integer) 5460
3) 1) "10.180.157.199"
2) (integer) 6379
4) 1) "10.180.157.202"
2) (integer) 6379

cluster flushslots
清空该节点负责slots，必须在节点负责的这些slot都没有数据的状况下才能执行，该命令须要谨慎使用，因为以前说的bitmapTestBit方法，redis只比较负责的节点，清空的slots信息没法被其余节点同步。

cluster addslots [slot]
在当前节点上增长slot。（将指定的一个或多个slot 指派给当前节点）

cluster delslots [slot]
在节点上取消slot的负责。这也会致使前面说的slot信息没法同步，并且一旦集群有slot不负责，配置cluster-require-full-coverage为yes的话，该节点就没法提供服务了，因此使用也需谨慎。

cluster setslot <slot> MIGRATING <nodeid>
把本节点负责的某个slot设置为迁移到目的节点。(即将本节点的slot指派给或叫迁移到指定的节点)

cluster setslot <slot> IMPORTING <nodeid>
设置某个slot为从迁移源节点迁移标志。(即将指定节点的slot指派给或叫迁移到本节点)

cluster setslot <slot> STABLE
设置某个slot为从迁移状态恢复为正常状态。(取消slot的导入（importing）或迁移（migrating）)

cluster setslot <slot> NODE <nodeid>
设置某个slot为某节点负责。该命令使用也须要注意，cluster setslot的四个命令须要配置迁移工具使用，单独使用容易引发集群混乱。该命令在集群出现异常时，须要指定某个slot为某个节点负责时，最好在每一个节点上都执行一遍，至少要在迁移的节点和最高epoch的节点上执行成功。(将指定的slot指派给指定的节点，若是该slot已经指派给另外一个节点，则要另外一个节点先删除该slot)

cluster info
集群的一些info信息。
127.0.0.1:6379> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:12
cluster_my_epoch:12
cluster_stats_messages_sent:1449982
cluster_stats_messages_received:1182698

cluster saveconfig
保存集群的配置文件，集群默认在配置修改的时候会自动保存配置文件，该方法也能手动执行命令保存。

cluster keyslot
能够查询某个key对应的slot地址。
127.0.0.1:6379> cluster keyslot key
(integer) 12539

cluster countkeysinslot
能够查询该节点负责的某个slot内部key的数量。
127.0.0.1:6379> cluster countkeysinslot 13252
(integer) 2

cluster getkeysinslot <slot> <count>
能够查询该节点负责的某个slot内部指定数量的key列表。
127.0.0.1:6379> cluster getkeysinslot 13252 10
1) "key0"
2) "key2298"

cluster forget
把某个节点加入黑名单，这样就没法完成握手。黑名单的过时时为60s，60s后两节点又会继续完成握手。

cluster replicate <nodeid>
负责某个节点，成为它的slave。（将当前节点设置为指定nodeid节点的从节点）

cluster slaves
列出某个节点slave列表。
127.0.0.1:6379> cluster slaves 2b5603326d0fca28031467727fae4558115a99d8
1) "a15705fdb7cac60e07ff699bf4c514e80f245a2c 10.180.157.205:6379 slave 2b5603326d0fca28031467727fae4558115a99d8 0 1450854932667 11 connected"

cluster count-failure-reports
列出某个节点的故障转移记录的长度。

cluster failover [FORCE|TAKEOVER]
手动执行故障转移。

cluster set-config-epoch
设置节点epoch，只有在节点加入集群前才能设置。

cluster reset [SOFT|HARD]
重置集群信息，soft是清空其余节点的信息，但不修改本身的id。hard还会修改本身的id。不传该参数则使用soft方式。

readonly
在slave上执行，执行该命令后，能够在slave上执行只读命令。

readwrite
在slave上执行，执行该命令后，取消在slave上执行命令。

附录2：集群相关配置
cluster-enabled
说明：集群开关，默认是不开启集群模式。
默认值:no。
是否能够动态修改:no。
值的范围:yes|no。

cluster-config-file
说明：集群配置文件的名称，每一个节点都有一个集群相关的配置文件，持久化保存集群的信息。
默认值:”nodes.conf”。
是否能够动态修改:no。
值的范围:文件路径。

cluster-node-timeout
说明：节点的超时时间，单位是毫秒。
默认值:15000。
是否能够动态修改:yes。
值的范围:大于0。

cluster-slave-validity-factor
说明：在进行故障转移的时候，group的所有slave都会请求申请为master，可是有些slave可能与master断开链接一段时间了，致使数据过于陈旧，这样的slave不该该被提高为master。该参数就是用来判断slave节点与master断线的时间是否过长。判断方法是比较slave断开链接的时间和(node-timeout * slave-validity-factor) + repl-ping-slave-period。
默认值:10。
是否能够动态修改:yes。
值的范围:大于等于0。

cluster-migration-barrier
说明：master的slave数量大于该值，slave才能迁移到其余孤儿master上，具体说明见均衡集群的slave章节。
默认值:1。
是否能够动态修改:yes。
值的范围:大于等于0。

cluster-require-full-coverage
说明：默认状况下，集群所有的slot有节点负责，集群状态才为ok，才能提供服务。设置为no，能够在slot没有所有分配的时候提供服务。不建议打开该配置，这样会形成分区的时候，小分区的master一直在接受写请求，而形成很长时间数据不一致。
默认值:yes。
是否能够动态修改:yes。
值的范围:yes|no。

 

 

 

 

1.Redis Cluster总览

1.1 设计原则和初衷

在官方文档Cluster Spec中，做者详细介绍了Redis集群为何要设计成如今的样子。最核心的目标有三个：

1. 性能：这是Redis赖以生存的看家本领，增长集群功能后固然不能对性能产生太大影响，因此Redis采起了P2P而非Proxy方式、异步复制、客户端重定向等设计，而牺牲了部分的一致性、使用性。
2. 水平扩展：集群的最重要能力固然是扩展，文档中称能够线性扩展到1000结点。
3. 可用性：在Cluster推出以前，可用性要靠Sentinel保证。有了集群以后也自动具备了Sentinel的监控和自动Failover能力。

1.2 架构变化与CAP理论

Redis Cluster集群功能推出已经有一段时间了。在单机版的Redis中，每一个Master之间是没有任何通讯的，因此咱们通常在Jedis客户端或者Codis这样的代理中作Pre-sharding。按照CAP理论来讲，单机版的Redis属于保证CP(Consistency & Partition-Tolerancy)而牺牲A(Availability)，也就说Redis可以保证全部用户看到相同的数据（一致性，由于Redis不自动冗余数据）和网络通讯出问题时，暂时隔离开的子系统能继续运行（分区容忍性，由于Master之间没有直接关系，不须要通讯），可是不保证某些结点故障时，全部请求都能被响应（可用性，某个Master结点挂了的话，那么它上面分片的数据就没法访问了）。

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

关于CAP理论的通俗讲解，请参考个人译文《多是CAP理论的最好解释 》。简单分析了Redis在架构上的变化后，我们就一块儿来体验一下Redis Cluster功能吧！

---

2.Redis集群初探

Redis的安装很简单，之前已经介绍过，就不详细说了。关于Redis Cluster的基础知识以前也有过整理，请参考《Redis集群功能预览》。若是须要全面的了解，那必定要看官方文档Cluster Tutorial，只看这一个就够了！

2.1 集群配置

要想开启Redis Cluster模式，有几项配置是必须的。此外为了方便使用和后续的测试，我还额外作了一些配置：

• 绑定地址：bind 192.168.XXX.XXX。不能绑定到127.0.0.1或localhost，不然指导客户端重定向时会报”Connection refused”的错误。
• 开启Cluster：cluster-enabled yes
• 集群配置文件：cluster-config-file nodes-7000.conf。这个配置文件不是要咱们去配的，而是Redis运行时保存配置的文件，因此咱们也不能够修改这个文件。
• 集群超时时间：cluster-node-timeout 15000。结点超时多久则认为它宕机了。
• 槽是否全覆盖：cluster-require-full-coverage no。默认是yes，只要有结点宕机致使16384个槽没全被覆盖，整个集群就所有中止服务，因此必定要改成no
• 后台运行：daemonize yes
• 输出日志：logfile “./redis.log”
• 监听端口：port 7000

配置好后，根据咱们的集群规模，拷贝出来几份一样的配置文件，惟一不一样的就是监听端口，能够依次改成700一、7002… 由于Redis Cluster若是数据冗余是1的话，至少要3个Master和3个Slave，因此咱们拷贝出6个实例的配置文件。为了不相互影响，为6个实例的配置文件创建独立的文件夹。

[root@8gVm redis-3.0.4]# pwd /root/Software/redis-3.0.4 [root@8gVm redis-3.0.4]# tree -I "*log|nodes*" cfg-cluster/ cfg-cluster/ ├── 7000 │ └── redis.conf.7000 ├── 7001 │ └── redis.conf.7001 ├── 7002 │ └── redis.conf.7002 ├── 7003 │ └── redis.conf.7003 ├── 7004 │ └── redis.conf.7004 └── 7005 └── redis.conf.7005 6 directories, 6 files

2.2 redis-trib管理器

Redis做者应该是个Ruby爱好者，Ruby客户端就是他开发的。此次集群的管理功能没有嵌入到Redis代码中，因而做者又顺手写了个叫作redis-trib的管理脚本。redis-trib依赖Ruby和RubyGems，以及redis扩展。能够先用which命令查看是否已安装ruby和rubygems，用gem list –local查看本地是否已安装redis扩展。

最简便的方法就是用apt或yum包管理器安装RubyGems后执行gem install redis。若是网络或环境受限的话，能够手动安装RubyGems和redis扩展（国外连接可能没法下载，能够从CSDN下载）：

[root@8gVm Software]# wget https://github.com/rubygems/rubygems/releases/download/v2.2.3/rubygems-2.2.3.tgz [root@8gVm Software]# tar xzvf rubygems-2.2.3.tgz [root@8gVm Software]# cd rubygems-2.2.3 [root@8gVm rubygems-2.2.3]# ruby setup.rb --no-rdoc --no-ri [root@8gVm Software]# wget https://rubygems.org/downloads/redis-3.2.1.gem [root@8gVm Software]# gem install redis-3.2.1.gem --local --no-rdoc --no-ri Successfully installed redis-3.2.1 1 gem installed

2.3 集群创建

首先，启动咱们配置好的6个Redis实例。

[root@8gVm redis-3.0.4]# for ((i=0; i<6; ++i)) > do > cd cfg-cluster/700$i && ../../src/redis-server redis.conf.700$i && cd - > done

此时6个实例尚未造成集群，如今用redis-trb.rb管理脚本创建起集群。能够看到，redis-trib默认用前3个实例做为Master，后3个做为Slave。由于Redis基于Master-Slave作数据备份，而非像Cassandra或Hazelcast同样不区分结点角色，自动复制并分配Slot的位置到各个结点。

[root@8gVm redis-3.0.4]# src/redis-trib.rb create --replicas 1 192.168.1.100:7000 192.168.1.100:7001 192.168.1.100:7002 192.168.1.100:7003 192.168.1.100:7004 192.168.1.100:7005 >>> Creating cluster Connecting to node 192.168.1.100:7000: OK Connecting to node 192.168.1.100:7001: OK Connecting to node 192.168.1.100:7002: OK Connecting to node 192.168.1.100:7003: OK Connecting to node 192.168.1.100:7004: OK Connecting to node 192.168.1.100:7005: OK >>> Performing hash slots allocation on 6 nodes... Using 3 masters: 192.168.1.100:7000 192.168.1.100:7001 192.168.1.100:7002 Adding replica 192.168.1.100:7003 to 192.168.1.100:7000 Adding replica 192.168.1.100:7004 to 192.168.1.100:7001 Adding replica 192.168.1.100:7005 to 192.168.1.100:7002 ... Can I set the above configuration? (type 'yes' to accept): yes >>> Nodes configuration updated >>> Assign a different config epoch to each node >>> Sending CLUSTER MEET messages to join the cluster Waiting for the cluster to join.... >>> Performing Cluster Check (using node 192.168.1.100:7000) ... [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered.

至此，集群就已经创建成功了！“贴心”的Redis还在utils/create-cluster下提供了一个create-cluster脚本，可以建立出一个集群，相似咱们上面创建起的3主3从的集群。

2.4 简单测试

咱们链接到集群中的任意一个结点，启动redis-cli时要加-c选项，存取两个Key-Value感觉一下Redis久违的集群功能。

[root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 192.168.1.100:7000> set foo bar -> Redirected to slot [12182] located at 192.168.1.100:7002 OK 192.168.1.100:7002> set hello world -> Redirected to slot [866] located at 192.168.1.100:7000 OK 192.168.1.100:7000> get foo -> Redirected to slot [12182] located at 192.168.1.100:7002 "bar" 192.168.1.100:7002> get hello -> Redirected to slot [866] located at 192.168.1.100:7000 "world"

仔细观察可以注意到，redis-cli根据指示，不断在7000和7002结点以前重定向跳转。若是启动时不加-c选项的话，就能看到以错误形式显示出的MOVED重定向消息。

[root@8gVm redis-3.0.4]# src/redis-cli -h 192.168.1.100 -p 7000 192.168.1.100:7000> get foo (error) MOVED 12182 192.168.1.100:7002

2.5 集群重启

目前redis-trib的功能还比较弱，须要重启集群的话先手动kill掉各个进程，而后从新启动就能够了。这也有点太… 网上有人重启后会碰到问题，我还比较幸运，这种“土鳖”的方式重启试了两次还没发现问题。

[root@8gVm redis-3.0.4]# ps -ef | grep redis | awk '{print $2}' | xargs kill

 

---

3.高级功能尝鲜

说是“高级功能”，其实在其余分布式系统中早就都有实现了，只不过在Redis世界里是比较新鲜的。本部分主要试验一下Redis Cluster中的数据迁移(Resharding)和故障转移功能。

3.1 数据迁移

本小节咱们体验一下Redis集群的Resharding功能！

3.1.1 建立测试数据

首先保存foo1~10共10个Key-Value做为测试数据。

[root@8gVm redis-3.0.4]# for ((i=0; i<10; ++i)) > do > src/redis-cli -c -h 192.168.1.100 -p 7000 set foo$i bar > done [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 192.168.1.100:7000> keys * 1) "foo6" 2) "foo7" 3) "foo3" 4) "foo2" 192.168.1.100:7000> get foo4 -> Redirected to slot [9426] located at 192.168.1.100:7001 "bar" 192.168.1.100:7001> keys * 1) "foo4" 2) "foo8" 192.168.1.100:7001> get foo5 -> Redirected to slot [13555] located at 192.168.1.100:7002 "bar" 192.168.1.100:7002> keys * 1) "foo5" 2) "foo1" 3) "foo10" 4) "foo9"

3.1.2 启动新结点

参照以前的方法新拷贝出两份redis.conf配置文件redis.conf.7010和7011，与以前结点的配置文件作一下区分。启动新的两个Redis实例以后，经过redis-trib.rb脚本添加新的Master和Slave到集群中。

[root@8gVm redis-3.0.4]# cd cfg-cluster/7010 && ../../src/redis-server redis.conf.7010 && cd - [root@8gVm redis-3.0.4]# cd cfg-cluster/7011 && ../../src/redis-server redis.conf.7011 && cd -

3.1.3 添加到集群

使用redis-trib.rb add-node分别将两个新结点添加到集群中，一个做为Master，一个做为其Slave。

[root@8gVm redis-3.0.4]# src/redis-trib.rb add-node 192.168.1.100:7010 192.168.1.100:7000 >>> Adding node 192.168.1.100:7010 to cluster 192.168.1.100:7000 Connecting to node 192.168.1.100:7000: OK Connecting to node 192.168.1.100:7001: OK Connecting to node 192.168.1.100:7002: OK Connecting to node 192.168.1.100:7005: OK Connecting to node 192.168.1.100:7003: OK Connecting to node 192.168.1.100:7004: OK >>> Performing Cluster Check (using node 192.168.1.100:7000) ... [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered. Connecting to node 192.168.1.100:7010: OK >>> Send CLUSTER MEET to node 192.168.1.100:7010 to make it join the cluster. [OK] New node added correctly. [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 cluster nodes 0d1f9c979684e0bffc8230c7bb6c7c0d37d8a5a9 192.168.1.100:7010 master - 0 1442452249525 0 connected ... [root@8gVm redis-3.0.4]# src/redis-trib.rb add-node --slave --master-id 0d1f9c979684e0bffc8230c7bb6c7c0d37d8a5a9 192.168.1.100:7011 192.168.1.100:7000 >>> Adding node 192.168.1.100:7011 to cluster 192.168.1.100:7000 Connecting to node 192.168.1.100:7000: OK Connecting to node 192.168.1.100:7010: OK Connecting to node 192.168.1.100:7001: OK Connecting to node 192.168.1.100:7002: OK Connecting to node 192.168.1.100:7005: OK Connecting to node 192.168.1.100:7003: OK Connecting to node 192.168.1.100:7004: OK >>> Performing Cluster Check (using node 192.168.1.100:7000) ... [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered. Connecting to node 192.168.1.100:7011: OK >>> Send CLUSTER MEET to node 192.168.1.100:7011 to make it join the cluster. Waiting for the cluster to join. >>> Configure node as replica of 192.168.1.100:7010. [OK] New node added correctly.

3.1.4 Resharding

经过redis-trib.rb reshard能够交互式地迁移Slot。下面的例子将5000个Slot从7000~7002迁移到7010上。也能够经过./redis-trib.rb reshard <host>:<port> --from <node-id> --to <node-id> --slots --yes在程序中自动完成迁移。

[root@8gVm redis-3.0.4]# src/redis-trib.rb reshard 192.168.1.100:7000 Connecting to node 192.168.1.100:7000: OK Connecting to node 192.168.1.100:7010: OK Connecting to node 192.168.1.100:7001: OK Connecting to node 192.168.1.100:7002: OK Connecting to node 192.168.1.100:7005: OK Connecting to node 192.168.1.100:7011: OK Connecting to node 192.168.1.100:7003: OK Connecting to node 192.168.1.100:7004: OK >>> Performing Cluster Check (using node 192.168.1.100:7000) M: b2036adda128b2eeffa36c3a2056444d23b548a8 192.168.1.100:7000 slots:0-5460 (4128 slots) master 1 additional replica(s) M: 0d1f9c979684e0bffc8230c7bb6c7c0d37d8a5a9 192.168.1.100:7010 slots:0 (4000 slots) master 1 additional replica(s) ... [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered. How many slots do you want to move (from 1 to 16384)? 5000 What is the receiving node ID? 0d1f9c979684e0bffc8230c7bb6c7c0d37d8a5a9 Please enter all the source node IDs. Type 'all' to use all the nodes as source nodes for the hash slots. Type 'done' once you entered all the source nodes IDs. Source node #1:all [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 cluster nodes 0d1f9c979684e0bffc8230c7bb6c7c0d37d8a5a9 192.168.1.100:7010 master - 0 1442455872019 7 connected 0-1332 5461-6794 10923-12255 b2036adda128b2eeffa36c3a2056444d23b548a8 192.168.1.100:7000 myself,master - 0 0 1 connected 1333-5460 b5ab302f5c2395e3c8194c354a85d02f89bace62 192.168.1.100:7001 master - 0 1442455875022 2 connected 6795-10922 0c565e207ce3118470fd5ed3c806eb78f1fdfc01 192.168.1.100:7002 master - 0 1442455874521 3 connected 12256-16383 ...

 

迁移完成后，查看以前保存的foo1~10的分布状况，能够看到部分Key已经迁移到了新的结点7010上。

[root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 keys "*" 1) "foo3" 2) "foo7" [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7001 keys "*" 1) "foo4" 2) "foo8" 3) "foo0" [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7002 keys "*" 1) "foo1" 2) "foo9" 3) "foo5" [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7010 keys "*" 1) "foo6" 2) "foo2"

3.2 故障转移

在高可用性方面，Redis可算是可以”Auto”一把了！Redis Cluster重用了Sentinel的代码逻辑，不须要单独启动一个Sentinel集群，Redis Cluster自己就能自动进行Master选举和Failover切换。

下面咱们故意kill掉7010结点，以后能够看到结点状态变成了fail，而Slave 7011被选举为新的Master。

[root@8gVm redis-3.0.4]# kill 43637 [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 cluster nodes 0d1f9c979684e0bffc8230c7bb6c7c0d37d8a5a9 192.168.1.100:7010 master,fail - 1442456829380 1442456825674 7 disconnected b2036adda128b2eeffa36c3a2056444d23b548a8 192.168.1.100:7000 myself,master - 0 0 1 connected 1333-5460 b5ab302f5c2395e3c8194c354a85d02f89bace62 192.168.1.100:7001 master - 0 1442456848722 2 connected 6795-10922 0c565e207ce3118470fd5ed3c806eb78f1fdfc01 192.168.1.100:7002 master - 0 1442456846717 3 connected 12256-16383 5a3c67248b1df554fbf2c93112ba429f31b1d3d1 192.168.1.100:7005 slave 0c565e207ce3118470fd5ed3c806eb78f1fdfc01 0 1442456847720 6 connected 99bff22b97119cf158d225c2b450732a1c0d3c44 192.168.1.100:7011 master - 0 1442456849725 8 connected 0-1332 5461-6794 10923-12255 cd305d509c34842a8047e19239b64df94c13cb96 192.168.1.100:7003 slave b2036adda128b2eeffa36c3a2056444d23b548a8 0 1442456848220 4 connected 64b544cdd75c1ce395fb9d0af024b7f2b77213a3 192.168.1.100:7004 slave b5ab302f5c2395e3c8194c354a85d02f89bace62 0 1442456845715 5 connected

 

尝试查询以前保存在7010上的Key，能够看到7011顶替上来继续提供服务，整个集群没有受到影响。

[root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 get foo6 "bar" [root@8gVm redis-3.0.4]# [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 get foo2 "bar"

---

4.内部原理剖析

前面咱们已经学习过，用Redis提供的redis-trib或create-cluster脚本能几步甚至一步就创建起一个Redis集群。这一部分咱们为了深刻学习，因此要暂时抛开这些方便的工具，彻底手动创建一遍上面的3主3从集群。

4.1 集群发现：MEET

最开始时，每一个Redis实例本身是一个集群，咱们经过cluster meet让各个结点互相“握手”。这也是Redis Cluster目前的一个欠缺之处：缺乏结点的自动发现功能。

[root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 cluster nodes 33c0bd93d7c7403ef0239ff01eb79bfa15d2a32c :7000 myself,master - 0 0 0 connected [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 cluster meet 192.168.1.100 7001 OK ... [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 cluster meet 192.168.1.100 7005 OK [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 cluster nodes 7b953ec26bbdbf67179e5d37e3cf91626774e96f 192.168.1.100:7003 master - 0 1442466369259 4 connected 5d9f14cec1f731b6477c1e1055cecd6eff3812d4 192.168.1.100:7005 master - 0 1442466368659 4 connected 33c0bd93d7c7403ef0239ff01eb79bfa15d2a32c 192.168.1.100:7000 myself,master - 0 0 1 connected 63162ed000db9d5309e622ec319a1dcb29a3304e 192.168.1.100:7001 master - 0 1442466371262 3 connected 45baa2cb45435398ba5d559cdb574cfae4083893 192.168.1.100:7002 master - 0 1442466372264 2 connected cdd5b3a244761023f653e08cb14721f70c399b82 192.168.1.100:7004 master - 0 1442466370261 0 connecte

4.2 角色设置：REPLICATE

结点所有“握手”成功后，就能够用cluster replicate命令为结点指定角色了，默认每一个结点都是Master。

[root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7003 cluster replicate 33c0bd93d7c7403ef0239ff01eb79bfa15d2a32c OK [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7004 cluster replicate 63162ed000db9d5309e622ec319a1dcb29a3304e OK [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7005 cluster replicate 45baa2cb45435398ba5d559cdb574cfae4083893 OK [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 cluster nodes 7b953ec26bbdbf67179e5d37e3cf91626774e96f 192.168.1.100:7003 slave 33c0bd93d7c7403ef0239ff01eb79bfa15d2a32c 0 1442466812984 4 connected 5d9f14cec1f731b6477c1e1055cecd6eff3812d4 192.168.1.100:7005 slave 45baa2cb45435398ba5d559cdb574cfae4083893 0 1442466813986 5 connected 33c0bd93d7c7403ef0239ff01eb79bfa15d2a32c 192.168.1.100:7000 myself,master - 0 0 1 connected 63162ed000db9d5309e622ec319a1dcb29a3304e 192.168.1.100:7001 master - 0 1442466814987 3 connected 45baa2cb45435398ba5d559cdb574cfae4083893 192.168.1.100:7002 master - 0 1442466811982 2 connected cdd5b3a244761023f653e08cb14721f70c399b82 192.168.1.100:7004 slave 63162ed000db9d5309e622ec319a1dcb29a3304e 0 1442466812483 3 connected

 

4.3 槽指派：ADDSLOTS

设置好主从关系以后，就能够用cluster addslots命令指派16384个槽的位置了。有点恶心的是，ADDSLOTS命令须要在参数中一个个指明槽的ID，而不能指定范围。这里用Bash 3.0的特性简化了，否则就得用Bash的循环来完成了：

[root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7000 cluster addslots {0..5000} OK [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7001 cluster addslots {5001..10000} OK [root@8gVm redis-3.0.4]# src/redis-cli -c -h 192.168.1.100 -p 7001 cluster addslots {10001..16383} OK [root@8gVm redis-3.0.4]# src/redis-trib.rb check 192.168.1.100:7000 Connecting to node 192.168.1.100:7000: OK ... >>> Performing Cluster Check (using node 192.168.1.100:7000) ... [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered.

 

这样咱们就经过手动执行命令获得了与以前同样的集群。

4.4 数据迁移：MIGRATE

真正开始Resharding以前，redis-trib会先在源结点和目的结点上执行cluster setslot <slot> importing和cluster setslot <slot> migrating命令，将要迁移的槽分别标记为迁出中和导入中的状态。而后，执行cluster getkeysinslot得到Slot中的全部Key。最后就能够对每一个Key执行migrate命令进行迁移了。槽迁移完成后，执行cluster setslot命令通知整个集群槽的指派已经发生变化。

关于迁移过程当中的数据访问，客户端访问源结点时，若是Key还在源结点上就直接操做。若是已经不在源结点了，就向客户端返回一个ASK错误，将客户端重定向到目的结点。

4.5 内部数据结构

Redis Cluster功能涉及三个核心的数据结构clusterState、clusterNode、clusterLink都在cluster.h中定义。这三个数据结构中最重要的属性就是：clusterState.slots、clusterState.slots_to_keys和clusterNode.slots了，它们保存了三种映射关系：

• clusterState：集群状态
  
  • nodes：全部结点
  • migrating_slots_to：迁出中的槽
  • importing_slots_from：导入中的槽
  • slots_to_keys：槽中包含的全部Key，用于迁移Slot时得到其包含的Key
  • slots：Slot所属的结点，用于处理请求时判断Key所在Slot是否本身负责
• clusterNode：结点信息
  
  • slots：结点负责的全部Slot，用于发送Gossip消息通知其余结点本身负责的Slot。经过位图方式保存节省空间，16384/8刚好是2048字节，因此槽总数16384不是随意定的。
• clusterLink：与其余结点通讯的链接

// 集群状态，每一个节点都保存着一个这样的状态，记录了它们眼中的集群的样子。 // 另外，虽然这个结构主要用于记录集群的属性，可是为了节约资源， // 有些与节点有关的属性，好比 slots_to_keys 、 failover_auth_count // 也被放到了这个结构里面。 typedef struct clusterState { ... // 指向当前节点的指针 clusterNode *myself; /* This node */ // 集群当前的状态：是在线仍是下线 int state; /* REDIS_CLUSTER_OK, REDIS_CLUSTER_FAIL, ... */ // 集群节点名单（包括 myself 节点） // 字典的键为节点的名字，字典的值为 clusterNode 结构 dict *nodes; /* Hash table of name -> clusterNode structures */ // 记录要从当前节点迁移到目标节点的槽，以及迁移的目标节点 // migrating_slots_to[i] = NULL 表示槽 i 未被迁移 // migrating_slots_to[i] = clusterNode_A 表示槽 i 要从本节点迁移至节点 A clusterNode *migrating_slots_to[REDIS_CLUSTER_SLOTS]; // 记录要从源节点迁移到本节点的槽，以及进行迁移的源节点 // importing_slots_from[i] = NULL 表示槽 i 未进行导入 // importing_slots_from[i] = clusterNode_A 表示正从节点 A 中导入槽 i clusterNode *importing_slots_from[REDIS_CLUSTER_SLOTS]; // 负责处理各个槽的节点 // 例如 slots[i] = clusterNode_A 表示槽 i 由节点 A 处理 clusterNode *slots[REDIS_CLUSTER_SLOTS]; // 跳跃表，表中以槽做为分值，键做为成员，对槽进行有序排序 // 当须要对某些槽进行区间（range）操做时，这个跳跃表能够提供方便 // 具体操做定义在 db.c 里面 zskiplist *slots_to_keys; ... } clusterState; // 节点状态 struct clusterNode { ... // 节点标识 // 使用各类不一样的标识值记录节点的角色（好比主节点或者从节点）， // 以及节点目前所处的状态（好比在线或者下线）。 int flags; /* REDIS_NODE_... */ // 由这个节点负责处理的槽 // 一共有 REDIS_CLUSTER_SLOTS / 8 个字节长 // 每一个字节的每一个位记录了一个槽的保存状态 // 位的值为 1 表示槽正由本节点处理，值为 0 则表示槽并不是本节点处理 // 好比 slots[0] 的第一个位保存了槽 0 的保存状况 // slots[0] 的第二个位保存了槽 1 的保存状况，以此类推 unsigned char slots[REDIS_CLUSTER_SLOTS/8]; /* slots handled by this node */ // 指针数组，指向各个从节点 struct clusterNode **slaves; /* pointers to slave nodes */ // 若是这是一个从节点，那么指向主节点 struct clusterNode *slaveof; /* pointer to the master node */ ... }; /* clusterLink encapsulates everything needed to talk with a remote node. */ // clusterLink 包含了与其余节点进行通信所需的所有信息 typedef struct clusterLink { ... // TCP 套接字描述符 int fd; /* TCP socket file descriptor */ // 与这个链接相关联的节点，若是没有的话就为 NULL struct clusterNode *node; /* Node related to this link if any, or NULL */ ... } clusterLink;

 

4.6 处理流程全梳理

在单机模式下，Redis对请求的处理很简单。Key存在的话，就执行请求中的操做；Key不存在的话，就告诉客户端Key不存在。然而在集群模式下，由于涉及到请求重定向和Slot迁移，因此对请求的处理变得很复杂，流程以下：

1. 检查Key所在Slot是否属于当前Node？
   2.1 计算crc16(key) % 16384获得Slot
   2.2 查询clusterState.slots负责Slot的结点指针
   2.3 与myself指针比较
2. 若不属于，则响应MOVED错误重定向客户端
3. 若属于且Key存在，则直接操做，返回结果给客户端
4. 若Key不存在，检查该Slot是否迁出中？(clusterState.migrating_slots_to)
5. 若Slot迁出中，返回ASK错误重定向客户端到迁移的目的服务器上
6. 若Slot未迁出，检查Slot是否导入中？(clusterState.importing_slots_from)
7. 若Slot导入中且有ASKING标记，则直接操做
8. 不然响应MOVED错误重定向客户端

---

5.应用案例收集

5.1 有道：Redis Cluster使用经验

详情请参见原文，关键内容摘录以下：

5.1.1 两个缺点

“redis cluster的设计在这块有点奇葩，跟集群相关的操做须要一个外部的ruby脚原本协助（固然多是为了让主程序的代码足够简洁？），而后那个脚本还只支持填实例的ip不支持host，还不告诉你不支持让你用host以后各类莫名其妙。”

“第一个缺点就是严格依赖客户端driver的成熟度。若是把redis cluster设计成相似Cassandra，请求集群中任何一个节点均可以负责转发请求，client会好写一些。”

“第二个缺点彻底是设计问题了，就是一个redis进程既负责读写数据又负责集群交互，虽然设计者已经尽量简化了代码和逻辑，但仍是让redis从一个内存NoSQL变成了一个分布式NoSQL。分布式系统很容易有坑，一旦有坑必须升级redis。”

5.1.2 去中心化 vs. Proxy

“关于redis cluster的设计，Gossip/P2P的去中心化架构自己不是问题，但一旦有了中心节点，能作的事情就多了，好比sharding不均匀是很容易自动rebalance的，而无中心的只能靠外界来搞。而后redis cluster又是slot的形式而非C*式的一致性哈希，新节点分slot又不自动，依赖外界（ruby脚本）来分配显得不方便更不优美和谐。并且由于是master-slave的系统而非W+R>N的那种，master挂掉以后尽快发现是比较重要的，gossip对于节点挂掉的发现终究没有中心节点/zookeeper方便快速。”

“基于proxy作转发意味着屏蔽了下层存储，彻底能够根据前缀/tag/冷热程度，来把部分甚至大多数数据放在磁盘从而节约成本又保证一致性，这都是有中心节点所带来的好处。”

5.2 奇虎360：Redis Cluster浅析和Bada对比

详情请参见原文，关键内容摘录以下：

5.2.1 负载均衡问题

“redis cluster的主备是以节点为单位，而bada则是以partition为单位，这样，一样是3个节点，1024个partition的状况下，redis cluster的主节点负责整个1024个partition的服务，而两个从节点则只负责异步备份，致使集群负载不均，再看bada，将1024个partition的主均分到3个节点中，每一个节点各有主备，主对外提供服务，这样均分了访问压力，有效的利用了资源。”

5.2.2 一致性的保证

“redis cluster与bada同样，最终一致性，读写都只请求主节点，当一条写请求在对应的主节点写成功后，会马上返回给客户端成功，而后主节点经过异步的方式将新的数据同步到对应的从节点，这样的方式减小了客户端多个节点写成功等待的时间，不过在某些状况下会形成写丢失：

1）当主节点接受一条写请求，写入并返回给客户端成功后不幸宕掉，此时刚才的写还未同步给其对应的从节点，而从节点在发现主节点挂掉并从新选主后，新的主节点则永久丢失了以前老的主节点向用户确认的写

2）当网络发生割裂，将集群分裂成少数派与多数派，这样在客户端不知情的状况下，会将写继续写入到少数派中的某些主节点中，而当割裂超过必定时长后，集群感知到异常，此时少数派中的全部主节点会中止响应全部的写请求，多数派的其对应的从节点则会发起选举成为新的主节点，假设过了一会后割裂恢复，老的主节点发现有更新的主存在，自动变成其从节点，而新的主节点中则会永久丢失掉网络割裂至集群感知异常进行切主这个阶段老主节点确认的全部写

相对于redis cluster的永久丢失，bada经过binlog merge有效的解决了这一问题。全部partition的主节点在响应客户端的写请求时，都会在本地记录binlog，binlog实质就是带有时间戳的KV对。当老主以从节点的身份从新加入集群时，会触发binlog merge操做，新主会比较而且合并两者的binlog，这样就能够将以前丢失掉得写再补回来。”

5.2.3 请求重定向问题

“bada服务端节点在收到本不应由本身负责的Partition请求后，不会向客户端返回重定向信息，而是经过代理的方式，直接在集群内部向正确节点转发客户端的请求，并将结果同meta信息再转发回客户端。”

“再看multi key操做，redis cluster为了追求高性能，支持multi key的前提是全部的key必须在同一个节点中, 不过这样的处理须要交给用户，对须要进行multi key操做的全部key，在写入前人为的加上hash tags。当redis cluster进行resharding的时候，也就是将某些slot从一个节点迁移到另外一个节点时，此时的multi key操做可能会失败，由于在迁移的slot中的key此时存在于两个节点。

bada怎么作呢？用户若是对multi key操做性能很在意时，能够采用与redis cluster一样的方式，给这些key加上hash tags来让它们落在同一个节点，若是能够接受性能的稍微损耗而解放用户的处理逻辑，则能够像single key操做同样，请求任一bada节点，它会代理全部的key请求并将结果返回给用户。而且在multi key操做在任什么时候候均可以，即便在进行partition的迁移，bada也会提早进行切主，保证服务的正常提供。”

5.3 芒果TV：Redis服务解决方案

详情请参见原文，关键内容摘录以下：

芒果TV在Redis Cluster基础上进行开发，主要增长了两个组件：

• 监控管理：以Python为主要开发框架的Web应用程序Redis-ctl
• 请求代理：以C++11为开发语言的轻量数据代理程序cerberus。其做用和优势为：
  
  • 集群代理程序的自动请求分发/重试机制使得应用没必要修改自身代码或更新Redis库
  • 代理节点为全部Redis节点加上统一管理和状态监测, 能够查阅历史数据, 或在发生任何问题以后快速响应修复
  • 代理进程的无状态性使之可在故障后快速恢复, 不影响后端集群数据完整性

这两个组件都已开源到GitHub上，你们能够关注一下！

---

6.Pros & Cons总结

关于Redis Cluster带来的种种优点就不说了，在这里主要是“鸡蛋里挑骨头”，总结一下现阶段集群功能的欠缺之处和可能的“坑”。

6.1 无中心化架构

6.1.1 Gossip消息

Gossip消息的网络开销和时延是决定Redis Cluster可以线性扩展的因素之一。关于这个问题，在《redis cluster百万QPS的挑战》一文中有所说起。

6.1.2 结点粒度备份

此外，Redis Cluster也许是为了简化设计采用了Master-Slave复制的数据备份方案，并无采起如Cassandra或IMDG等对等分布式系统中常见的Slot粒度（或叫Partition/Bucket等）的自动冗余和指派。

这种设计虽然避免比较复杂的分布式技术，但也带来了一些问题：

• Slave彻底闲置：即使是读请求也不会被重定向到Slave结点上，Slave属于“冷备”
• 写压力没法分摊：Slave闲置致使的另外一个问题就是写压力也都在Master上

6.2 客户端的挑战

因为Redis Cluster的设计，客户端要担负起一部分责任：

• Cluster协议支持：无论Dummy仍是Smart模式，都要具有解析Cluster协议的能力
• 网络开销：Dummy客户端不断重定向的网络开销
• 链接维护：Smart客户端对链接到集群中每一个结点Socket的维护
• 缓存路由表：Smart客户端Slot路由表的缓存和更新
• 内存消耗：Smart客户端上述维护的信息都是有内存消耗的
• MultiOp有限支持：对于MultiOp，由客户端经过KeyTag保证全部Key都在同一Slot。而即使如此，迁移时也会致使MultiOp失败。同理，对Pipeline和Transaction的支持也受限于必须操做同一Slot内的Key。

6.3 Redis实现问题

尽管属于无中心化架构一类的分布式系统，但不一样产品的细节实现和代码质量仍是有很多差别的，就好比Redis Cluster有些地方的设计看起来就有一些“奇葩”和简陋：

• 不能自动发现：无Auto Discovery功能。集群创建时以及运行中新增结点时，都要经过手动执行MEET命令或redis-trib.rb脚本添加到集群中
• 不能自动Resharding：不只不自动，连Resharding算法都没有，要本身计算从哪些结点上迁移多少Slot，而后仍是得经过redis-trib.rb操做
• 严重依赖外部redis-trib：如上所述，像集群健康情况检查、结点加入、Resharding等等功能全都抽离到一个Ruby脚本中了。还不清楚上面提到的缺失功能将来是要继续加到这个脚本里仍是会集成到集群结点中？redis-trib也许要变成Codis中Dashboard的角色
• 无监控管理UI：即使将来加了UI，像迁移进度这种信息在无中心化设计中很可贵到
• 只保证最终一致性：写Master成功后当即返回，如需强一致性，自行经过WAIT命令实现。但对于“脑裂”问题，目前Redis没提供网络恢复后的Merge功能，“脑裂”期间的更新可能丢失

6.4 性能损耗

因为以前手头没有空闲的物理机资源，因此只在虚拟机上作了简单的单机测试，在单独的一台压力机使用YCSB测试框架向虚拟机产生读写负载。虚拟机的配置为8核Intel Xeon CPU X5650@2.67GHz，16GB内存，分别搭建了4结点的单机版Redis和集群版Redis，测试一下Redis Cluster的性能损耗。因为不是最近作的测试，因此Jedis用的2.6.2版本。注：固然Redis Cluster能够经过多机部署得到水平扩展带来的性能提高，这里只是因为环境有限因此作的简单单机测试。

因为YCSB自己仅支持Redis单机版，因此须要咱们本身增长扩展插件，具体方法请参照《YCSB性能测试工具使用》。经过YCSB产生2000w随机数据，Value大约100Byte左右。而后经过YCSB测试Read-Mostly(90% Read)和Read-Write-Mixed(50% Read)两种状况：

• 数据加载：吞吐量上有约18%的降低。
• Read-Mostly：吞吐量上有约3.5%~7.9%的降低。
• Read-Write-Mixed：吞吐量上有约3.3%~5.5%降低。
• 内存占用：Jedis客户端多占用380MB内存。

6.5 最后的总结

从现阶段看来，相比Sentinel或Codis等方案，Redis Cluster的优点还真是有限，我的以为最大的优势有两个：

1. 官方提供的Slot实现而不用像Codis那样去改源码了；
2. 不用额外的Sentinel集群或相似的代码实现了。

同其余分布式系统，如Cassandra，或内存型的IMDG如Hazelcast和GridGain，除了性能方面外，从功能上Redis Cluster简直被爆得体无完肤… 看看我以前总结过的GridGain介绍《开源IMDG之GridGain》：

• 结点自动发现和Rebalance
• 分区粒度的备份
• 故障时分区角色自动调整
• 结果聚合（不会重定向客户端）
• “脑裂”恢复后的Merge（Hazelcast支持多种合并策略）
• 多Primary分区写操做（见Replicated模式）

这些都是Redis Cluster没有或者要手动完成的。固然这也不足为奇，由于这与Redis的设计初衷有关，毕竟做者都已经说了，最核心的设计目标就是性能、水平伸缩和可用性。

从Redis Cluster的环境搭建使用到高级功能和内部原理剖析，再到应用案例收集和优缺点的分析罗列，讲了这么多，关于Redis集群到底如何，相信你们根据本身切身和项目的具体状况必定有了本身的结论。无论是评估测试也好，二次开发也好，仍是直接上线使用也好，相信随着官方的不断迭代更新和你们的力量，Redis Cluster必定会逐渐完善成熟的！

 

http://www.cnblogs.com/lixigang/articles/4847110.html