07 Redis消息订阅、pipeline、事务、modules、布隆过滤器、缓存LRU

最新推荐文章于 2024-11-08 14:34:47 发布

Garen Gosling

最新推荐文章于 2024-11-08 14:34:47 发布

阅读量150

点赞数

分类专栏： 02 从网络到分布式文章标签： linux 缓存 redis

本文链接：https://blog.csdn.net/jianmo777/article/details/118857465

版权

02 从网络到分布式专栏收录该内容

14 篇文章 1 订阅

订阅专栏

Redis 管道（Pipelining）

管道（Pipelining）：学习如何一次发送多个命令，节省往返时间。
大量插入数据：如何在短时间里向Redis写入大量数据。
从文件中批量插入数据：将文件中的指令批量执行。

请求/响应协议和RTT
Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。
数据包从客户端到达服务器，并从服务器返回数据回复客户端，这个时间被称之为 RTT (Round Trip Time - 往返时间)。
管道（pipelining），一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应。这样就可以将多个命令发送到服务器，而不用等待回复，最后在一个步骤中读取该答复。
优点：很多命令依次执行，会产生很多次RTT开销，而使用管道，一次RTT开销就可以执行很多命令。简而言之，管道可以减少RTT开销。
缺点：使用管道发送命令时，服务器将被迫回复一个队列答复，占用很多内存。
怎样解决：如果你需要发送大量的命令，最好是把他们按照合理数量分批次的处理，例如10K的命令，读回复，然后再发送另一个10k的命令，等等。这样速度几乎是相同的，但是在回复这10k命令队列需要非常大量的内存用来组织返回数据内容。
管道（Pipelining） VS 脚本（Scripting）
大量管道的应用场景都可以通过redis脚本来处理。redis脚本更高效。如果客户端在写命令前需要读命令返回的结果，则不能用管道，而要用脚本。

演示

安装nc
使用nc，模拟redis客户端
echo输出到控制台
nc通过管道把命令在reids中执行，执行结果，用echo输出到控制台

Redis 发布/订阅（Pub/Sub）

Redis 发布/订阅（Pub/Sub）：redis是一个快速、稳定的发布/订阅的信息系统。

在这里插入图片描述

发布/订阅
客户端1，往通道ooxx中发布消息hello

客户端2，订阅ooxx通道的消息，因为是客户端1发布消息之后，客户端2才订阅的，所以是看不到之前客户端1发布的消息的

客户端1在次发布消息

客户端2看到了消息

Redis 事务

Redis 事务：将一组命令放在同一个事务中进行处理。
在这里插入图片描述
事务可以一次执行多个命令，并且带有以下两个重要的保证：

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

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

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

WATCH 使得 EXEC 命令需要有条件地执行：

事务只能在所有被监视键都没有被修改的前提下执行，如果这个前提不能满足的话，事务就不会被执行。
当 EXEC 被调用时，不管事务是否成功执行，对所有键的监视都会被取消。
当客户端断开连接时，该客户端对键的监视也会被取消。

Redis事务不支持回滚

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

事务的执行顺序

当多个客户端执行事务，那个客户端先执行EXEC命令，哪个事务先执行。与哪个客户端先开启事务无关。
在这里插入图片描述
如果，客户端1先开启事务，客户端2后开启事务，但是客户端2先执行EXEC命令，客户端1后执行EXEC命令，则客户端2的事务先执行。
客户端1开启事务，执行一系列操作

客户端2开启事务，执行一系列操作

客户端2提交事务
在这里插入图片描述
客户端1提交事务

watch监听的key如果值被修改则事务执行失败

客户端1用watch监听k1
在这里插入图片描述
客户端2重新设置k1的值

客户端1提交事务，事务执行失败

布隆过滤器

什么是布隆过滤器
布隆过滤器（Bloom Filter）是由Howard Bloom在1970年提出的一种比较巧妙的概率型数据结构，它可以告诉你某种东西一定不存在或者可能存在。当布隆过滤器说，某种东西存在时，这种东西可能不存在；当布隆过滤器说，某种东西不存在时，那么这种东西一定不存在。
布隆过滤器相对于Set、Map 等数据结构来说，它可以更高效地插入和查询，并且占用空间更少，它也有缺点，就是判断某种东西是否存在时，可能会被误判。但是只要参数设置的合理，它的精确度也可以控制的相对精确，只会有小小的误判概率。
Redis中布隆过滤器
之前的布隆过滤器可以使用Redis中的位图操作实现，直到Redis4.0版本提供了插件功能，Redis官方提供的布隆过滤器才正式登场。布隆过滤器作为一个插件加载到Redis Server中，就会给Redis提供了强大的布隆去重功能。
布隆过滤器的基本使用
bf.add：添加元素到布隆过滤器中，类似于集合的sadd命令，不过bf.add命令只能一次添加一个元素，如果想一次添加多个元素，可以使用bf.madd命令。
bf.exists：判断某个元素是否在过滤器中，类似于集合的sismember命令，不过bf.exists命令只能一次查询一个元素，如果想一次查询多个元素，可以使用bf.mexists命令。
布隆过滤器可以解决的问题
缓存击穿，布隆过滤器是用bitmap方式存储，占用内存非常小。大量数据，如果缓存中查不到，那么是否去数据库中查呢？可以先用布隆过滤器查一下是否存在，如果不存在就不允许穿透缓存查询数据库。