redis集群搭建及分析

概述

redis提供了无中心化的模式来提供对key的shading, 提供数据存储的master节点与master节点之间是对等的, master节点与master节点之间经过gossip协议进行通讯,以实现集群选主,失效转移, 触发数据迁移等操做.

1. redis 集群搭建

1.1 配置项说明

cluster-enabled <yes/no>: 是否开启集群模式, yes开启, no不开启.
cluster-config-file <filename>: 集群配置文件,用于集群信息,用户不能编辑或改变该文件.
cluster-node-timeout <milliseconds>: 检测集群中master节点失败最大时间,当master节点超过该时间还没法联系时, 若是有备份节点则备份节点将对maser节点进行失效转移,若干没有则表示该master节点失效, 当集群中大多数master节点失效时,集群将再也不提供操做.
cluster-slave-validity-factor <factor>:master节点检测到超时时最大链接重试次数, 默认为0, 即一旦检测到超时则slave节点就对master进行失效转移, 当该值为正数时, 在factor*timeout的时间周期内, slave不会对master进行失效转移.
cluster-migration-barrier <count>: master节点保存链接的最小slave节点数.
cluster-require-full-coverage <yes/no>:当主节点失效时是否继续提供服务, 默认yes, 即主节点失效时将不提供服务, no, 失效时仍然提供服务.

1.2 集群搭建

下面将搭建3主3从的集群, 主节点端口分别为7000, 7001, 70002, 从节点端口为7003, 7004, 7005.即一个master节点对应一个slave节点.
建立配置文件以下:

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

建立6个文件夹, 文件夹名为端口名, 并将配置文件拷贝到各文件夹,端口修改成对应端

mkdir cluster-test
cd cluster-test
mkdir 7000 7001 7002 7003 7004 7005

将redis-server执行程序拷贝到各文件夹,并启动

cd 7000
../redis-server ./redis.conf

运行后结果以下:

14073:M 11 Aug 14:45:40.198 * No cluster configuration found, I'm 5714dd95e99999f7130eba44747f7a15aa8f5394

5714dd95e99999f7130eba44747f7a15aa8f5394, 表示节点Id.

建立集群:
完成以上步骤后,各节点独立运行, 并无造成集群, 下面须要相互之间通讯,组成集群, 这里使用redis自带的工具redis-trib,
首先安装 redis gem

gem install redis

建立集群

./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \
127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

建立成功

[OK] All 16384 slots covered

查看集群状态:

127.0.0.1:7002> cluster nodes
4406983653bd90043b5b7f65af0afc571bb2d93c 127.0.0.1:7002 myself,master - 0 0 3 connected 10923-16383
fd5e7a729072b0e7e29ff5a4935a0151c470a47d 127.0.0.1:7005 slave 4406983653bd90043b5b7f65af0afc571bb2d93c 0 1470899978447 3 connected
5714dd95e99999f7130eba44747f7a15aa8f5394 127.0.0.1:7000 master - 0 1470899976944 1 connected 0-5460
aca053afafd21f887d3bc9d87c16597f67b7e513 127.0.0.1:7001 master - 0 1470899977946 2 connected 5461-10922
c450ae75e23a2cfeda901c0de77ef0cae85a8a8b 127.0.0.1:7003 slave 5714dd95e99999f7130eba44747f7a15aa8f5394 0 1470899978947 1 connected
576764adacf6737b5ef6e63ff5ea2cb3a9aae43d 127.0.0.1:7004 slave aca053afafd21f887d3bc9d87c16597f67b7e513 0 1470899977445 5 connected

命令测试:

./redis-cli -c -p 7000
127.0.0.1:7000> set foo bar
-> Redirected to slot [12182] located at 127.0.0.1:7002
OK
127.0.0.1:7002> set hello world
-> Redirected to slot [866] located at 127.0.0.1:7000
OK
127.0.0.1:7000>
127.0.0.1:7000> get hello
"world"
127.0.0.1:7000> get foo
-> Redirected to slot [12182] located at 127.0.0.1:7002
"bar"

集群搭建成功

2. slots映射说明

redis 内部提供 16384个槽,每一个节点分配固定槽数, 也就是说一个集群最多支持16348个节点, 若有A, B, C三个节点, 则分配以下:

Node A  [0,5500]
    Node B [5501,11000]
    Node C [11001,16383]

对于一个key, 首先对其作crc16, 并将结果对16384去模, 所得的结果则表示key所属的槽, 经过查询槽的分配策略, 获得key分配的服务器, 从而实现key在集群内部shading.

3. 重定向命令

moved重定向命令:
client端与redis集群的任一节点创建链接后, 对key进行操做时:
若是收到命令的redis节点发现key对应的槽不属于本身处理,则会给client回复moved错误, 并返回槽所在的真正节点,
client端收到moved错误后,重定向到指定节点作操做,
这里能够能够看出, 任何一个redis节点均保存了集群中的其余节点槽对应信息.另外为了提升client性能, client会缓存槽与服务器的对应信息, 因此收到moved从定向时, 会相应的更新缓存.

ask重定向命令:
ask重定向发送在集群中正在对槽对应的key进行数据迁移时,具体流程为:
当client端向节点nodeA发送key1的处理命令时, 若果A节点具备key1对应的槽slot1的处理权, 且key1没法在nodeA查询到, 且slot1正处于迁移状态,则nodeA返回ask重定向命令, 将其指向迁移的目标节点nodeB
client收到重定向命令后, 向nodeB先发送asking命令, 再发送key1的处理命令.
nodeB接收到asking命令后, 将对收到后续一个命令作特殊处理,也就是即便发现slot1不属于nodeB处理,仍然会执行key1的处理命令.ask从定向命令不会引发client端更新缓存,且nodeB只处理一次.

4. 失效转移

redis集群有实行主备机制, slave节点保存着master节点全部数据备份, 当master节点失效时,slave节点会对master节点进行失效转移.具体流程为:
集群中master节点之间按期会进行通讯, 当集群中对等的masterA节点发现某个节点masterB超时无回应时, 则将该masterB节点置为faling,并广播检测到的状况.
同 时masterA会记录集群中其余master节点对masterB的检测结果, 若是发现集群中大部分(n/2+1)的master节点均认为该节点faling,则将masterB的装置为failed, 即失效,同时, masterA向masterB的slave节点发送命令让其选举.
选举时在一个时间纪元内会存在两种状况, 要么一个slave节点得到大于等于n/2+1的投票成为新的master, 要么超时.
选择成功后的slave将会成为master节点,继续工做,而超时则进入新一轮选举,直到选出新的master.
这里具备投票权的master只能投票一次,从而保证只有一个master能当选.而失效的master节点又从新上线后将转为slave节点.

redis集群的测试结果以下:
在上面搭建的集群中7004为7001的slave节点,现将7001挂掉, 查看集群状态:

127.0.0.1:7002> cluster nodes
4406983653bd90043b5b7f65af0afc571bb2d93c 127.0.0.1:7002 myself,master - 0 0 3 connected 10923-16383
fd5e7a729072b0e7e29ff5a4935a0151c470a47d 127.0.0.1:7005 slave 4406983653bd90043b5b7f65af0afc571bb2d93c 0 1470903542509 3 connected
5714dd95e99999f7130eba44747f7a15aa8f5394 127.0.0.1:7000 master - 0 1470903542509 1 connected 0-5460
aca053afafd21f887d3bc9d87c16597f67b7e513 127.0.0.1:7001 master,fail - 1470903522089 1470903520389 2 disconnected
c450ae75e23a2cfeda901c0de77ef0cae85a8a8b 127.0.0.1:7003 slave 5714dd95e99999f7130eba44747f7a15aa8f5394 0 1470903541506 1 connected
576764adacf6737b5ef6e63ff5ea2cb3a9aae43d 127.0.0.1:7004 master - 0 1470903543513 7 connected 5461-10922

能够看到7001已经失效, 同时7004成了新的master节点.

如今又将7001重启, 查看集群状态:

127.0.0.1:7002> cluster nodes
4406983653bd90043b5b7f65af0afc571bb2d93c 127.0.0.1:7002 myself,master - 0 0 3 connected 10923-16383
fd5e7a729072b0e7e29ff5a4935a0151c470a47d 127.0.0.1:7005 slave 4406983653bd90043b5b7f65af0afc571bb2d93c 0 1470903594126 3 connected
5714dd95e99999f7130eba44747f7a15aa8f5394 127.0.0.1:7000 master - 0 1470903596130 1 connected 0-5460
aca053afafd21f887d3bc9d87c16597f67b7e513 127.0.0.1:7001 slave 576764adacf6737b5ef6e63ff5ea2cb3a9aae43d 0 1470903594727 7 connected
c450ae75e23a2cfeda901c0de77ef0cae85a8a8b 127.0.0.1:7003 slave 5714dd95e99999f7130eba44747f7a15aa8f5394 0 1470903595730 1 connected
576764adacf6737b5ef6e63ff5ea2cb3a9aae43d 127.0.0.1:7004 master - 0 1470903595629 7 connected 5461-10922

7001 成为了slave节点.

5. 集群扩展

集群扩展分为两个方面,分别为新增节点(包括新增master节点, 新增slave节点), 及减小节点.
新增master节点
流程和前面搭建集群时一致, 先给节点分配一个端口并运行,如7006.而后经过redis-trib执行如下命令

./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000

如上, 第一个地址为新增的地址, 第二个地址为集群中已经运行的master地址,执行完以上命令后master虽然加入了集群,可是它并无分配到槽进行数据处理
这是须要进行reshaing, 命令以下:

./redis-trib.rb reshard --from <node-id> --to <node-id> --slots <number of slots> --yes <host>:<port>

新增slave节点

./redis-trib.rb add-node --slave --master-id 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7006 127.0.0.1:7000

其中,master-id表示要成为谁的slave.

减小节点

./redis-trib del-node 127.0.0.1:7000 `<node-id>`

6. 总结

从 整个流程来看,.无论仍是集群的建立仍是 后期集群的运维,redis都很是的顺畅,这无疑提升了使用的门槛,就以当前redis的性能来讲,作redis缓存集群是个不错的选择,不过,若是要在 运营环境进行使用,仍是须要更加方便的部署及运维工具,这里推荐搜狐的开源工具cachecloud, 的确十分好用,git地址见:
https://github.com/sohutv/cac...