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

2022-09-20 22:06:46

啤酒理论

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 ，回滚是没有办法处理这些情况的。