网站ftp文件,福州网站大全,誉重网站建设,网站字体颜色大小一、背景与简介 Redis关于高可用与分布式有三个与之相关的运维部署模式。分别是主从复制master-slave模式、哨兵Sentinel模式以及集群Cluster模式。 这三者都有各自的优缺点以及所应对的场景、对应的业务使用量与公司体量。 1、主从master-slave模式 【介绍】 这种模式可以采用… 一、背景与简介 Redis关于高可用与分布式有三个与之相关的运维部署模式。分别是主从复制master-slave模式、哨兵Sentinel模式以及集群Cluster模式。 这三者都有各自的优缺点以及所应对的场景、对应的业务使用量与公司体量。 1、主从master-slave模式 【介绍】 这种模式可以采用一主一从、一主多从、以及树形结构的嵌套复制结构都是支持的。 【优点】 1、配置以及运维相对简单可以支持读写分离master节点负责写操作、slave负责进行读操作同时slave作为master节点数据的一个备份避免由于master节点挂掉整个服务不可用。 【缺点】 1、master节点发生故障时需要人工进行介入增加运维成本。通知客户端修改master的IP地址与端口让slave节点顶上来作为主节点。那么之前的slave节点变成了主节点等之前的old-master节点恢复后反过来作为之前slave节点的从节点。 即使你可以把这个故障切主的过程进行自动脚本化但是怎么确保多个slave中选择哪个slave成为新的主节点以及各种异常情况都能hold得住? 自己写的这个脚本就会变得很复杂。 2、切主暂且不说自动化脚本还能解决但是你让业务方切换IP端口这个事情万万是不能被接受的。用到这个Redis的地方太多了你想改也改不过来改了要发新配置代码还有就是怕漏改。即使你使用Nacos等配置中心也是一件让人头疼的事情 基于以上的几点考虑官方推出了哨兵Sentinel模式将这个过程自动化。切换流程不需要我们自己编写脚本哨兵模式会可靠地帮我们完成这个故障切换过程同时客户端也无须改变任何IP端口无感进行故障切换。 【适应的公司体量】 小公司、创业公司或者业务量不是特别大的公司 2、哨兵Sentinel模式 【介绍 】 哨兵Sentinel模式其实是将master-slave主从模式故障切换从人工介入换成了自动化切换的过程哨兵节点会高效、快速、可靠的从剩余的slave节点中选择出1个合适的节点作为新的master主节点之后将剩余的slave节点切主到这个新的master节点。同时客户端要获取master节点信息要通过连接sentinel来获取master的IP和端口这样每次切主的过程程序会自动完成无感迁移。 【优点】 1、官方原生支持高可用方案比第一种master-slave手动写切换脚本以及通知业务方更换IP端口更加方便、可靠、稳定 【缺点】 1、虽然哨兵解决了高可用问题但是无法解决高容量、高并发的需求。 因为一个哨兵始终只是维护master-slave的高可用而已不能解决高并发、高容量问题。 这个后续的Cluster集群模式可以来解决。 2、切主的过程可能会存在客户端短时间内连接不上master的情况这个时间取决于故障迁移恢复时间。因为master节点挂了哨兵在做故障迁移没结束之前,哨兵存储的master的信息还是挂掉的IP端口自然客户端继续连接挂掉的主机IP端口就无法进行正常数据读写。 【适应的公司体量】 稍微有点业务体量与规模的公司 3、集群Cluster模式 【介绍】 集群Cluster模式支持分布式部署采用虚拟槽的设计思路将存储的key进行CRC16($key)%16383的方式对数据进行分片存储和读取。 一共存在0-16383的slot虚拟槽位 一个虚拟槽位slot理论上可以支持一个masterN个slave的主从架构模式。 那就是理论上可以支持16383个masterslave的主从架构模式 这样的量就已经很牛逼了。 同时集群模式本身就支持高可用一旦slot节点的master-slave主从结构的主节点挂了那么会从它所属的slot的master-slave主从结构中进行重新切主操作。 不过官方推荐整个Redis集群不超过1000个节点。 想想一下就算是1000个如果按照一台服务器16G内存的情况计算如果一半的内存进行存储也就是8G整个集群的容量高达80TB。 这种基本上除了一线互联网大厂能玩得转我看其它公司也没这个运维能力以及需求量了。 【优点】 1、支持高容量、高并发访问量的需求官方原生支持、可靠稳定 2、同时支持高可用模式自动切主实现故障迁移。 虽然故障迁移期间客户端也可能会出现无法正常访问Redis集群的情况但是只会影响落到这个slot的这些key 其它的key还是能正常访问的具体还得按照实际情况计算节点越多单个slot故障影响越小,可能只存在20-30%无法访问可以理解只是挂了部分。但是哨兵模式切主过程中产生不可用的情况就不一样哨兵模式是故障迁移期间整体100%都无法访问。 【缺点】 1、对公司运维团队要求很高运维成本高、同时成本也会变高 【适应的公司体量】 一线或者二线的互联网大厂 二、哨兵Sentinel-简单实验
1、主从配置是Sentinel、Cluster的基础 例如存在A节点作为master节点存在2个slave节点分别是A1、A2. 那么在A1、A2分别执行
slaveof $master_ip $master_port 即可完成A作为master节点,A1、A2作为其slave节点的一主两从的拓扑结构。 这个过于简单就不再演示今天重点做Sentinel哨兵的故障模拟和迁移实验
2、环境搭建与测试
1、环境介绍 我们准备3个sentinel节点 以及一个一主两从的结构。 让这个3个sentinel哨兵节点对整个一主两从进行监听与负责故障转移。
hostnameIP端口角色备注s1192.168.32.326379sentinel哨兵节点s2192.168.32.226379sentinel哨兵节点s3192.168.32.426379sentinel哨兵节点master192.168.32.76379master节点slave1192.168.32.56379slave节点主节点是masterslave2192.168.32.66379slave节点主节点是master docker-compose.yaml文件内容如下:
version: 3
services:s1:image: redis:5.0hostname: s1volumes:- ./redis-sentinel-26379.conf:/data/redis-sentinel-26379.confentrypoint: [ tail, -f, /dev/null ]s2:image: redis:5.0hostname: s2volumes:- ./redis-sentinel-26379.conf:/data/redis-sentinel-26379.confentrypoint: [ tail, -f, /dev/null ]s3:image: redis:5.0hostname: s3volumes:- ./redis-sentinel-26379.conf:/data/redis-sentinel-26379.confentrypoint: [ tail, -f, /dev/null ]master:image: redis:5.0hostname: masterentrypoint: [tail, -f, /dev/null]slave1:image: redis:5.0hostname: slave1entrypoint: [tail, -f, /dev/null]slave2:image: redis:5.0hostname: slave2entrypoint: [tail, -f, /dev/null]
2、Sentinel哨兵的配置文件
redis-sentinel-26379.conf:
port 26379
daemonize yes
logfile 26379.log
dir /data/
sentinel monitor mymaster master 6379 2 #Sentinel监控集群别名mymaster监控的master这个用的host别名,可以写IP形式: 192.168.32.7 6379是端口 2是指投票个数
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 180000 3、首先启动1主2从结构
docker-compose up -d --build #启动所有容器# master节点
docker-compose exec master bash #进入master容器
redis-server /dev/null #运行redis-server进入后台# slave1节点
docker-compose exec slave1 bash #进入slave1容器
redis-server /dev/null #运行redis-server进入后台
redis-cli #进入控制台
slaveof master 6379 #切主
info replication #查看主从复制情况# slave2节点
docker-compose exec slave2 bash #进入slave2容器
redis-server /dev/null #运行redis-server进入后台
redis-cli #进入控制台
slaveof master 6379 #切主
info replication #查看主从复制情况 查看master节点的集群节点信息: info replication 可以看到存在2个slave节点分别是192.168.32.5(slave1)、192.168.32.6(slave2)正常连接运行
4、依次启动s1、s2、s3的Sentinel节点
redis-sentinel redis-sentinel-26379.conf #后台运行sentinel节点程序
5、通过Sentinel API命令查看当前的master信息
sentinel masters 查询结果如下: 6、模拟master节点故障将master容器进行docker-compose stop操作 再次进入s1 sentinel节点运行redis-cli, 执行sentinel masters指令查看当前master的信息: 此时可以看到本来master是192.168.32.7是主节点后来模拟故障将这个节点进行stop操作。此时故障迁移已经完成, 从192.168.32.5、192.168.32.6选择了192.168.32.5做为新的master节点.
同时我们进入192.168.32.5(slave1)查看当前info replication信息: 7、恢复刚才的master容器此时slave1再运行info replication会多出从节点 从slave1节点运行info replication此时可以看到192.168.32.7从一开始的主节点反过来变成了slave1的从节点, slave1已经变成了新的master主节点: 三、总结 选择简单主从模式、哨兵模式、或者集群模式可以根据自己公司的业务量以及运维团队规模进行评估选择合适的方案。 高可用一直和成本成反比关系想要高可用那么付出的成本要变高无论是运维成本还是资金成本 反之如果降低成本那么可用性就会降低。 公司体量还很小处于起步阶段推荐简单主从模式基本上够用了成本也不会很高。 如果已经稍微上规模了还是推荐使用哨兵模式这样故障迁移的过程就会自动化无须人工介入更加稳定。 如果已经是发展到哨兵模式都无法满足业务需求了再考虑使用Cluster集群模式能够满足更高容量、高并发访问量的需求。 上面的这些模式都是基于IDC自己运维的机房或者自行搭建的机房环境如果上云自己想追求高可用性和可靠性但是又没那么多运维精力的话可以直接买云厂商的Redis服务即可付钱买服务即可。
