Redis实战（四）：redis的消息订阅、pipeline、事务、modules、布隆过滤器、缓存LRU

最新推荐文章于 2024-11-09 13:22:03 发布

了不起的小师傅

最新推荐文章于 2024-11-09 13:22:03 发布

阅读量132

点赞数

分类专栏： Redis实战文章标签： redis

原文链接：https://hanquan.blog.csdn.net/article/details/106959726

版权

8 篇文章 0 订阅

订阅专栏

Buffer机制，减少没必要的来回调用

只要和redis建立了连接，发送字符串，就能交互
在这里插入图片描述

在这里插入图片描述

help @pubsub

在这里插入图片描述

在这里插入图片描述

  PSUBSCRIBE pattern [pattern ...]
  summary: Listen for messages published to channels matching the given patterns
  since: 2.0.0

PUBLISH channel message
summary: Post a message to a channel
since: 2.0.0

PUBSUB subcommand [argument [argument ...]]
summary: Inspect the state of the Pub/Sub subsystem
since: 2.8.0

PUNSUBSCRIBE [pattern [pattern ...]]
summary: Stop listening for messages posted to channels matching the given patterns
since: 2.0.0

SUBSCRIBE channel [channel ...]
summary: Listen for messages published to the given channels
since: 2.0.0

UNSUBSCRIBE [channel [channel ...]]
summary: Stop listening for messages posted to the given channels
since: 2.0.0

在这里插入图片描述可以启动不同的redis去接收订阅的消息，有的用来推送给用户，有的用来发给kafka，继而存储到数据库中

假设是client1绿色先开启的事务multi，client2黄色后开启的事务，
并且假设client2黄色的exec先到达，client1绿色的exec后到达：
在这里插入图片描述是先发送exec的客户端先执行命令

在这里插入图片描述

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

以下是这种做法的优点：

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

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