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

一、事务

1、简介

• 可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化， 按顺序地串行化执行而不会被其他命令插入，不许加塞
• 一个队列中，一次性、顺序性、排他性的执行一系列命令
• 

2、实战

常用命令

正常执行

放弃事务

全体连坐

一个出错，全都不执行

冤头债主

哪个出错哪个不执行，其他执行

watch监控

redis采用乐观锁，因为采用悲观锁会降低redis的性能

unwatch

小结

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

当客户端连接丢失的时候（比如退出连接），所有东西都会被取消监视

开启

以 MULTI 开始一个事务

入队

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

执行

由EXEC命令触发事务

二、管道

1、问题由来

多次命令请求需要频繁的调用系统IO,降低了性能

2、解决思路

类似于set k1 v1, set k2 v2 一步到位成mset k1 v1 k2 v2

4、实操

也就是批处理

• 将多个命令都存在一个txt文件中，然后一同批处理，验证批处理

//代码
cat cmd.txt | redis-cli -a 111111 --pipe

总结

Pipeline 与原生批量

原生批量命令是原子性（如：mset，mget），pipeline是非原子性

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

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

Pipeline 与事务对比

事务具有原子性，管道不具有原子性 （这句话应该是错误的，redis事务不具有原子性）

管道一次性将多条命令发送到服务器，事务是一条一条发的，事务只有在接收到exec命 令后才会执行，管道不会

执行事务时会阻塞其他命令的执行，而执行管道中的命令时不会

Pipeline 注意事项

pipeline缓冲的指令只是会依次执行，不保证原子性，如果执行中指令发生异常，将会继续执行后续的指令

使用pipeline组装的命令个数不能太多，不然数据量过大客户端阻塞的时间可能过久，同时服务器也被迫回复一个队列答复，占用很多内存

三、发布订阅（了解即可）

介绍

• 是一种消息通信模式：

• 发送者（PUBLISH）发送消息
• 订阅者（SUBSCRIBE）接收消息，可以实现进程间的消息传递

Redis可以实现消息中间件MQ的功能，通过发布订阅实现消息的引导和分流

功能

Redis客户端可以订阅任意数量的频道，类似我们微信关注多个公众号

发布/订阅其实是一个轻量的队列，只不过数据不会被持久化，一般用来处理实时性较高的异步消息

基本操作

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

主从配置只需要配置从机

3、实战

4、配置

5、一主二从

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

查看命令

info replication

命令操作手动指定

• 去掉配置文件中配置的从属关系
• replicaof/slaveof no one 升级为主机
• replicaof/slaveof 主库IP 主库端口 称为主库的从机
• 配置VS命令的区别

• 配置，持久稳定
• 命令，当次生效
• 

6、复制原理

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、架构图

3、客观下线

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.conf
  redis-server /myredis/redis6379.conf 
  redis-cli -a 111111
6380.conf
  redis-server /myredis/redis6380.conf 
  redis-cli -a 111111 -p 6380
6381.conf
  redis-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

8、超级兵的选择原则Raft

9、master选举

六、集群

1、介绍

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

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

Redis集群可以支持多个Master

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

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

Redis集群可以支持多个Master

Redis集群支持多个Master，每个Master又可以挂载多个Slave

读写分离

支持海量数据的高可用

支持海量数据的读写存储操作

由于Cluster自带Sentinel的故障转移机制，内置了高可用的支持，无需再去使用哨兵功能

客户端和Redis的节点连接，不再需要连接集群中所有节点，只需连接集群中的任意一个可用节点即可

槽位slot负责分配到各个物理服务节点，由对应的集群来负责维护节点、插槽和数据之间的关系

2、Redis集群分布式存储

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

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

哈希取余分区

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

优点：

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

缺点：

直接规划好节点，进行扩容或者缩容会很麻烦，不管扩还是缩，每次数据变动会导致节点有变动，映射关系都要重新计算，在服务器个数固定不变时没有问题。

如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化，Hash(key)/3会变成Hash(key) /?。此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。

某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。

一致性哈希算法分区

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

三个步骤

算法构建一致性哈希环

一致性哈希算法必然有个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环。

服务器IP节点映射

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

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

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上。

优点

一致性哈希算法的容错性

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

一致性哈希算法的扩展性

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

缺点

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

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

哈希槽分区

• 哈希槽实质就是一个数组，数组[0,2^14 -1]形成hash slot空间。
  
• 解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据。
• 
• 槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。哈希解决的是映射问题，使用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集群可能会丢掉一些被系统收到的写入请求命令

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

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

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

**(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 yjy219912ym
cluster-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 yjy219912ym
cluster-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

1

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

查看集群消息:cluster nodes

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

为主节点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、集群缩容

先获得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

8、小结

集群下不能使用mget