Redis的高级使用(1)-(管道|发布订阅|事务)

最新推荐文章于 2024-05-20 22:10:47 发布

夜來风羽声

最新推荐文章于 2024-05-20 22:10:47 发布

阅读量926

点赞数

分类专栏： Redis 文章标签： redis 网络服务器

本文链接：https://blog.csdn.net/qq_43583755/article/details/121713432

版权

Redis 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

一、管道

1.前置知识

Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。

这意味着通常情况下一个请求会遵循以下步骤：

客户端向服务端发送一个查询请求，并监听Socket返回，通常是以阻塞模式，等待服务端响应。
服务端处理命令，并将结果返回给客户端。
因此，例如下面是4个命令序列执行情况：
- Client: INCR X
- Server: 1
- Client: INCR X
- Server: 2
- Client: INCR X
- Server: 3
- Client: INCR X
- Server: 4

客户端和服务器通过网络进行连接。这个连接可以很快（loopback接口）或很慢（建立了一个多次跳转的网络连接）。无论网络延如何延时，数据包总是能从客户端到达服务器，并从服务器返回数据回复客户端。

这个时间被称之为 RTT (Round Trip Time - 往返时间).

2.概念

一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应。这样就可以将多个命令发送到服务器，而不用等待回复，最后在一个步骤中读取该答复 ,这就是管道（pipelining）

Redis很早就支持管道（pipelining）技术，因此无论你运行的是什么版本，你都可以使用管道（pipelining）操作Redis。下面是一个使用的例子：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UFCOvgBd-1638589700965)(管道和发布订阅事务.assets/1638583539885.png)]

这一次我们没有为每个命令都花费了RTT开销，而是只用了一个命令的开销时间。

非常明确的，用管道顺序操作的第一个例子如下：

Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4

注意:

使用管道发送命令时，服务器将被迫回复一个队列答复，占用很多内存。所以，如果你需要发送大量的命令，最好是把他们按照合理数量分批次的处理，例如10K的命令，读回复，然后再发送另一个10k的命令，等等。这样速度几乎是相同的，但是在回复这10k命令队列需要非常大量的内存用来组织返回数据内容。

3.Pipelining VS Scripting

大量 pipeline 应用场景可通过 Redis 脚本（Redis 版本 >= 2.6）得到更高效的处理，后者在服务器端执行大量工作。脚本的一大优势是可通过最小的延迟读写数据，让读、计算、写等操作变得非常快（pipeline 在这种情况下不能使用，因为客户端在写命令前需要读命令返回的结果）。

理解:

如果是组织大量的、无依赖关系的命令，可以选择管道，当然也可以选择脚本。如果命令之间有依赖关系，比如后续的命令需要处理先前命令的返回值，只能选择脚本。

4.扩展

**问题:如果能将要执行的指令一行行存储到文件中，然后用一行命令将文件中的命令一次执行完成?**

参考资料: http://redis.cn/topics/batch-insert.html

二、发布订阅

1.概念及简单使用

订阅者对一个或多个频道感兴趣，只需接收感兴趣的消息，不需要知道什么样的发布者发布的。这种发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑。

1.发布
	publish k1 hahaha
	
2.订阅
	subscribe|unsubscribe k1
	该命令发生后会阻塞在这监听消息
注意:
	只有先监听后,才会接收到之后发布的消息

在这里插入图片描述

2.模拟场景

如果我们要看历史聊天记录和实时聊天记录,应该怎么设计?

客户端3天前的历史性数据放到redis的缓存中(sorted_set),更老的数据则放到数据库中
实时的数据我们通过redis的发布订阅然后再放到redis缓存中解决,而另一边通过kafka持久化到数据库

在这里插入图片描述

上述的图可能描述的有点模糊,所以这里补充了一张

如下图步骤为:

客户端通过redis发布消息
另一个客户端通过redis订阅消息从而获取到消息
另外一个redis客户端通过订阅消息,通过sorted_set将消息缓存到redis中(zset)
微服务订阅消息,通过中间件kafka消费数据,最终持久化到mysql

注意:上述的2,3,4是同时发生的

在这里插入图片描述

三、事务

1.概念

特性

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令。事务可以一次执行多个命令，并且带有以下两个重要的保证：
- 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
- 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
补充:

2.2之后,Redis 还可以通过乐观锁（optimistic lock）实现 CAS （check-and-set）操作 ,其中watch就是乐观锁

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RviLwyPf-1638589700972)(管道和发布订阅事务.assets/1638586002984.png)]

EXEC 命令负责触发并执行事务中的所有命令：

如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。
另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。

2.用法

MULTI 命令用于开启一个事务，它总是返回 OK 。 MULTI 执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当 EXEC命令被调用时，所有队列中的命令才会被执行。如下图所示:
在这里插入图片描述

另一方面，通过调用 DISCARD ，客户端可以清空事务队列，并放弃执行事务。
在这里插入图片描述
EXEC 命令的回复是一个数组，数组中的每个元素都是执行事务中的命令所产生的回复。其中，回复元素的先后顺序和命令发送的先后顺序一致。

当客户端处于事务状态时，所有传入的命令都会返回一个内容为 QUEUED 的状态回复（status reply），这些被入队的命令将在 EXEC 命令被调用时执行。

3.事务中的错误

使用事务时可能会遇上以下两种错误：

事务在执行 EXEC 之前，入队的命令可能会出错。比如说，命令可能会产生语法错误（参数数量错误，参数名错误，等等），或者其他更严重的错误，比如内存不足（如果服务器使用 maxmemory 设置了最大内存限制的话）。
命令可能在 EXEC 调用之后失败。举个例子，事务中的命令可能处理了错误类型的键，比如将列表命令用在了字符串键上面，诸如此类。

对于发生在 EXEC 执行之前的错误，客户端以前的做法是检查命令入队所得的返回值：如果命令入队时返回 QUEUED ，那么入队成功；否则，就是入队失败。如果有命令在入队时失败，那么大部分客户端都会停止并取消这个事务。

不过，从 Redis 2.6.5 开始，**服务器会对命令入队失败的情况进行记录，并在客户端调用 EXEC 命令时，拒绝执行并自动放弃这个事务。

总结:

以前检查入队所得返回值,为queue则成功,否则失败,若失败了一般会停止并取消该事务

2.65之后,会对命令入队失败进行记录,在调用EXEC命令时,拒绝执行并放弃该事务

注意:

即使事务中有某条/某些命令执行失败了，事务队列中的其他命令仍然会继续执行 —— Redis 不会停止执行事务中的命令

4.为什么Redsi不支持回滚

如果你有使用关系式数据库的经验，那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。

以下是这种做法的优点：

Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

有种观点认为 Redis 处理事务的做法会产生 bug ，然而需要注意的是，在通常情况下，回滚并不能解决编程错误带来的问题。举个例子，如果你本来想通过 INCR 命令将键的值加上 1 ，却不小心加上了 2 ，又或者对错误类型的键执行了 INCR ，回滚是没有办法处理这些情况的。