一、Redis集群方式
主从模式、哨兵模式、集群模式(cluster)
主从复制:解决数据备份,读写分离。但是无法实现自动化故障转移,无法对master进行扩容。
哨兵模式:实现自动化故障恢复。在读写分离下,单节点导致服务不可用。
集群模式:解决负载均衡以及存储问题。
模式 | 版本 | 优点 | 缺点 |
主从模式 | redis2.8之前 | 1、解决数据备份问题 | 1、master故障,无法自动故障转移,需人工介入 |
哨兵模式 | redis2.8级之后的模式 | 1、Master 状态监测 | 1、slave节点下线,sentinel不会对其进行故障转移,连接从节点的客户端因为无法获取到新的可用从节点 |
redis cluster模式 | redis3.0版本之后 | 1、有效的解决了redis在分布式方面的需求 | 1、架构比较新,最佳实践较少 |
二、集群模式简介
集群中的节点分为主节点和从节点;只有主节点负责读写请求和集群信息的维护;从节点只进行主节点数据和状态信息的复制。
redis集群采用master-slave的方式,即1个master节点可以包含多个slave节点,slave节点主要对master节点的数据进行备份,如果master节点挂了,可以启动salve节点替换掉原先的master节点,作为新的master节点。redis集群使用投票容错机制,如果集群中超过半数以上的节点投票认为某节点挂了,那么这个节点就会被认为挂掉了,所以,在设置redis集群时,最少的master节点为3个,如果每一个master节点都添加一个slave节点的话,搭建一个redis集群总共需要6个节点,即3个master节点,3个slave节点。
redis集群没有统一的入口,客户端连接集群的时候,连接集群中的任意节点即可。
redis集群的运用主要是针对海量数据+高并发+高可用的场景。
三、数据分片方式
经过CRC16哈希到一个指定的Node上,这个过程即redis cluster的分片,集群内部将所有的key映射到16384个Slot中,集群中的每个Redis Instance负责其中的一部分的Slot的读写。
集群客户端连接集群中任一Redis Instance即可发送命令,当Redis Instance收到自己不负责的Slot的请求时,会将负责请求Key所在Slot的Redis Instance地址返回给客户端,客户端收到后自动将原请求重新发往这个地址,对外部透明。一个Key到底属于哪个Slot由 (HASH_SLOT = CRC16(key) mod 16384) 决定。只有master节点会被分配槽位,slave节点不会分配槽位。
具体的分片方式有客户端分片、代理分片和Twemproxy 代理分片机制。
(一)客户端分片
客户端分片方案是将分片工作放在业务程序端。程序代码根据预先设置的路由规则,直接对多个 Redis 实例进行分布式访问。这样的好处是,群集不依赖于第三方分布式中间件,实现方法和代码都自己掌控,可随时调整,不用担心踩到坑。这实际上是一种静态分片技术,Redis 实例的增减,都得手工调整分片程序。基于此分片机制的开源产品,现在仍不多见。
这种分片机制的性能比代理式更好(少了一个中间分发环节),但缺点是升级麻烦,对研发人员的个人依赖性强,需要有较强的程序开发能力做后盾。如果主力程序员离职,可能新的负责人会选择重写一遍。所以这种方式下可运维性较差,一旦出现故障,定位和解决都得研发人员和运维人员配合解决,故障时间变长。因此这种方案,难以进行标准化运维,不太适 合中小公司。
(二)代理分片
代理分片方案是将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求,根据路由规则,将这些请求分发给正确的 Redis 实例并返回给业务程序。这种机制下,一般会选用第三方代理程序(而不是自己研发)。因为后端有多个 Redis 实例,所以这类程序又称为分布式中间件。这种分片机制的好处是业务程序不用关心后端 Redis实例,维护起来也方便。虽然会因此带来些性能损耗,但对于 Redis 这种内存读写型应用,相对而言是能容忍的。这是比较推荐的集群实现方案。像 Twemproxy、Codis 就是基于该机制的开源产品的其中代表,应用非常广泛。
1.Twemproxy 代理分片机制
Twemproxy 是一种代理分片机制,由 Twitter 开源。Twemproxy 作为代理,可接受来自多个程序的访问,按照路由规则,转发给后台的各个 Redis 服务器,再原路返回。这个方案顺理成章地解决了单个 Redis 单实例问题。当然 Twemproxy 本身也是单点,需要用Keepalived 做高可用方案。在很长的时间内,Twemproxy 是应用范围最广、稳定性最高、最久经考验的分布式中间件。
这种分片方式无法平滑地扩容/缩容,增加了运维难度。当业务量突增需要增加 Redis 服务器或业务量萎缩需要减少 Redis 服务器时,Twemproxy 都无法平滑地进行扩容或缩容等操作。
Twemproxy 代理分片机制对运维操作不友好,甚至没有控制面板。由于使用了中间件代理,相比客户端直接连接服务器方式,性能上有所损耗,实测性能效果降低了 20%左右。
2.Codis 代理分片机制
Codis 由豌豆荚于 2014 年 11 月开源,基于 Go 语言和 C 语言开发,是近期涌现的、国人开发的优秀开源软件之一,现已广泛用于豌豆荚的各种 Redis 业务场景。从各种压力测试来看,Codis 的稳定性符合高效运维的要求。
Codis 引入了 Group 的概念,每个 Group 包括 1 个 Redis Master 及至少 1 个 RedisSlave,这是和 Twemproxy 的区别之一。这样做的好处是,如果当前 Master 有问题,则运维人员可通过 Dashboard“自助式”切换到 Slave,而不需要小心翼翼地修改程序配置文件。
(二)服务器端分片
服务器端分片是 Redis 官方的集群分片技术。Redis-Cluster 将所有 Key 映射到 16384个 slot 中,集群中每个 Redis 实例负责一部分,业务程序是通过集成的 Redis-Cluster 客户端进行操作。客户端可以向任一实例发出请求,如果所需数据不在该实例中,则该实例引导客户端自动去对应实例读写数据。Redis-Cluster 成员之间的管理包括节点名称、IP、端口、状态、角色等,都通过节点与之间两两通讯,定期交换信息并更新。
四、多slave选举
在多个slave情况下如果一个master宕机,需要基于Raft协议选举方式来实现的新主的选举。步骤如下:
- 当从节点发现自己主master下线后,从节点广播故障切换请求。master向节点投票。
- master进行投票,master向slave返回故障切换请求,表示支持slave成为新的master。
- slave根据请求统计有多少master支持。
- 集群里有N个master,slave收到N/2 +1票时,成为新的master。
- 若没有足够的支持票数,则重新选举。
五、案例分析
(一)安装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
(二)修改配置文件
[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
(三)创建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
(四)测试群集
[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
(五)集群信息查看
[root@localhost ~]# redis-cli
192.168.10.106:6379> cluster nodes
(六)添加节点
方法一
[root@localhost ~]# redis-cli -c -p 6379 cluster meet 192.168.10.107 6379
OK
[root@localhost ~]# redis-cli
127.0.0.1:6379> cluster nodes
注意:
添加完后此新节点是master的角色
方法二
redis-cli --cluster add-node 192.168.10.109:6379 192.168.10.107:6379
注意:
10.109是要新添加的节点,10.107是当前集群中的任意一个节点
(七)修改新节点称为其他节点从节点
[root@localhost ~]# redis-cli -h 192.168.10.109 -p 6379
192.168.10.109:6379> cluster replicate 5472bbc9226737ca2199e146080ddaa41686a694
让10.109称为10.107的从节点,此ID是10.107的ID
(八)重新分配槽位
重新分片基本上意味着将slot 重新分配,就像集群创建一样,它是使用 redis-cli 实用程序完成的。
注意:平均分配所有的槽位,使用以下命令会自动降16384个槽位自动分配给集群的每一个master,不用手动指定槽为分配。
redis-cli --cluster rebalance --cluster-threshold 1 --cluster-use-empty-masters 192.168.10.101:6379
只需要指定一个老的节点(10.21.108.174:3001),redis 会自动查找其他节点。
(九)删除节点
1.清除10.109的槽位信息
[root@localhost ~]# redis-cli -h 192.168.10.109 -p 6379
192.168.10.109:6379> flushall
OK
192.168.10.109:6379> cluster reset
OK
2.删除10.109的节点
redis-cli --cluster del-node 192.168.10.101:6379 fe75330d96c2c3af9c5a02b9819d66b2e8a48da2
注意:
此ID为10.107的ID
标签:Redis,redis,模式,6379,集群,192.168,master,节点 From: https://blog.csdn.net/zheshijiuyue/article/details/140375453