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

啤酒理论

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

前置知识

只要和redis建立了连接，发送字符串，就能交互

管道

发布 / 订阅

help @pubsub

发送者

订阅者

  PSUBSCRIBE pattern [pattern ...]summary: Listen for messages published to channels matching the given patternssince: 2.0.0PUBLISH channel messagesummary: Post a message to a channelsince: 2.0.0PUBSUB subcommand [argument [argument ...]]summary: Inspect the state of the Pub/Sub subsystemsince: 2.8.0PUNSUBSCRIBE [pattern [pattern ...]]summary: Stop listening for messages posted to channels matching the given patternssince: 2.0.0SUBSCRIBE channel [channel ...]summary: Listen for messages published to the given channelssince: 2.0.0UNSUBSCRIBE [channel [channel ...]]summary: Stop listening for messages posted to the given channelssince: 2.0.0

聊天室架构模型

每个人能够收到实时消息
上滑加载最近3天消息
再上滑加载历史消息，所有消息都应该被存在数据库中

可以启动不同的redis去接收订阅的消息，有的用来推送给用户，有的用来发给kafka，继而存储到数据库中

Redis事务

假设是client1绿色先开启的事务multi，client2黄色后开启的事务，
并且假设client2黄色的exec先到达，client1绿色的exec后到达：
是先发送exec的客户端先执行命令

在事务中 watch 监控某个 key，如果发生改变，就不执行事务

为什么 Redis 不支持回滚（roll back）

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

以下是这种做法的优点：

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

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

RedisBloom模块 - 布隆过滤器

解决缓存穿透问题

布隆过滤器：用小空间解决大量数据匹配的问题
三种架构情况：

更新完数据库，需要同步刷缓存 -> 双写问题

缓存淘汰策略

下节课预习

缓存常见问题：

击穿
雪崩
穿透
一致性