云计算·大数据 频道

Kafka和Redis如何解决流处理挑战

  虽然流可以是处理大量数据的有效方式,但它们也有自己的挑战。让我们看看其中的一些。

  1. 如果消费者无法像制作人创建块那样快速处理块,会发生什么?一个例子:如果消费者比生产者慢50%,会怎么样?如果我们从一个10GB的文件开始,这意味着当生产者处理完所有10GB时,消费者只处理了5GB。剩余的5GB在等待处理时会发生什么情况?突然之间,分配给仍然需要处理的数据的50到100字节必须扩展到5GB。

  图1:如果消费者的速度比生产者慢,则需要额外的内存。

  2. 这只是一个噩梦场景。还有其他的。例如,如果消费者在处理一条生产线时突然失效,会发生什么情况?你需要一种跟踪正在处理的行的方法,以及一种允许重新读取该行和随后的所有行的机制。

  图2:当消费者失效时。

  3. 最后,如果你需要能够处理不同的事件并将其发送给不同的消费者,会发生什么?此外,如果增加额外的复杂性,一个消费者的进程依赖于另一个消费者,那么就有相互依赖的进程,会怎么样?一个真正的风险是,你最终会遇到一个复杂的、紧耦合的、难以管理的单体系统——随着不断添加和删除不同的生产者和消费者,这些需求将不断变化。

  举个例子(图3),假设我们有一家大型零售店,拥有数千台服务器,支持通过网络应用和移动应用进行购物。

  假设我们正在处理三种与支付、库存和Web服务器日志相关的数据,每种数据都有一个相应的消费者:“支付处理器”、“库存处理器”和“Web服务器事件处理器”。此外,两个消费者之间存在着重要的相互依赖关系。在处理库存之前,需要先验证付款。最后,每种类型的数据都有不同的目的地。如果是支付事件,则将输出发送到所有系统,如数据库、电子邮件系统、CRM等。如果是Web服务器事件,则仅将其发送到数据库。如果是库存事件,则将其发送到数据库和CRM。

  你可以想象,这很快就会变得非常复杂和混乱。这还不包括我们需要为每个消费者处理的慢消费者和容错问题。

  图3:紧耦合的挑战,因为有多个生产者和消费者。

  当然,所有这些都假设你正在处理一个单体架构,你有一台服务器接收和处理所有事件。你将如何处理微服务架构?在这种情况下,许多小型服务器,即微服务,将处理事件,它们都需要能够相互通信。突然间,你不仅仅有多个生产者和消费者,它们还分散在多个服务器上。

  微服务的一个关键好处是,它们解决了根据不断变化的需求扩展特定服务的问题。不幸的是,微服务只解决了一些问题。我们的生产者和消费者之间仍然存在紧耦合,我们保留了库存微服务和支付服务之间的依赖关系。我们在最初的流媒体示例中指出的问题仍然存在:

  ——我们还没有弄清楚当消费者崩溃时该怎么办。

  ——我们还没有找到一种管理慢消费者、不会迫使我们大幅扩大缓冲区规模的方法。

  ——我们还没有办法确保数据不会丢失。

  这些只是一些主要挑战。让我们看看如何解决这些问题。

  图4:微服务世界中紧耦合的挑战

  专用流处理系统

  正如我们所看到的,流可以非常适合处理大量数据,但也带来了一系列挑战。为了解决这些挑战,引入了新的专用系统,如Apache Kafka和Redis Streams。在Kafka和Redis流的世界中,服务器不再像流那样位于中心,其他一切都围绕着它们。

  数据工程师和数据架构师经常共享这种以流为中心的世界观。当流成为中心时,一切都是流水线型的,这并不奇怪。

  图5显示了前面看到的紧耦合示例的直接映射。让我们看看它在高层次上是如何工作的。

  ——在这里,流和数据(事件)是一等公民,而不是处理它们的系统。

  ——任何有兴趣发送数据(生产者)、接收数据(消费者)或同时发送和接收数据(生产者和消费者)的系统都连接到流处理系统。

  ——由于生产者和消费者是解耦的,因此可以随意添加其他消费者或生产者。你可以听任何你想听的事件。这使得它非常适合微服务架构。

  ——如果消费者速度较慢,则可以通过添加更多消费者来增加消费。

  ——如果一个消费者依赖于另一个消费者,你可以简单地监听该消费者的输出流,然后进行处理。例如,在上图中,库存服务在处理库存事件之前从库存流(紫色)和支付处理流(橙色)的输出接收事件。这就是解决相互依赖问题的方法。

  ——流中的数据是持久的(与在数据库中一样)。任何系统都可以随时访问任何数据。如果由于某种原因数据没有被处理,你可以重新处理它。

  许多流挑战一度看似艰巨,甚至无法克服,但只要把流放在中心,就可以轻易解决。这就是为什么越来越多的人在他们的数据层中使用Kafka和Redis Streams,这也是为什么数据工程师将流视为世界的中心。

0
相关文章