集群是个好东西,一个应用解决不了的,多个应用共同分担。提高了程序的高可用!

介绍redis-benchmark

项目遇到性能问题,基本都会以集群方式去解决。在讲Redis的集群之前,我们先学会Redis的性能压力测试。–redis-benchmark

redis 服务在windows环境下的启动命令是redis-server.exe ,在此文件夹,往往还存在一个新的文件redis-benchmark.exe,此文件就是用来进行redis的压力测试的!(linux环境也是一样的!) 中文官网说明:http://www.redis.cn/topics/benchmarks.html

Mac 安装Redis

# Mac 显示隐藏文件夹
defaults write com.apple.finder AppleShowAllFiles -boolean true ; killall Finder
# 1 查看是否安装 Homebrew
brew --version

# 2 安装redis
brew install redis

# 3 卸载redis
brew cleanup redis

# 4 启动redis
/opt/homebrew/opt/redis/bin/redis-server /opt/homebrew/etc/redis.conf

测试性能

redis-benchmark -q -n 100000
仅仅截取常规的命令速度,可以看出来M1 Pro,每秒处理10万个请求没问题!我也加大了10万连接数调整为20万,实际速度能达到12万左右

实际每秒10万的处理性能已经很不错了!足够面对企业服务器的需求了!

Redis主从复制

配置Redis一主二从结构

不同版本的Redis配置命令发生变化了:replicaof是新版本的命令,旧版本是slaveof命令

# 主节点 master
port 6379
# 从节点1 slave1
port 6380
# replicaof <masterip> <masterport>
replicaof 127.0.0.1 6379
# 从节点2 slave2
port 6381
# replicaof <masterip> <masterport>
replicaof 127.0.0.1 6379

启动主从Redis

 /opt/homebrew/opt/redis/bin/redis-server /opt/homebrew/etc/redis01.conf

 /opt/homebrew/opt/redis/bin/redis-server /opt/homebrew/etc/redis02.conf

 /opt/homebrew/opt/redis/bin/redis-server /opt/homebrew/etc/redis03.conf

检查Redis 主从状态信息

redis-cli -p 6379

输入 info

Redis哨兵模式 Redis Sentinel

什么是Redis哨兵模式?

redis主从复制有个最大的确定就是,主节点挂了,需要人工干预才能保证业务的正常运行。Redis主从复制对主从服务器做一个监视的任务。一旦发现主服务器宕机了,就迅速启动相应的规则将某一台从服务器升级为主服务器,无需人工干预,更稳定更快

本质就是一个Redis服务器,只是用于监控,不可set,get相关命令!

使用Redis哨兵模式的前提是,至少拥有Redis集群的一个主从结构!

Redis哨兵配置文件

配置文件必须加入下方内容

sentinel monitor master-name ip port quorum

# 配置master节点的密码
#sentinel auth-pass master-name 我是密码

上述配置参数讲解

  • master-name 监控主节点的名字,多个哨兵需要配置一致 一般配置为 mymaster
  • ip 表示:redis主节点ip
  • port 表示:redis主节点port
  • quorum 表示:判定某节点被哨兵标记为挂掉的哨兵数量,一般配置为哨兵数量除2再减一
port 26379
dir /tmp/redis-test-data-dir
sentinel monitor mymaster 127.0.0.1 6379 2 
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
port 26380
dir /tmp/redis-test-data-dir
sentinel monitor mymaster 127.0.0.1 6379 2 
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
port 26381
dir /tmp/redis-test-data-dir
sentinel monitor mymaster 127.0.0.1 6379 2 
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

启动哨兵 (需提前开启redis主从模式)

哨兵会自动组建集群:我们一般不会单独配置一个哨兵,而是配置哨兵数量为:大于1的奇数,一般为三个。因为哨兵需要进行投票。如果只有1个哨兵,发现redis服务器有问题,很有可能是其自己的网络问题。如果有2个哨兵,一个哨兵,发现故障,另一个哨兵没发现故障,我们就不知要不要切换新的master节点了。如果有3个哨兵,我们就可以设定半数投票机制。如果认定失败数大于总哨兵数一半以上,就认定是相对比较合理的。如果哨兵设置为偶数个,相互投票,可能投票数打平。建议为大于1的奇数

/opt/homebrew/opt/redis/bin/redis-sentinel /opt/homebrew/etc/redis-sentinel01.conf

/opt/homebrew/opt/redis/bin/redis-sentinel /opt/homebrew/etc/redis-sentinel02.conf

/opt/homebrew/opt/redis/bin/redis-sentinel /opt/homebrew/etc/redis-sentinel03.conf

当每新开启一个哨兵后,前面的哨兵的配置文件就会发生变化,添加了新哨兵的信息!

如果发生主节点宕机,我们可以简单干预主从切换,那就需要在redis服务端的配置文件,加入replica-priority,此数值越小,优先级越高!选值是 0-100,如果是0,则不会被选举为主节点。设置为1即可。

哨兵原理

1、监控阶段

哨兵1连接master,获取子节点与其记录的哨兵信息,再与master建立cmd连接,如果有其他哨兵,使用发布订阅,公开获取最新的redis服务器信息,其他哨兵获取后,同步自己的数据

哨兵1通过上一步的信息,连接其他Redis子节点并获取其记录的哨兵信息,并建立cmd连接

哨兵2连接master,获取子节点与其他哨兵信息,并与master建立cmd连接

哨兵2通过上一步的信息,连接子节点与其他哨兵信息,并建立与子节点cmd连接,于此同时,使用发布订阅,公开获取最新的redis服务器信息,其他哨兵获取后,同步自己的数据

2、通知阶段

每个哨兵都会与redis服务器进行通信,通信失败后,就会给此服务器标记状态,分为:

sdown主观下线 odown客观下线

sdown 是有哨兵与任一redis节点进行通信,如ping pong,如果在down-after-milliseconds时间内此节点没有响应,则该哨兵认为此redis节点主观下线了。

如果是认定master主观下线的哨兵则会通过指令sentinel is-masterdown-by-addr寻求其它哨兵对主节点的判断,当超过quorum(在sentinel配置中配置的法定人数)个数,此时哨兵节点则认为该主节点确实有问题,这样就客观下线了。一旦触发客观下线,就会触发第三步:故障转移

尚不清晰,非master节点宕机,哨兵会不会判定客观下线,我本机测试只有sdown

3、故障转移

哨兵之间推选出故障转移的哨兵

故障转移的哨兵,拿到所有节点,经过一些列判断,选出主redis服务器

通知选举出的主redis服务器,你作为master服务器了

通知其他从服务器:新的master信息

redis脑裂

redis脑裂是当前master节点与所有哨兵断开连接,但实际是正常的,但是原有哨兵,就安排了新的master出来。也就是说,同时存在了2个master了。客户端有多个连接,有的连接老master,有的连接新master。2个master之间数据是不一样的,过了一段时间,老master网络正常了,加入集群中,就会作为从节点,同步新master的数据,(同步过程是,A发起同步请求,B会打包rdb文件,A拿到rdb文件 A执行flusb db,A还原rdb数据)导致老master在没加入集群期间,新数据的丢失!

解决redis脑裂

redis配置文件添加

min-slaves-to-write :是指主库最少得有 N 个健康的从库存活才能执行写命令。建议设定为:slaves的数量/2 +1

min-slaves-max-lag :是指从库和主库进行数据复制时的 ACK 消息延迟的最大时间;

新版本Redis 配置变更为:

min-replicas-to-write 3
min-replicas-max-lag 10

如果同时存在多个master,必然有1个master不会拥有子节点。设置min-slaves-to-write后,老master发现没有足够的从节点,就会拒绝写入服务。如果同时设定了min-slaves-max-lag,就变为足够满足从节点数且其复制时间不超过指定时间,master才能正常使用。如果无法满足master就会拒绝写入!大大减少了脑裂造成的数据丢失!脑裂一般无法满足一个数据不丢失!

发表回复

您的电子邮箱地址不会被公开。

本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。

最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量,若小于网盘提示的容量则是这个原因。这是浏览器下载的bug,建议用百度网盘软件或迅雷下载。 若排除这种情况,可在对应资源底部留言,或联络我们。

对于会员专享、整站源码、程序插件、网站模板、网页模版等类型的素材,文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买,且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况,但部分素材会在素材包内有一份字体下载链接清单。

如果您已经成功付款但是网站没有弹出成功提示,请联系站长提供付款信息为您处理

源码素材属于虚拟商品,具有可复制性,可传播性,一旦授予,不接受任何形式的退款、换货要求。请您在购买获取之前确认好 是您所需要的资源