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

介绍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主从复制

参照:https://www.jb51.net/article/224568.htm

上述图片描述的是:1个主库 + 2 个从库。同时两个从库,本身就各带有2个从库。

Redis集群数据复制的原理

1、同步SYNC:主服务器收到SYNC命令后,生成RDB快照文件,然后发送给从服务器

  1. 发送psync命令进行数据同步,由于是第一次进行复制,从节点没有复制偏移量和主节点的运行ID,所以发送psync-1。
  2. 主节点根据psync-1解析出当前为全量复制,回复+FULLRESYNC响应。
  3. 从节点接收主节点的响应数据保存运行ID和偏移量offset
  4. 主节点执行bgsave保存RDB文件到本地
  5. 主节点发送RDB文件给从节点,从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件
  6. 对于从节点开始接收RDB快照到接收完成期间,主节点仍然响应读写命令,因此主节点会把这期间写命令数据保存在复制客户端缓冲区内,当从节点加载完RDB文件后,主节点再把缓冲区内的数据发送给从节点,保证主从之间数据一致性。
  7. 从节点接收完主节点传送来的全部数据后会清空自身旧数据
  8. 从节点清空数据后开始加载RDB文件
  9. 从节点成功加载完RDB后,如果当前节点开启了AOF持久化功能, 它会立刻做bgrewriteaof操作,为了保证全量复制后AOF持久化文件立刻可用。

2、命令传播:主服务器收到客户端修改数据命令后,数据库数据发生变化,同时将命令缓存起来,然后将缓存命令发送到从服务器,从服务器通过载入缓存命令来达到主从数据一致。

命令传播的方式是:使用psync {runId} {offset}

下面介绍的是命令传播中图遇到失败的情况。

  1. 当主从节点之间网络出现中断时,如果超过repl-timeout时间,主节点会认为从节点故障并中断复制连接
  2. 主从连接中断期间主节点依然响应命令,但因复制连接中断命令无法发送给从节点,不过主节点内部存在的复制积压缓冲区,依然可以保存最近一段时间的写命令数据,默认最大缓存1MB。
  3. 当主从节点网络恢复后,从节点会再次连上主节点
  4. 当主从连接恢复后,由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当作psync参数发送给主节点,要求进行部分复制操作。
  5. 主节点接到psync命令后首先核对参数runId是否与自身一致,如果一 致,说明之前复制的是当前主节点;之后根据参数offset在自身复制积压缓冲区查找,如果偏移量之后的数据存在缓冲区中,则对从节点发送+CONTINUE响应,表示可以进行部分复制。
  6. 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点,保证主从复制进入正常状态。

了解上述两种机制后,Redis集群数据复制的原理就是:从库向主库发送SYNC命令,主库开始执行bgsave生成RDB文件,发送给从库。如果此时主库生成完RDB文件,主库依旧有命令操作数据变化,主库就利用命令传播机制,将主库的变化命令给从库。

看一下别人上传的时序图

配置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

以下均是 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
redis-cli -p 6379

输入info,执行后会打印大量的信息,如果想了解具体含义,可以前往:https://www.zanglikun.com/7123.html
info

Redis 主从复制 优缺点

优点:提供了可用性(可以实现读写分离),从库多了,宕机一个问题不大。

缺点:

  • master节点挂了需要人工干预切换master节点
  • master节点宕机后,恢复瞬间会有大量从节点SYNC命令进来,Master节点 IO压力大。

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再减一

3个哨兵的配置

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的奇数

下面是启动3个哨兵的命令
/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-server端(非哨兵)的配置文件,加入replica-priority参数,此数值越小,被推为主节点优先级越高!选值是 0-100,如果是0,则不会被选举为主节点。设置为1即可。

哨兵原理

1、检测主节点挂了

2、确定主节点挂了,Sentinel将server2升级为主服务器,server3/4从新的主服务器进行复制。同时等待server1的再次上线。

3、如果Server1此事正常了。Sentinel系统也可以主动降级主节点为从节点,将从节点升级为主节点。

底层实现机制

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就会拒绝写入!大大减少了脑裂造成的数据丢失!脑裂一般无法满足一个数据不丢失!

Redis哨兵模式的缺点

优点:主要用来监控redis主从集群,提高了redis 主从集群的可用性。

缺点:Redis较难支持在线扩容(我不是很理解在线扩容的含义)

Cluster模式

Redis Cluster是一种服务器 Sharding 技术,redis 3.0版本开始正式提供。
哨兵模式基本已经实现了高可用,但是每台机器都存储相同内容,很浪费内存,所以Redis Cluster实现了分布式存储。每台机器节点上存储不同的内容。

Cluster模式的每一个主机都是主节点,同时会对每个节点进行Slot范围划分。大意就是。每次操作执行读写操作时,会依据key做算法判定,得出slot数,针对slot范围,读写操作就针对某个节点了。

操作落在那个节点公式是:slot = crc16(“KeyName”) % 16384

Redis Cluster数据分片原理

redis 数据分片使用的是hash slot, redis集群有16384个哈希槽(用bitmap存储就是占有内存2kb,大意就是最多16384个节点,正常业务不会超过那么多的节点的),每个Key通过CRC16校验后对16384取模来决定放置哪一个槽。
当存取redis key时候,redis会根据CRC16算法得到一个结果,然后把结果和16384求余,通过这个值去对应得节点获取数据。
这个时候,应用客户端实际上只需要连接其中任意一个节点即可,然后Redis Cluster 中每个节点都保存了其他节点得槽信息。这样当存取key计算完槽之后,通过保存槽信息从配置中获取节点信息,然后再去对应得节点获取数据。

Redis建议Cluster模式是3主3从模式,一共6个节点。

如果构建了3主3从模式。

如果:主节点挂了,会把从节点推选为新主节点。如果老主节点恢复,就加入从节点。

如果:主节点挂了,从节点也挂了,整个集群拒绝执行。

1、实现了分布式存储,节省了内存

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

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

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

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

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

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