> 文章列表 > Redis 7 事务、管道、发布订阅、主从、哨兵、集群

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

一、事务

1、简介

  • 可以一次执行多个命令,本质是一组命令的集合。一个事务中的所有命令都会序列化, 按顺序地串行化执行而不会被其他命令插入,不许加塞
  • 一个队列中,一次性、顺序性、排他性的执行一系列命令
    Redis 7 事务、管道、发布订阅、主从、哨兵、集群

2、实战

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

常用命令

Redis 7 事务、管道、发布订阅、主从、哨兵、集群
正常执行
Redis 7 事务、管道、发布订阅、主从、哨兵、集群
放弃事务

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

全体连坐
一个出错,全都不执行

Redis 7 事务、管道、发布订阅、主从、哨兵、集群
冤头债主
哪个出错哪个不执行,其他执行
Redis 7 事务、管道、发布订阅、主从、哨兵、集群
watch监控
redis采用乐观锁,因为采用悲观锁会降低redis的性能
Redis 7 事务、管道、发布订阅、主从、哨兵、集群
unwatch
Redis 7 事务、管道、发布订阅、主从、哨兵、集群

小结

  • 一旦执行了 exec 之前加的watch监控锁都会被取消掉

  • 当客户端连接丢失的时候(比如退出连接),所有东西都会被取消监视

  • 开启

    • 以 MULTI 开始一个事务
  • 入队

    • 将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面
  • 执行

    • 由EXEC命令触发事务

二、管道

1、问题由来

多次命令请求需要频繁的调用系统IO,降低了性能
Redis 7 事务、管道、发布订阅、主从、哨兵、集群

2、解决思路

类似于set k1 v1, set k2 v2 一步到位成mset k1 v1 k2 v2
Redis 7 事务、管道、发布订阅、主从、哨兵、集群

4、实操

也就是批处理

  • 将多个命令都存在一个txt文件中,然后一同批处理,验证批处理
//代码
cat cmd.txt | redis-cli -a 111111 --pipe

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

总结

Pipeline 与原生批量

  • 原生批量命令是原子性(如:mset,mget),pipeline是非原子性

  • 原生批量命令一次只能执行一种命令,pipeline支持批量执行不同命令

  • 原生批命令是服务端实现,而pipeline需要服务端与客户端共同完成

Pipeline 与事务对比

  • 事务具有原子性,管道不具有原子性 (这句话应该是错误的,redis事务不具有原子性)
  • 管道一次性将多条命令发送到服务器,事务是一条一条发的,事务只有在接收到exec命 令后才会执行,管道不会
  • 执行事务时会阻塞其他命令的执行,而执行管道中的命令时不会

Pipeline 注意事项

  • pipeline缓冲的指令只是会依次执行,不保证原子性,如果执行中指令发生异常,将会继续执行后续的指令
  • 使用pipeline组装的命令个数不能太多,不然数据量过大客户端阻塞的时间可能过久,同时服务器也被迫回复一个队列答复,占用很多内存

三、发布订阅(了解即可)

介绍

  • 是一种消息通信模式:
    • 发送者(PUBLISH)发送消息
    • 订阅者(SUBSCRIBE)接收消息,可以实现进程间的消息传递
  • Redis可以实现消息中间件MQ的功能,通过发布订阅实现消息的引导和分流
  • 功能
    • Redis客户端可以订阅任意数量的频道,类似我们微信关注多个公众号
    • 发布/订阅其实是一个轻量的队列,只不过数据不会被持久化,一般用来处理实时性较高的异步消息
      Redis 7 事务、管道、发布订阅、主从、哨兵、集群
      Redis 7 事务、管道、发布订阅、主从、哨兵、集群
      基本操作
SUBSCRIBE channel [channel]   // 订阅多个频道
PUBLISH channel message       // 对一个频道发布信息
PSUBSCRIBE pattern [pattern...]  // 按照模式批量订阅,订阅一个或多个符合给定模式(支持*号?号之类的)的频道
PUSUB CHANNELS      // 由活跃频道组成的列表
PUSUB NUMSUB channel [channel...]   // 某个频道有几个订阅者
PUBSUB NUMPAT   // 只统计使用PUBSCRIBE 命令执行的,返回客户端订阅的唯一模式的数量
UNSUBSCRIBE channel [channel...]    // 取消订阅
PUNSUBSCRIBE pattern [pattern...]   // 退订所有给定模式的频道

四、主从复制

1、介绍

  • 主从复制

  • mmaster以写为主,slave以读为主

    • 当master数据变化时,自动将新的数据异步同步到其他slave数据库
    • 读写分离
  • down机恢复

  • 数据备份

  • 水平扩容支撑高并发

2、配置

主从配置只需要配置从机
Redis 7 事务、管道、发布订阅、主从、哨兵、集群

3、实战

Redis 7 事务、管道、发布订阅、主从、哨兵、集群
Redis 7 事务、管道、发布订阅、主从、哨兵、集群

4、配置

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

5、一主二从

  • master有读写能力,slave只有读能力
  • slave是从头开始复制,不是从切入点开始切入
  • 主机宕机后,从机原地待命,不会变成master
  • 主机恢复正常后,主从关系恢复到正常状态

查看命令

info replication

Redis 7 事务、管道、发布订阅、主从、哨兵、集群 - 命令操作手动指定

  • 去掉配置文件中配置的从属关系
  • replicaof/slaveof no one 升级为主机
  • replicaof/slaveof 主库IP 主库端口 称为主库的从机
  • 配置VS命令的区别
    • 配置,持久稳定
    • 命令,当次生效
      Redis 7 事务、管道、发布订阅、主从、哨兵、集群

6、复制原理

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

7、痛点

1、复制延时,信号衰减

由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。

2、master挂了

  • 默认情况下不会在slave节点自动重选一个master
  • 需要人工干预

五、哨兵

1、介绍

  • 哨兵巡查监控后台master主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,继续对外服务,俗称无人值守运维

  • 作用

    • 监控redis运行状态,包括master和slave
    • 当master down机,能自动将slave切换成新master
  • 哨兵的四个功能

    • 主从监控
      • 监控主从redis库运行是否正常
    • 消息通知
      • 哨兵可以将故障转移的结果发送到客户端
    • 故障转移
      • 如果master异常,则会进行主从切换,将其中一个slave作为新master
    • 配置中心
      • 客户端通过连接哨兵来获得当前Redis服务的主节点地址

2、架构图

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

3、客观下线

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

4、配置

参数

bind 服务监听地址,用于客户端连接
daemonize 是否以后台daemon方式运行
protected-mode 安全保护模式
port 端口
logfile 日志文件路径
pidfile pid日志路径
dir 工作目录
sentiel monitor
设置要监控的master
quorm 表示最少有几个哨兵认可客观下线,同意故障迁移的法定票数
网络是不可靠的,有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了,在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了,quorum这个参数是进行客观下线的一个依据,意思是至少有quorum个sentinel认为这个master有故障,才会对这个master进行下线以及故障转移。因为有的时候,某个sentinel节点可能因为自身网络原因,导致无法连接master,而此时master并没有出现故障,所以,这就需要多个sentinel都一致认为该master有问题,才可以进行下一步操作,这就保证了公平性和高可用。
sentiel auth-pass 通过密码连接master

哨兵配置

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111
bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111
bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

5、启动一主二从

1、先给原先的主机master配上访问密码

masterauth "111111"

因为master后面可能会变成从机
2、启动一主二从

6379.confredis-server /myredis/redis6379.conf redis-cli -a 1111116380.confredis-server /myredis/redis6380.conf redis-cli -a 111111 -p 63806381.confredis-server /myredis/redis6381.conf redis-cli -a 111111 -p 6381

6、启动哨兵

redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel

7、结论

sentinel 可以动态修改配置文件的slaveof
Redis 7 事务、管道、发布订阅、主从、哨兵、集群

8、超级兵的选择原则Raft

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

9、master选举

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

六、集群

1、介绍

  • 由于数据量过大,单个Master复制集难以承担,因此需要对多个复制集进行集群,形成水平扩展每个复制集只负责存储整个数据集的一部分,这就是Redis的集群,其作用是提供在多个Redis节点间共享数据的程序集。

  • Redis集群是一个提供在多个Redis节点间共享数据的程序集

    • Redis集群可以支持多个Master

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

  • Redis集群支持多个Master,每个Master又可以挂载多个Slave
    • 读写分离
    • 支持海量数据的高可用
    • 支持海量数据的读写存储操作
  • 由于Cluster自带Sentinel的故障转移机制,内置了高可用的支持,无需再去使用哨兵功能
  • 客户端和Redis的节点连接,不再需要连接集群中所有节点,只需连接集群中的任意一个可用节点即可
  • 槽位slot负责分配到各个物理服务节点,由对应的集群来负责维护节点、插槽和数据之间的关系

2、Redis集群分布式存储

Redis集群分布式存储有大概有3种解决方法

  • 哈希取余分区
  • 一致性哈希算法分区
  • 哈希槽分区

哈希取余分区

hash(key) % N个机器台数,计算出哈希值,用来决定数据映射到哪一个节点上。

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

优点

  • 简单粗暴,直接有效,只需要预估好数据规划节点例如3台、8台、10台,就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上,这样每台服务器固定处理一部分请求(并维护这些请求的信息),起到负载均衡+分而治之的作用。

缺点

  • 直接规划好节点,进行扩容或者缩容会很麻烦,不管扩还是缩,每次数据变动会导致节点有变动,映射关系都要重新计算,在服务器个数固定不变时没有问题。
  • 如果需要弹性扩容或故障停机的情况下,原来的取模公式就会发生变化,Hash(key)/3会变成Hash(key) /?。此时地址经过取余运算的结果将发生很大变化,根据公式获取的服务器也会变得不可控。
  • 某个redis机器宕机了,由于台数数量变化,会导致hash取余全部数据重新洗牌。

一致性哈希算法分区

提出一致性Hash解决方案。目的是当服务器个数发生变动时,尽量减少影响客户端到服务器的映射关系

三个步骤
  1. 算法构建一致性哈希环

    • 一致性哈希算法必然有个hash函数并按照算法产生hash值,这个算法的所有可能哈希值会构成一个全量集,这个集合可以成为一个hash空间[0,2^32-1],这个是一个线性空间,但是在算法中,我们通过适当的逻辑控制将它首尾相连(0 = 2^32),这样让它逻辑上形成了一个环形空间。
    • 它也是按照使用取模的方法,前面笔记介绍的节点取模法是对节点(服务器)的数量进行取模。而一致性Hash算法是对232取模,简单来说,一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环,如假设某哈希函数H的值空间为0-232-1(即哈希值是一个32位无符号整形),整个哈希环如下图:整个空间按顺时针方向组织,圆环的正上方的点代表0,0点右侧的第一个点代表1,以此类推,2、3、4、……直到232-1,也就是说0点左侧的第一个点代表232-1, 0和232-1在零点中方向重合,我们把这个由232个点组成的圆环称为Hash环。

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

  1. 服务器IP节点映射

    • 将集群中各个IP节点映射到环上的某一个位置。

    • 将各个服务器使用Hash进行一个哈希,具体可以选择服务器的IP或主机名作为关键字进行哈希,这样每台机器就能确定其在哈希环上的位置。假如4个节点NodeA、B、C、D,经过IP地址的哈希函数计算(hash(ip)),使用IP地址哈希后在环空间的位置如下:

      Redis 7 事务、管道、发布订阅、主从、哨兵、集群

  2. key 落到服务器的落键规则

    • 当我们需要存储一个kv键值对时,首先计算key的hash值,hash(key),将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置,从此位置沿环顺时针“行走”,第一台遇到的服务器就是其应该定位到的服务器,并将该键值对存储在该节点上。

    • 如我们有Object A、Object B、Object C、Object D四个数据对象,经过哈希计算后,在环空间上的位置如下:根据一致性Hash算法,数据A会被定为到Node A上,B被定为到Node B上,C被定为到Node C上,D被定为到Node D上。

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

优点
  • 一致性哈希算法的容错性

    • 假设Node C宕机,可以看到此时对象A、B、D不会受到影响,只有C对象被重定位到Node D。一般的,在一致性Hash算法中,如果一台服务器不可用,则受影响的数据仅仅是此服务器到其环空间中前一台服务器(即沿着逆时针方向行走遇到的第一台服务器)之间数据,其它不会受到影响。简单说,就是C挂了,受到影响的只是B、C之间的数据,并且这些数据会转移到D进行存储。

      Redis 7 事务、管道、发布订阅、主从、哨兵、集群

  • 一致性哈希算法的扩展性

    • 数据量增加了,需要增加一台节点NodeX,X的位置在A和B之间,那收到影响的也就是A到X之间的数据,重新把A到X的数据录入到X上即可,
      不会导致hash取余全部数据重新洗牌。

      Redis 7 事务、管道、发布订阅、主从、哨兵、集群

缺点
  • 一致性哈希算法的数据倾斜问题

    • Hash环的数据倾斜问题
      一致性Hash算法在服务节点太少时,容易因为节点分布不均匀而造成数据倾斜(被缓存的对象大部分集中缓存在某一台服务器上)问题,
      例如系统中只有两台服务器:

      Redis 7 事务、管道、发布订阅、主从、哨兵、集群

哈希槽分区

  • 哈希槽实质就是一个数组,数组[0,2^14 -1]形成hash slot空间。

  • 解决均匀分配的问题,在数据和节点之间又加入了一层,把这层称为哈希槽(slot),用于管理数据和节点之间的关系,现在就相当于节点上放的是槽,槽里放的是数据。 Redis 7 事务、管道、发布订阅、主从、哨兵、集群

  • 槽解决的是粒度问题,相当于把粒度变大了,这样便于数据移动。哈希解决的是映射问题,使用key的哈希值来计算所在的槽,便于数据分配

  • 一个集群只能有16384个槽,编号0-16383(0-2^14-1)。这些槽会分配给集群中的所有主节点,分配策略没有要求。

  • 集群会记录节点和槽的对应关系,解决了节点和槽的关系后,接下来就需要对key求哈希值,然后对16384取模,余数是几key就落入对应的槽里。HASH_SLOT = CRC16(key) mod 16384。以槽为单位移动数据,因为槽的数目是固定的,处理起来比较容易,这样数据移动问题就解决了。

  • 当需要在 Redis 集群中放置一个 key-value时,redis先对key使用crc16算法算出一个结果然后用结果对16384求余数[ CRC16(key) % 16384],这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,也就是映射到某个节点上。如下代码,key之A 、B在Node2, key之C落在Node3上

分片是什么 使用Redis集群时我们会将存储的数据分散到多台redis机器上,这称为分片。简言之,集群中的每个Redis实例都被认为是整个数据的一个分片。
如何找到给定key的分片 为了找到给定key的分片,我们对key进行CRC16(key)算法处理并通过对总分片数量取模。然后,使用确定性哈希函数,这意味着给定的key将多次始终映射到同一个分片,我们可以推断将来读取特定key的位置。

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

优势:

Redis 7 事务、管道、发布订阅、主从、哨兵、集群

缺点

Redis集群不保证 强一致性,这意味着在特定的条件下,Redis集群可能会丢掉一些被系统收到的写入请求命令

10.3 为什么redis集群的最大槽数是16384

  • Redis集群并没有使用一致性hash而是引入了哈希槽的概念。Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽,集群的每个节点负责一部分hash槽。

    • 正常的心跳数据包带有节点的完整配置,可以用幂等方式用旧的节点替换旧节点,以便更新旧的配置。这意味着它们包含原始节点的插槽配置,该节点使用2k的空间和16k的插槽,但是会使用8k的空间(使用65k的插槽)。同时,由于其他设计折衷,Redis集群不太可能扩展到1000个以上的主节点。因此16k处于正确的范围内,以确保每个主机具有足够的插槽,最多可容纳1000个矩阵,但数量足够少,可以轻松地将插槽配置作为原始位图传播。请注意,在小型群集中,位图将难以压缩,因为当N较小时,位图将设置的slot / N位占设置位的很大百分比。

    Redis 7 事务、管道、发布订阅、主从、哨兵、集群

(1)如果槽位为65536,发送心跳信息的消息头达8k,发送的心跳包过于庞大。在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为65536时,这块的大小是: 65536÷8÷1024=8kb

在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为16384时,这块的大小是: 16384÷8÷1024=2kb

因为每秒钟,redis节点需要发送一定数量的ping消息作为心跳包,如果槽位为65536,这个ping消息的消息头太大了,浪费带宽。

(2)redis的集群主节点数量基本不可能超过1000个。

集群节点越多,心跳包的消息体内携带的数据越多。如果节点过1000个,也会导致网络拥堵。因此redis作者不建议redis cluster节点数量超过1000个。 那么,对于节点数在1000以内的redis cluster集群,16384个槽位够用了。没有必要拓展到65536个。

(3)槽位越小,节点少的情况下,压缩比高,容易传输

Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的,在传输过程中会对bitmap进行压缩,但是如果bitmap的填充率slots / N很高的话(N表示节点数),bitmap的压缩率就很低。 如果节点数很少,而哈希槽数量很多的话,bitmap的压缩率就很低。

3、redis不保证强一致性

redis在写的过程中如果主机宕机肯能会造成数据丢失

4、搭建3主3从redis

6381

bind 0.0.0.0
daemonize yes
protected-mode no
port 6381
logfile "/myredis/cluster/cluster6381.log"
pidfile /myredis/cluster6381.pid
dir /myredis/cluster
dbfilename dump6381.rdb
appendonly yes
appendfilename "appendonly6381.aof"
requirepass yjy219912ym
masterauth yjy219912ymcluster-enabled yes
cluster-config-file nodes-6381.conf
cluster-node-timeout 5000

6382

bind 0.0.0.0
daemonize yes
protected-mode no
port 6382
logfile "/myredis/cluster/cluster6382.log"
pidfile /myredis/cluster6382.pid
dir /myredis/cluster
dbfilename dump6382.rdb
appendonly yes
appendfilename "appendonly6382.aof"
requirepass yjy219912ym
masterauth yjy219912ymcluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000

通过redis-cli命令为6台机器构建集群关系

构建主从关系 注意用自己的IP

redis-cli -a yjy219912ym --cluster create --cluster-replicas 1 192.168.159.130:6381 192.168.159.130:6382 192.168.159.131:6383 192.168.159.131:6384 192.168.159.132:6385 192.168.159.132:6386

–cluster-replicas 1 表示为每个master创建一个slave节点

查看集群消息:cluster nodes
Redis 7 事务、管道、发布订阅、主从、哨兵、集群

5、集群读写

代码:redis-cli -a yjy219912ym -p 6381 -c
这里的-c是集群下独特的读写,这将开启路由映射,映射到对应的槽位。

手动调整主从关系
代码cluster failover
原来的集群master宕机了,slave升级为master,当原来的master重新恢复正常后,身份变成了slave,如果此时想要恢复成以前的主从关系,就要手动执行cluster failover

6、集群扩容

将新增的6387加入到原有的集群

redis-cli -a 123456  --cluster add-node 192.168.111.187:6387 192.168.111.185:6381

注意,此时6387虽然已经加入了集群,但是还没有分配曹号
分配曹号代码:rehash

redis-cli -a 123456 --cluster reshard 192.168.111.185:6381

Redis 7 事务、管道、发布订阅、主从、哨兵、集群
为主节点6387分配从节点6388 –cluster-master-id 后跟的是6387的id

redis-cli -a 123456 
--cluster add-node 192.168.238.114:6388 192.168.238.114:6387 
--cluster-slave 
--cluster-master-id b861764cbba16a1b21536a3182349748e56f24cc

7、集群缩容

Redis 7 事务、管道、发布订阅、主从、哨兵、集群
先获得6388的节点id,在集群中将6388删除

redis-cli -a 123456 --cluster del-node 192.168.238.114:6388 
411144d66f28e876de5a6433689c8cbfab10686f

检查节点,只剩7台

将6387的槽号情况,重新分配,先全部都给6381

redis-cli -a 123456 --cluster reshard 192.168.238.111:6381

Redis 7 事务、管道、发布订阅、主从、哨兵、集群
删除6387
Redis 7 事务、管道、发布订阅、主从、哨兵、集群

8、小结

集群下不能使用mget

Redis 7 事务、管道、发布订阅、主从、哨兵、集群