NoSQL 之Redis集群

▪ 单节点Redis服务器带来的问题

▪ 单点故障，服务不可用

▪ 无法处理大量的并发数据请求

▪ 数据丢失--大灾难

▪ 解决方法

▪ 搭建Redis集群

▪ Redis工作模式

▪ 单节点

▪ 集群的方式：

▪ 主从模式（2.8之前）

解决数据备份，读写分离，无法实现自动化故障转移

无法对master扩容

▪ 哨▪兵模式（2.8之后）

利用哨兵检查master的状态

自动的故障转移

无法对master扩容

▪ 集群模式（3.0之后）

redis cluster

▪ Redis集群介绍

▪ Redis集群时一个提供在多个Redis间节点间共享数据的程序集

▪ Redis集群并不支持处理多个keys的命令，因为这需要再不同的节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会导致不可预料的错误

▪ Redis集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下可继续处理命令

▪ Redis集群的优势

▪ 自动分割数据到不同的节点上

▪ 整个集群的部分节点失败或者不可达的情况下能够继续处理命令

▪ Redis集群的实现方法

▪ 有客户端分片

▪ 代理分片

▪ 服务器端分片

▪ Redis-Cluster数据分片

▪ Redis集群没有使用一致性hash，而是引入了哈希槽概念

▪ Redis集群有16384个哈希槽

▪ 每个key通过CRC16校验后对16384取模来决定放置槽

▪ 集群的每个节点负责一部分哈希槽

▪ Redis-Cluster数据分片

▪ 以3个节点组成的集群为例

节点A包含0到5500号哈希槽

节点B包含5501到11000号哈希槽

节点C包含11001到16384号哈希槽

▪ 支持添加或者删除节点

▪ 添加删除节点无需停止服务

▪ 例如

如果想新添加个节点D，需要移动节点A,B,C中的部分槽到D上

如果想移除节点A，需要将A中的槽移到B和C节点上

Redis-Cluster的主从赋值模型

▪ 集群中具有A,B,C三个节点，如果节点B失败了，整个集群就会因缺少5501-11000这个范围的槽而不可用

▪ 为每个节点添加一个从节点A1,B1,C1，整个集群便有三个master节点和三个slave节点组成，在节点B失败后，集群便会选举B1为新的主节点继续服务

▪ 当B和B1都失败后，集群将不可用

实验：

1：安装redis（每个节点都要安装）

[root@localhost ~]# systemctl stop firewalld

[root@localhost ~]# setenforce 0

[root@localhost ~]# yum -y install gcc* zlib-devel

[root@localhost ~]# tar xvzf redis-5.0.14.tar.gz

[root@localhost ~]# cd redis-5.0.14/

[root@localhost redis-5.0.14]# make

[root@localhost redis-5.0.14]# make PREFIX=/usr/local/redis install

[root@localhost ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/

[root@localhost redis-5.0.14]# cd /root/redis-5.0.14/utils/

[root@localhost utils]# ./install_server.sh

2：修改配置文件（每个节点都要配置，只有IP地址不同，其他都相同）

[root@localhost ~]# vim /etc/redis/6379.conf

 bind 0.0.0.0 ##62行

protected-mode yes

port 6379

tcp-backlog 511

timeout 0

tcp-keepalive 300

daemonize yes

supervised no

pidfile /var/run/redis_6379.pid

loglevel notice

logfile /var/log/redis_6379.log

appendonly yes      ##开启 aof 持久化

。。。。。略。。。。。

cluster-enabled yes ##722行，去掉注释符，表示启用群集

cluster-config-file nodes-6379.conf ##730行，去掉注释

cluster-node-timeout 15000 ##736行，去掉注释

cluster-require-full-coverage no ##813行，去掉注释，将yes改为no

注释：

Ø 开启Cluster：cluster-enabled yes

Ø 集群配置文件：cluster-config-file nodes-7000.conf。这个配置文件不是要我们去配的，而是Redis运行时保存配置的文件，所以我们也不可以修改这个文件。

Ø 集群超时时间：cluster-node-timeout 15000。结点超时多久则认为它宕机了。

Ø 槽是否全覆盖：cluster-require-full-coverage no。默认是yes，只要有结点宕机导致16384个槽没全被覆盖，整个集群就全部停止服务，所以一定要改为no

[root@localhost ~]# /etc/init.d/redis_6379 restart

[root@localhost ~]# netstat -anpt | grep 6379

tcp        0      0 192.168.10.101:6379     0.0.0.0:*               LISTEN      20315/redis-server  

tcp        0      0 192.168.10.101:16379    0.0.0.0:*               LISTEN      20315/redis-server

3：创建redis群集

redis-cli --cluster create --cluster-replicas 1 192.168.10.101:6379 192.168.10.102:6379 192.168.10.103:6379 192.168.10.104:6379 192.168.10.105:6379 192.168.10.106:6379

5：测试群集

[root@localhost ~]# redis-cli -h 192.168.10.106 -p 6379 -c

192.168.10.106:6379> set centos 7.3

192.168.10.106:6379> get centos

192.168.10.106:6379> quit

[root@localhost ~]# redis-cli -h 192.168.10.105 -p 6379 -c

192.168.10.105:6379> get centos

192.168.10.105:6379> quit

注意1：

在创建redis集群服务时，提示以下错误：

/usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis/client.rb:124:in `call': ERR Slot 0 is already busy (Redis::CommandError)

from /usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis.rb:3282:in `block in cluster'

from /usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis.rb:50:in `block in synchronize'

from /usr/local/rvm/rubies/ruby-2.4.5/lib/ruby/2.4.0/monitor.rb:214:in `mon_synchronize'

from /usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis.rb:50:in `synchronize'

from /usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis.rb:3281:in `cluster'

from ./redis-trib.rb:212:in `flush_node_config'

from ./redis-trib.rb:906:in `block in flush_nodes_config'

from ./redis-trib.rb:905:in `each'

from ./redis-trib.rb:905:in `flush_nodes_config'

from ./redis-trib.rb:1426:in `create_cluster_cmd'

from ./redis-trib.rb:1830:in `

'

错误提示是说：slot插槽被占用了、这是因为 搭建集群前时，以前redis的旧数据和配置信息没有清理干净。

解决方案：

             用redis-cli 登录到每个节点执行  flushall  和 cluster reset  就可以了。

注意2：

如果配置文件中没有监听127.0.0.1，在使用/etc/init.d/redis_6379.conf start启动redis服务时（停止或重启都是如此），会提示连接127.0.0.1:6379失败

解决方法：

使用如下方法启动

[root@localhost ~]# redis-server /etc/redis/6379.conf

使用如下命令关闭

[root@localhost ~]# redis-cli -h 192.168.10.103 -p 6379 shutdown

注意3：

配置文件中如果没有监听127.0.0.1的地址，在连接是需要使用如下方法：

redis-cli -h 192.168.10.101 -p 6379

这里的ip为本机监听的ip

注意4：

在做群集的时候各个节点不要监听127.0.0.1的地址，否则，在建立群集时会有如下情况

>>> Creating cluster

>>> Performing hash slots allocation on 6 nodes...

Using 3 masters:

192.168.10.101:6379

192.168.10.102:6379

192.168.10.103:6379

Adding replica 192.168.10.104:6379 to 192.168.10.101:6379

Adding replica 192.168.10.105:6379 to 192.168.10.102:6379

Adding replica 192.168.10.106:6379 to 192.168.10.103:6379

M: 4d06690cfdc9b90f0fd5a03d90c00502b4f33c35 192.168.10.101:6379

   slots:0-5460 (5461 slots) master

M: 9bcde42c8b5f3f1b0c23787cd5776a01eaedb2e1 192.168.10.102:6379

   slots:5461-10922 (5462 slots) master

M: 0f7864b42a3e7ab0f6d738bd066e18d0de1f4893 192.168.10.103:6379

   slots:10923-16383 (5461 slots) master

S: 61165338694dab2381308edf8d63b2a6fc68e558 192.168.10.104:6379

   replicates 4d06690cfdc9b90f0fd5a03d90c00502b4f33c35

S: efe896c8745ce4e001d8c84588ba67a45a243a29 192.168.10.105:6379

   replicates 9bcde42c8b5f3f1b0c23787cd5776a01eaedb2e1

S: 418c2562eedac8f9cce4b1540fc8f9ff4bcf0f1c 192.168.10.106:6379

   replicates 0f7864b42a3e7ab0f6d738bd066e18d0de1f4893

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...............................................................................................................................................................................................................................................................................................................................................................................

系统会一直停留在这里，这是在等待其他节点并入到群集中，，需要在其他slave的主机上接受其master才可以

Adding replica 192.168.10.104:6379 to 192.168.10.101:6379

Adding replica 192.168.10.105:6379 to 192.168.10.102:6379

Adding replica 192.168.10.106:6379 to 192.168.10.103:6379

按照这里的提示登录其他slave

127.0.0.1:6379> CLUSTER MEET 192.168.10.101 6379

然后等待连接即可