redis+kafka限流_Kafka和Redis流-CSDN博客

redis+kafka限流

让我们谈谈队列设计。

我们有一本很长的书，我们希望许多人都可以阅读。有些可以在午餐时间阅读，有些可以在星期一晚上阅读，有些则可以在周末带回家。这本书太长了，以至于我们在任何时候都有数百人在读书。

我们这本书的读者需要跟踪他们在书中所处的位置 ，因此他们通过在书中添加书签来跟踪自己的位置 。一些读者阅读速度很慢，使书签接近开头。其他读者则半途而废，将他们留在中间，再也不会退缩。

更糟的是，我们每天都在这本书中添加页面 。没人能真正完成这本书。

最终，我们的书中充满了书签，直到最后一天，书太重了，无法携带。

然后，一个非常机灵的人决定不允许读者在书中放置书签，而必须在日记本上写下他们正在浏览的页面 。

这是Apache Kafka的设计，是一种非常有弹性的设计。读者通常不是负责任的公民，通常也不会自己清理自己，这本书可能是我们公司发生的所有重要事件的日志。

其他队列的常见替代设计是队列服务跟踪读者所处的位置–这意味着需要为每个读者分配内存。表现不佳的阅读器可能会反复请求新的队列会话，这可能会使队列服务不堪重负。这通常不是一个好的设计，因为我们希望读者可以随意阅读而不会冒任何风险。

阿帕奇·卡夫卡

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

1001。“ 蒂姆 ” 购买了旅游交易“ 斐济 ”
1002。“ 蒂姆 ”已将其订阅首选项更新为“ 每日 ”
1003“SAM”已登录使用“iPhone”
1004年。“ sam ”已打开旅行协议“ bali ”
1005“SAM”已经登录使用“ 桌面网页 ”
1006.“ sam ” 购买了 “ bali ”交易

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

卡夫卡听起来很棒，为什么要使用Redis Streams？

Kafka是存储事件流的绝佳选择，它是为大规模设计的。 Kafka承担了额外的复杂性以实现这一规模。设置和管理Kafka设置确实需要了解一些复杂的概念。对于较小的项目，更简单，更小的系统可能是更好的选择。尽管我们都喜欢解决Google规模的问题，但这很少需要。

对于简单的，通常为非持久性的数据存储，Redis是最常见的选择之一。它具有对所有流行编程语言的强大库支持，并且为大多数开发人员所熟知。为简单起见，这是权衡强大的分布式弹性的一个很好的例子。 Redis现在支持Kafka事件流概念的简化版本，从而使架构概念易于所有人且廉价地使用。

为了开始使用此Redis Streams，我将介绍两个新命令，这些命令现在位于Redis的“不稳定”分支中。要使用此示例进行操作，您可以免费创建一个在线的Redis实例这里在约2分钟。您也可以从此处拉Redis的“不稳定”分支。

写入Redis流

XADD stream_name * key1 value1 key2 value2（etc）

XADD允许我们编写事件流。让我们创建一个反映以上示例的事件流。我们将流命名为“事件”。

XADD events * user tim action purchase item travel:fiji
XADD events * user tim action preferences subscription daily
XADD events * user sam action login platform iPhone
XADD events * user sam action visit item travel:bali
XADD events * user sam action login platform “desktop web”
XADD events * user sam action purchase item travel:bali

“ *”用于从键值集中分离可选参数。

这会将所有这些动作写入“事件”流中。

从Redis流读取

XREAD COUNT 2 STREAMS事件item-id

XREAD使我们可以从此队列中读取项目。让我们一次阅读两个项目：

demo.wiftycloud.com:6379> XREAD COUNT 2 STREAMS events 0
1) 1) “events”
   2) 1) 1) 1512991598699–0
         2) 1) “user”
            2) “tim”
            3) “action”
            4) “purchase”
            5) “item”
            6) “travel:fiji”
      2) 1) 1512991602438–0
         2) 1) “user”
            2) “tim”
            3) “action”
            4) “preferences”
            5) “subscription”
            6) “daily”

我们要求流“事件”中的项，从列表的开头开始（通过传递“ 0”）。我们只请求了2个项目。要获取接下来的两个项目，而不是从'0'开始，我们现在从Redis返回的最后一个ID开始-在上面的示例中为'1512991602438–0'。

> XREAD COUNT 2 streams events 1512991602438–0
1) 1) “events”
   2) 1) 1) 1512991605766-0
         2) 1) “user”
            2) “sam”
            3) “action”
            4) “logon”
            5) “platform”
            6) “iPhone”
      2) 1) 1512991617871-0
         2) 1) “user”
            2) “sam”
            3) “action”
            4) “visit”
            5) “item”
            6) “travel:bali”

其他选项可用-BLOCK允许我们让Redis服务器等待连接，直到事件可用为止。

在这两个命令XADD和XREAD之间，我们可以很容易地构造一个业务事件队列。

Node.js示例

对Streams的库支持仍未准备好，但是当前可以使用自定义命令。在此处可以找到使用ioredis进行此操作的示例。