【发布时间】:2019-12-31 06:42:36
【问题描述】:
各有什么优缺点? 请建议何时使用其中一个而不是另一个。
【问题讨论】:
标签: database caching redis publish-subscribe
各有什么优缺点? 请建议何时使用其中一个而不是另一个。
【问题讨论】:
标签: database caching redis publish-subscribe
Pub/Sub 是一个发布者/订阅者平台,它不是数据存储。无论是否有订阅者,已发布的消息都会消失。
在 Redis Streams 中,流是一种数据类型,它本身就是一种数据结构。消息或条目存储在内存中并一直保留在那里,直到被命令删除。
Pub/Sub 是同步通信(push 协议)。各方需要同时处于活动状态才能进行通信。这里的 Redis 是一个纯同步消息代理。
Redis Streams 允许同步(XREAD 和 BLOCK 和特殊的 $ ID 是 push 协议)和异步通信(常规 XREAD 是 pull 协议)。 XREAD 和 BLOCK 类似于 Pub/Sub,但能够在断开连接时恢复而不会丢失消息。
Pub/Sub 最多一次,即“一劳永逸”。
Redis Streams 允许最多一次或至少一次(接收方发送的显式确认)
Pub/Sub 仅是阻塞模式。订阅频道后,客户端进入订阅者模式,无法发出命令([P]SUBSCRIBE、[P]UNSUBSCRIBE、PING 和 QUIT 除外),它已变为只读状态。
Redis Streams 允许消费者在阻塞模式下读取消息。
Pub/Sub 只是扇出。所有活动的客户端都会收到所有消息。
Redis Streams 允许扇出(使用XREAD),但也可以将来自同一流的不同消息子集提供给许多客户端。这允许扩展消息处理,通过将不同的消息路由到不同的工作人员,以一种不可能将相同的消息传递给多个消费者的方式。最后一个场景是通过消费者群体实现的。
Redis Streams 提供了更多功能,例如时间戳、字段值对、范围等。这并不意味着您应该始终使用 Streams。如果您的用例可以通过 Pub/Sub 实现,那么您最好使用 Pub/Sub。使用 Streams,您必须注意内存使用情况。
【讨论】: