消息队列
消息队列: 把要传输的数据放在队列中
功能: 可以实现多个系统之间的解耦,异步,削峰/限流等 常用的消息队列应用: kafka,rabbitMQ,redis
消息队列主要分为两种,这两种模式Redis都支持
生产者/消费者模式 发布者/订阅者模式
生产者消费者模式
在生产者/消费者(Producer/Consumer)模式下，上层应用接收到的外部请求后开始处理其当前步骤的操 作，在执行完成后将已经完成的操作发送至指定的频道(channel,逻辑队列)当中，并由其下层的应用监听 该频道并继续下一步的操作，如果其处理完成后没有下一步的操作就直接返回数据给外部请求，如果还 有下一步的操作就再将任务发布到另外一个频道，由另外一个消费者继续监听和处理。此模式应用广泛
模式介绍
生产者消费者模式下，多个消费者同时监听一个队列，但是一个消息只能被最先抢到消息的消费者消 费，即消息任务是一次性读取和处理，此模式在分布式业务架构中很常用，比较常用的消息队列软件还有RabbitMQ、Kafka、RocketMQ、ActiveMQ等。
队列介绍
队列当中的消息由不同的生产者写入，也会有不同的消费者取出进行消费处理，但是一个消息一定是只能被取出一次也就是被消费一次。
生产者发布消息
[root@redis ~]# redis-cli 127.0.0.1:6379> AUTH 123456 OK 127.0.0.1:6379> LPUSH channel1 msg1 #从管道的左侧写入 (integer) 1 127.0.0.1:6379> LPUSH channel1 msg2 (integer) 2 127.0.0.1:6379> LPUSH channel1 msg3 (integer) 3 127.0.0.1:6379> LPUSH channel1 msg4 (integer) 4 127.0.0.1:6379> LPUSH channel1 msg5 (integer) 5
查看队列所有消息
127.0.0.1:6379> LRANGE channel1 0 -1 1) "msg5" 2) "msg4" 3) "msg3" 4) "msg2" 5) "msg1"
消费者消费消息
127.0.0.1:6379> RPOP channel1 #从管道的右侧消费，用于消息的先进先出 "msg1" 127.0.0.1:6379> RPOP channel1 "msg2" 127.0.0.1:6379> RPOP channel1 "msg3" 127.0.0.1:6379> RPOP channel1 "msg4" 127.0.0.1:6379> RPOP channel1 "msg5" 127.0.0.1:6379> RPOP channel1 (nil)
再次验证队列消息
127.0.0.1:6379> LRANGE channel1 0 -1 (empty list or set) #队列中的消息已经被已全部消费完毕
发布者订阅模式
扫描二维码关注公众号，回复：
13223912 查看本文章
模式简介
在发布者订阅者模式下，发布者将消息发布到指定的channel里面，凡是监听该channel的消费者都会收 到同样的一份消息，这种模式类似于是收音机的广播模式，即凡是收听某个频道的听众都会收到主持人发布的相同的消息内容。此模式常用语群聊天、群通知、群公告等场景
Publisher：发布者
Subscriber：订阅者
Channel：频道
订阅者监听频道
[root@redis ~]# redis-cli 127.0.0.1:6379> AUTH 123456 OK 127.0.0.1:6379> SUBSCRIBE channel1 #订阅者事先订阅指定的频道，之后发布的消息才 能收到 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 1
发布者发布消息
127.0.0.1:6379> PUBLISH channel1 test1 #发布者发布消息 (integer) 2 #订阅者个数 127.0.0.1:6379> PUBLISH channel1 test2 (integer) 2
各个订阅者都能收到消息
订阅多个频道
#订阅指定的多个频道 127.0.0.1:6379> SUBSCRIBE channel1 channel2
订阅所有频道
127.0.0.1:6379> PSUBSCRIBE * #支持通配符*
订阅匹配的频道
127.0.0.1:6379> PSUBSCRIBE chann* #匹配订阅多个频道
取消订阅
127.0.0.1:6379> unsubscribe channel1 1) "unsubscribe" 2) "channel1" 3) (integer) 0
redis 集群与高可用
虽然Redis可以实现单机的数据持久化，但无论是RDB也好或者AOF也好，都解决不了单点宕机问题，即 一旦单台 redis服务器本身出现系统故障、硬件故障等问题后，就会直接造成数据的丢失
此外,单机的性能也是有极限的,因此需要使用另外的技术来解决单点故障和性能扩展的问题。
redis 主从复制
redis 主从复制架构
主从模式（master/slave），可以实现Redis数据的跨主机备份。 程序端连接到高可用负载的VIP，然后连接到负载服务器设置的Redis后端real server，此模式不需要在 程序里面配 置Redis服务器的真实IP地址，当后期Redis服务器IP地址发生变更只需要更改redis 相应的 后端real server即可， 可避免更改程序中的IP地址设置。
主从复制特点
一个master可以有多个slave 一个slave只能有一个master 数据流向是从master到slave单向的
主从复制实现
Redis Slave 也要开启持久化并设置和master同样的连接密码，因为后期slave会有提升为master的可 能,Slave 端切换master同步后会丢失之前的所有数据,而通过持久化可以恢复数据 一旦某个Slave成为一个master的slave，Redis Slave服务会清空当前redis服务器上的所有数据并将 master的数据导入到自己的内存，但是如果只是断开同步关系后,则不会删除当前已经同步过的数据。 当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。否则的话，由于延迟等问题，部署的主 节点Redis服务应该要避免自动启动。
参考案例: 导致主从服务器数据全部丢失
1.假设节点A为主服务器，并且关闭了持久化。并且节点B和节点c从节点A复制数据 2.节点A崩溃，然后由自动拉起服务重启了节点A.由于节点A的持久化被关闭了，所以重启之后没有任何数据 3.节点B和节点c将从节点A复制数据，但是A的数据是空的，于是就把自身保存的数据副本删除。
在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现Redis的高可 用性，也是非常危险的。因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没 有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动启动。
命令行配置
启用主从同步
默认redis 状态为master，需要转换为slave角色并指向master服务器的IP+PORT+Password 在从节点执行REPLICAOF MASTER_IP PORT 指令可以启用主从同步复制功能,早期版本使用 SLAVEOF指令（注意防火墙问题Firewalld）
127.0.0.1:6379> REPLICAOF MASTER_IP PORT 127.0.0.1:6379> CONFIG SET masterauth <masterpass>
范例：
#在mater上设置key1 [root@centos8 ~]# redis-cli 127.0.0.1:6379> AUTH 123456 OK 127.0.0.1:6379> config get requirepass 1) "requirepass" 2) "" 127.0.0.1:6379> config set requirepass 123456 OK 127.0.0.1:6379> config get requirepass (error) NOAUTH Authentication required. 127.0.0.1:6379> auth 123456 OK 127.0.0.1:6379> config get requirepass 1) "requirepass" 2) "123456" 127.0.0.1:6379> INFO replication # Replication role:master connected_slaves:0 ... 127.0.0.1:6379> SET key1 v1-master OK 127.0.0.1:6379> KEYS * 1) "key1" 127.0.0.1:6379> GET key1 "v1-master" 127.0.0.1:6379>
范例：
#以下都在slave上执行，登录 [root@centos8 ~]# redis-cli 127.0.0.1:6379> info NOAUTH Authentication required. 127.0.0.1:6379> AUTH 123456 OK 127.0.0.1:6379> INFO replication #查看当前角色默认为master # Replication role:master connected_slaves:0 ... 127.0.0.1:6379> SET key1 v1-slave-18 OK 127.0.0.1:6379> KEYS * 1) "key1" 127.0.0.1:6379> GET key1 "v1-slave-18" 127.0.0.1:6379> #在第二个slave,也设置相同的key1,但值不同 127.0.0.1:6379> KEYS * 1) "key1" 127.0.0.1:6379> GET key1 "v1-slave-28" 127.0.0.1:6379> 127.0.0.1:6379> INFO replication # Replication role:master ... #在slave上设置master的IP和端口，4.0版之前的指令为slaveof 127.0.0.1:6379> REPLICAOF 172.31.0.8 6379 #仍可使用SLAVEOF MasterIP Port OK #在slave上设置master的密码，才可以同步 127.0.0.1:6379> CONFIG SET masterauth 123456 OK 127.0.0.1:6379> INFO replication # Replication #角色变为slave role:slave master_host:172.31.0.8 #指向master master_port:6379 master_link_status:up #查看已经同步成功 127.0.0.1:6379> GET key1 "v1-master" #在master上可以看到所有slave信息 127.0.0.1:6379> INFO replication # Replication role:master connected_slaves:2 slave0:ip=172.31.0.18,port=6379,state=online,offset=112,lag=1 #slave信息 slave1:ip=172.31.0.28,port=6379,state=online,offset=112,lag=1
删除主从同步
在从节点执行 REPLIATOF NO ONE 指令可以取消主从复制
#取消复制,在slave上执行REPLIATOF NO ONE,会断开和master的连接不再主从复制, 但不会清除slave 上已有的数据 127.0.0.1:6379> REPLICAOF no one
同步日志
在 master 上观察日志
[root@centos8 ~]# tail /var/log/redis/redis.log 24402:M 06 Oct 2021 09:09:16.448 * Replica 172.31.0.18:6379 asks for synchronization
在 slave 节点观察日志
[root@centos8 ~]# tail -f /var/log/redis/redis.log 24395:S 06 Oct 2021 09:09:16.411 * Connecting to MASTER 172.31.0.8:6379 24395:S 06 Oct 2021 09:09:16.412 * MASTER <-> REPLICA sync started
修改slave节点配置文件
范例: (CentOS8 注意防火墙问题)
[root@centos8 ~]# vim /etc/redis.conf ....... # replicaof <masterip> <masterport> replicaof 172.31.0.8 6379 #指定master的IP和端口号 # If the master is password protected (using the "requirepass" configuration # directive below) it is possible to tell the replica to authenticate before # starting the replication synchronization process, otherwise the master will # refuse the replica request. # masterauth <master-password> masterauth 123456 #如果密码需要设置 ....... [root@centos8 ~]# systemctl restart redis
master和slave查看状态
#在master上查看状态 127.0.0.1:6379> info replication # Replication role:master connected_slaves:1 slave0:ip=172.31.0.18,port=6379,state=online,offset=1104403,lag=0 #在slave上查看状态 127.0.0.1:6379> get key1 #同步成功后,slave上的key信息丢失,从master复制过来新的值 "v1-master" 127.0.0.1:6379> INFO replication # Replication role:slave master_host:172.31.0.8 master_port:6379 master_link_status:up ... #停止master的redis服务：systemctl stop redis,在slave上可以观察到以下现象 127.0.0.1:6379> INFO replication # Replication role:slave master_host:172.31.0.8 master_port:6379 master_link_status:down #显示down，表示无法连接master
slave 观察日志
[root@centos8 ~]# tail -f /var/log/redis/redis.log 24592:S 20 Feb 2021 12:03:58.792 * Connecting to MASTER 172.31.0.8:6379 24592:S 20 Feb 2021 12:03:58.792 * MASTER <-> REPLICA sync started
Master日志
[root@centos8 ~]# tail /var/log/redis/redis.log 11846:M 20 Feb 2021 12:11:35.171 * DB loaded from disk: 0.000 seconds 11846:M 20 Feb 2021 12:11:35.171 * Ready to accept connections
slave 状态只读无法写入数据
127.0.0.1:6379> set key1 v1-slave (error) READONLY You can't write against a read only replica.
主从复制故障恢复
主从复制故障恢复过程介绍
slave 节点故障和恢复
当 slave 节点故障时，将Redis Client指向另一个 slave 节点即可,并及时修复故障从节点
master 节点故障和恢复
需要提升slave为新的master
master故障后，只能手动提升一个slave为新master，不支持自动切换。 之后将其它的slave节点重新指定新的master为master节点 Master的切换会导致master_replid发生变化，slave之前的master_replid就和当前master不一致从而会引发所有 slave的全量同步。
主从复制故障恢复实现
假设当前主节点172.31.0.8故障,提升172.31.0.18为新的master
127.0.0.1:6379> info replication # Replication role:slave master_host:172.31.0.18 master_port:6379 master_link_status:up
停止slave同步并提升为新的master
#将当前 slave 节点提升为 master 角色 127.0.0.1:6379> REPLICAOF NO ONE #旧版使用SLAVEOF no one OK (5.04s) 127.0.0.1:6379> info replication # Replication role:master connected_slaves:0
测试能否写入数据：
127.0.0.1:6379> set keytest1 vtest1 OK
修改所有slave 指向新的master节点
#修改172.31.0.28节点指向新的master节点172.31.0.18 127.0.0.1:6379> SLAVEOF 172.31.0.8 6379 OK 127.0.0.1:6379> set key100 v100 (error) READONLY You can't write against a read only replica. #查看日志 [root@centos8 ~]# tail -f /var/log/redis/redis.log 1762:S 20 Feb 2021 13:28:21.943 # Connection with master lost. 1762:S 20 Feb 2021 13:28:21.943 * Caching the disconnected master state.
在新master可看到slave
#在新master节点172.31.0.18上查看状态 127.0.0.1:6379> INFO replication # Replication role:master connected_slaves:1 slave0:ip=172.31.0.28,port=6379,state=online,offset=4606,lag=0 ...
实现 redis 的级联复制
即实现基于Slave节点的Slave master和slave1节点无需修改,只需要修改slave2及slave3指向slave1做为mater即可
#在slave2和slave3上执行下面指令 127.0.0.1:6379> REPLICAOF 172.31.0.18 6379 OK 127.0.0.1:6379> CONFIG SET masterauth 123456
在 master 设置key,观察是否同步
#在master新建key 127.0.0.1:6379> set key2 v2 OK 127.0.0.1:6379> get key2 "v2" #在slave1和slave2验证key 127.0.0.1:6379> get key2 "v2" #在slave1和slave2都无法新建key 127.0.0.1:6379> set key3 v3 (error) READONLY You can't write against a read only replica.
在中间那个slave查看状态
127.0.0.1:6379> INFO replication # Replication role:slave master_host:172.31.0.8 master_port:6379 master_link_status:up master_last_io_seconds_ago:8 #最近一次与master通信已经过去多少秒。 master_sync_in_progress:0 #是否正在与master通信。 slave_repl_offset:4312 #当前同步的偏移量 slave_priority:100 #slave优先级，master故障后值越小越优先同步。 slave_read_only:1 connected_slaves:1 slave0:ip=172.31.0.28,port=6379,state=online,offset=4312,lag=0 #slave的slave节点
主从复制优化
主从复制过程
Redis主从复制分为全量同步和增量同步
首次主从同步是全量同步，主从同步可以让从服务器从主服务器同步数据，而且从服务器还可再有其它 的从服务器，即另外一台redis服务器可以从一台从服务器进行数据同步，redis 的主从同步是非阻塞 的，master收到从服务器的psync(2.8版本之前是SYNC)命令,会fork一个子进程在后台执行bgsave命 令，并将新写入的数据写入到一个缓冲区中，bgsave执行完成之后,将生成的RDB文件发送给slave，然 后master再将缓冲区的内容以redis协议格式再全部发送给slave，slave 先删除旧数据,slave将收到后的 RDB文件载入自己的内存，再加载所有收到缓冲区的内容 从而这样一次完整的数据同步 Redis全量复制一般发生在Slave首次初始化阶段，这时Slave需要将Master上的所有数据都复制一份。 全量同步之后再次需要同步时,从服务器只要发送当前的offset位置(等同于MySQL的binlog的位置)给主 服务器，然后主服务器根据相应的位置将之后的数据(包括写在缓冲区的积压数据)发送给从服务器,再次 将其保存到从节点内存即可。
主从同步完整过程
具体主从同步过程如下：
1）从服务器连接主服务器，发送PSYNC命令 2）主服务器接收到PSYNC命令后，开始执行BGSAVE命令生成RDB快照文件并使用缓冲区记录此后执行的所有 写命令 3）主服务器BGSAVE执行完后，向所有从服务器发送RDB快照文件，并在发送期间继续记录被执行的写命令 4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照至内存 5）主服务器快照发送完毕后,开始向从服务器发送缓冲区中的写命令 6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令 7）后期同步会先发送自己slave_repl_offset位置，只同步新增加的数据，不再全量同步
复制缓冲区(环形队列)配置参数：
#复制缓冲区大小,建议要设置足够大 repl-backlog-size 1mb #Redis同时也提供了当没有slave需要同步的时候，多久可以释放环形队列： repl-backlog-ttl 3600
避免全量复制
第一次全量复制不可避免,后续的全量复制可以利用小主节点(内存小),业务低峰时进行全量 节点运行ID不匹配:主节点重启会导致RUNID变化,可能会触发全量复制,可以利用故障转移，例如哨 兵或集群,而从节点重启动,不会导致全量复制 复制积压缓冲区不足: 当主节点生成的新数据大于缓冲区大小,从节点恢复和主节点连接后,会导致全量复制.解决方法将repl-backlog-size 调大
避免复制风暴
单主节点复制风暴 当主节点重启，多从节点复制 解决方法:更换复制拓扑 单机器多实例复制风暴 机器宕机后，大量全量复制 解决方法:主节点分散多机器
主从同步优化配置
Redis在2.8版本之前没有提供增量部分复制的功能，当网络闪断或者slave Redis重启之后会导致主从之间的全量同步，即从2.8版本开始增加了部分复制的功能。
性能相关配置
repl-diskless-sync no # 是否使用无盘同步RDB文件，默认为no，no为不使用无盘，需要将RDB文件保 存到磁盘后再发送给slave，yes为支持无盘，支持无盘就是RDB文件不需要保存至本地磁盘，而且直接通过 socket文件发送给slave repl-diskless-sync-delay 5 #diskless时复制的服务器等待的延迟时间 repl-ping-slave-period 10 #slave端向server端发送ping的时间间隔，默认为10秒 repl-timeout 60 #设置主从ping连接超时时间,超过此值无法连接,master_link_status显示为down, 并记录错误日志 repl-disable-tcp-nodelay no #是否启用TCP_NODELAY，如设置成yes，则redis会合并小的TCP包从 而节省带宽， 但会增加同步延迟（40ms），造成master与slave数据不一致，假如设置成no，则redis master会立即发送同步数据，没有延迟，yes关注网络性能，no关注redis服务中的数据一致性 repl-backlog-size 1mb #master的写入数据缓冲区，用于记录自上一次同步后到下一次同步过程中间的 写入命令，计算公式：repl-backlog-size = 允许从节点最大中断时长 * 主实例offset每秒写入量，比 如master每秒最大写入64mb，最大允许60秒，那么就要设置为64mb*60秒=3840MB(3.8G),建议此值是设 置的足够大 repl-backlog-ttl 3600 #如果一段时间后没有slave连接到master，则backlog size的内存将会被释 放。如果值为0则 表示永远不释放这部份内存。 slave-priority 100 #slave端的优先级设置，值是一个整数，数字越小表示优先级越高。当master故障 时将会按照优先级来选择slave端进行恢复，如果值设置为0，则表示该slave永远不会被选择。 min-replicas-to-write 1 #设置一个master的可用slave不能少于多少个，否则master无法执行写 min-slaves-max-lag 20 #设置至少有上面数量的slave延迟时间都大于多少秒时，master不接收写操作(拒绝写入)
常见主从复制故障汇总
master密码不对
即配置的master密码不对，导致验证不通过而无法建立主从同步关系。
[root@centos8 ~]# tail -f /var/log/redis/redis.log 24930:S 20 Feb 2021 13:53:57.029 * Connecting to MASTER 172.31.0.8:6379 24930:S 20 Feb 2021 13:53:57.030 * MASTER <-> REPLICA sync started 24930:S 20 Feb 2021 13:53:57.030 * Non blocking connect for SYNC fired the event. 24930:S 20 Feb 2021 13:53:57.030 * Master replied to PING, replication can continue... 24930:S 20 Feb 2021 13:53:57.031 # Unable to AUTH to MASTER: -ERR invalid password
Redis版本不一致
不同的redis 大版本之间存在兼容性问题，比如：3和4，4和5之间，因此各master和slave之间必须保持版本一致
无法远程连接
在开启了安全模式情况下，没有设置bind地址或者密码
[root@centos8 ~]# vim /etc/redis.conf #bind 127.0.0.1 #将此行注释 [root@centos8 ~]# systemctl restart redis [root@centos8 ~]# ss -ntl #可以本机登录 [root@centos8 ~]# redis-cli 127.0.0.1:6379> KEYS * (empty list or set)
配置不一致
主从节点的maxmemory不一致,主节点内存大于从节点内存,主从复制可能丢失数据 rename-command 命令不一致,如在主节点定义了fushall,flushdb,从节点没定义,结果执行flushdb,不同步
#master有一个rename-command flushdb "king",而slave没有这个配置,则同步时从节点可以看到 以下同步错误 3181:S 21 Oct 2021 17:34:50.581 # == CRITICAL == This replica is sending an error to its master: 'unknown command `king`, with args beginning with: ' after processing the command '<unknown>'