Redis 集群搭建
一 Redis集群简介
1.redis数据集群的分片
Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:
- 节点 A 包含 0 到 5500号哈希槽.
- 节点 B 包含5501 到 11000 号哈希槽.
- 节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我像移除节点A,需要将A中得槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态
如果存入一个值,按照redis cluster哈希槽的算法: CRC16('key')%16384 = 6782。 那么就会把这个key 的存储分配到 B 上了。同样,当我连接(A,B,C)任何一个节点想获取'key'这个key时,也会这样的算法,然后内部跳转到B节点上获取数据
2.redis集群主从复制模型
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用,所以集群使用了主从复制模型,每个节点都会有N-1个复制品.
在我们例子中具有A,B,C三个节点的集群,在没有复制模型的情况下,如果节点B失败了,那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.
然而如果在集群创建的时候(或者过一段时间)我们为每个节点添加一个从节点A1,B1,C1,那么整个集群便有三个master节点和三个slave节点组成,这样在节点B失败后,集群便会选举B1为新的主节点继续服务,整个集群便不会因为槽找不到而不可用了
不过当B和B1 都失败后,集群是不可用的.
3.redis一致性保证
Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作.
第一个原因是因为集群是用了异步复制. 写操作过程:
- 客户端向主节点B写入一条命令.
- 主节点B向客户端回复命令状态.
- 主节点将写操作复制给他得从节点 B1, B2 和 B3.
主节点对命令的复制工作发生在返回命令回复之后, 因为如果每次处理命令请求都需要等待复制操作完成的话, 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。 注意:Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区, 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。
举个例子 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点, 其中 A 、B 、C 为主节点, A1 、B1 、C1 为A,B,C的从节点, 还有一个客户端 Z1 假设集群中发生网络分区,那么集群可能会分为两方,大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ,小部分的一方则包含节点 B 和客户端 Z1 .
Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master,那么Z1写入B中得数据便丢失了.
注意, 在网络分裂出现期间, 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的, 这一时间限制称为节点超时时间(node timeout), 是 Redis 集群的一个重要的配置选项
二 Redis集群搭建
- [root@localhost redis-3.2.0]# tar xzf redis-3.2.8.tar.gz
- [root@localhost redis-3.2.0]# cd redis-3.2.8
- [root@localhost redis-3.2.0]# make
- [root@localhost redis01]# make install PREFIX=/usr/redis-cluster
- [root@localhost redis01]# cp /usr/redis-cluster/bin/redis-server /usr/bin
- [root@localhost redis-3.2.0]# cp /usr/redis-cluster/bin/redis-cli /usr/bin
daemonize yes #后台启动
port 7001 #修改端口号,从6380到8380
cluster-enabled yes #开启cluster,去掉注释
cluster-config-file nodes.conf
cluster-node-timeout 15000
appendonly yes
以此类推修改redis6381-redis8380剩下集群的配置- [root@localhost redis-cluster]# cp /usr/redis-3.2.8/src/redis-trib.rb /usr/redis-cluster/
- [root@localhost redis-cluster]# cp /usr/redis-3.2.8/src/redis-trib.rb /usr/bin/
- [root@localhost redis-cluster]# yum install ruby
- [root@localhost redis-cluster]# yum install rubygems
- [root@localhost redis-cluster]# gem install redis-3.2.2.gem
- [root@localhost redis-cluster]# redis-server /usr/redis-cluster/redis6380/redis6380.conf
- [root@localhost redis-cluster]# redis-server /usr/redis-cluster/redis6381/redis6381.conf
- [root@localhost redis-cluster]# redis-server /usr/redis-cluster/redis6382/redis6382.conf
- [root@localhost redis-cluster]# redis-server /usr/redis-cluster/redis7381/redis7381.conf
- [root@localhost redis-cluster]# redis-server /usr/redis-cluster/redis7382/redis7382.conf
- [root@localhost redis-cluster]# redis-server /usr/redis-cluster/redis8380/redis8380.conf
- [root@localhost redis-cluster]# redis-trib.rb create --replicas 1 172.23.27.97:6380 172.23.27.97:6381 172.23.27.97:6382 172.23.27.97:7381 172.23.27.97:7382 172.23.27.97:8380
设置好以后,使用以下命令检查集群
返回有内容,三主三从,表示集群搭建成功
- [root@localhost redis-cluster]#
- [root@localhost redis-cluster]# redis-trib.rb check 127.0.0.1:6380
三 Redis监控
参见相关文档,这里简单说明一下:
1. redis cluster 在迁移,和主备切换的时候,均不影响正常的redis使用
2 运维需要监控redis cluster和redis 单机使用情况:
2.1监控cluster:redis-trib.rb info 127.0.0.1:6380 返回值类似如下:
127.0.0.1:6380 (c3e313ec...) -> 1 keys | 5462 slots | 1 slaves.
127.0.0.1:6381 (88dd4d50...) -> 0 keys | 5461 slots | 1 slaves.
127.0.0.1:6382 (111bcf64...) -> 0 keys | 5461 slots | 1 slaves.
如果发现keys的数目相差超过1w,需要报警。主备数目不对的情况下,也需要报警
3 监控redis内存使用:
redis-cli -p 6380 info| grep used_memory_peak_human
返回如下内容:used_memory_peak_human:2.35M
如果这个值已经接近redis配置的内存最大值,需要报警
4. 监控redis cluster是否在正常状态
[root@dev01 rediscluster]# redis-trib.rb info 127.0.0.1:6380
127.0.0.1:6380 (a776c747...) -> 0 keys | 5461 slots | 1 slaves.
172.23.27.97:6381 (b5713042...) -> 0 keys | 5462 slots | 1 slaves.
172.23.27.97:6382 (2449c3b4...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 0 keys in 3 masters.
0.00 keys per slot on average.
[root@dev01 rediscluster]# redis-trib.rb CHECK 127.0.0.1:6380
>>> Performing Cluster Check (using node 127.0.0.1:6380)
M: a776c7470d8fce22a15f4648b6779a3cb05feae3 127.0.0.1:6380
slots:0-5460 (5461 slots) master
1 additional replica(s)
S: ede467d6b98912543de6387189860b586a61458a 172.23.27.97:7381
slots: (0 slots) slave
replicates b5713042514a2c42563dfb5e429b347c8e517401
S: 6ae8ea96c83f955e6bce861d6282ec889809816d 172.23.27.97:7382
slots: (0 slots) slave
replicates 2449c3b46342e15b1882aad64b950de050c7bac1
M: b5713042514a2c42563dfb5e429b347c8e517401 172.23.27.97:6381
slots:5461-10922 (5462 slots) master
1 additional replica(s)
S: 90772a73d7f23063dee0276d99e2f25c7477bb75 172.23.27.97:8380
slots: (0 slots) slave
replicates a776c7470d8fce22a15f4648b6779a3cb05feae3
M: 2449c3b46342e15b1882aad64b950de050c7bac1 172.23.27.97:6382
slots:10923-16383 (5461 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.