首先说一下队列设计。

假设有一本很长的书，并且有许多人阅读。有些人可以在午餐时间阅读，有些人在周一晚上阅读，其他人则在周末带回家。这本书很长，在任何时候，我们都有数百人阅读它。

书的读者需要跟踪他们在书中的位置，因此他们通过在书中放置书签来跟踪他们的位置。有些读者阅读速度很慢，书签就在开头。而有些读者半途而废，将自己的书签留在书中，再也不会回来。

更糟糕的是，我们每天都在给这本书加页。没有人能真正读完这本书。

最终，书被书签塞满了，直到有一天，它太重了，搬不动，没人能再读了。

于是有一个非常聪明的人决定不允许读者在书中放置书签，而必须在日记中写下他们要翻到的页数。

这就是 Apache Kafka 的设计，而且是一个非常有弹性的设计。

其他队列的常见替代设计是让队列服务跟踪读者所在的位置——这意味着需要为每个读者分配内存。行为不端的读者可能会反复请求新的队列会话，这会使队列服务不堪重负。因此，这不是一个好的设计，因为我们希望读者可以随意阅读而不会对队列造成任何风险。

Kafka

Kafka 是围绕一系列事件而设计的，例如：

1001：'甲'购买了旅游套餐'A'

1002：'甲'更新了他的订阅偏好为“每日”

1003：'乙'使用'iphone'登录

1004：'乙'打开了旅游套餐'巴厘岛'

1005：'乙'使用'桌面Web'登录

1006：'乙'购买了旅游套餐'巴厘岛'

Kafka 事件阅读器会跟踪它们已读取的流中的 ID，这意味着事件服务器不需要跟踪它们。即使有许多行为不佳的读者， Kafka 事件服务器也能保持可预测的内存使用。

Kafka 听起来很不错，为什么需要 redis Streams？

Kafka 是存储事件流的绝佳选择，它专为大规模而设计。为了达到这种规模，Kafka 承担了额外的复杂性，配置和管理 Kafka 设置需要了解一些复杂的概念。但对于较小的项目，更简单、更小的系统可能是更好的选择。

Redis 是简单的、非持久性数据存储的最常见选择之一。它对所有流行的编程语言都有很好的库支持，并且被大多数开发人员所熟知。Redis 支持更简单版本的 Kafka 事件流概念，使每个人都可以轻松使用。

Redis Streams使用示例

1. 创建一个名为“stream”的流

XADD stream * data hello

2. 读取名为“stream”的流中的所有消息

XREAD STREAMS stream $

3. 读取名为“stream”的流中的最新消息

XREAD STREAMS stream 0

4. 读取名为“stream”的流中的最新消息，并等待1秒钟以获取更多消息

XREAD STREAMS stream 0 BLOCK 1000

5. 读取名为“stream”的流中的最新消息，并等待1秒钟以获取更多消息，最多获取10条消息

XREAD STREAMS stream 0 COUNT 10 BLOCK 1000

6. 读取名为“stream”的流中的最新消息，并将其标记为已处理

XREAD STREAMS stream 0 COUNT 1 BLOCK 1000
XACK stream group 1526569493336-0

总结

在一些需要使用事件流的场景中，一般使用 Kafka ，但在一些简单的场景下，也可以考虑使用 Redis Stream，毕竟Redis Stream更加简单，成本更低。