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