虽然流可以成为处理大量数据的有效方式，但它们也有自己的挑战。让我们看看其中的一些。1.如果消费者不能像生产者创建区块那样快地处理区块会怎样？举个例子：如果消费者比生产者慢50%怎么办？如果我们从一个10GB的文件开始，这意味着当生产者处理完所有10GB时，消费者只处理了5GB。剩余的5GB等待处理会怎样？突然之间，分配给仍需要处理的数据的50到100字节必须扩展到5GB。图1：如果消费者比生产者慢，则需要额外的内存2.这简直就是一场噩梦。还是得到了更多。例如，如果消费者在处理生产线时突然发生故障怎么办？您需要一种方法来跟踪正在处理的行，以及一种允许重新读取该行和所有后续行的机制。图2：当一个消费者失败时3.最后，如果您需要能够处理不同的事件并将它们发送给不同的消费者怎么办？另外，如果增加额外的复杂性，一个消费者的过程依赖于另一个消费者，那么存在相互依赖的过程怎么办？一个真正的风险是你最终会得到一个复杂的、紧密耦合的、难以管理的单体系统——随着不同的生产者和消费者的不断添加和删除，这些需求不断变化。例如（图3），假设我们有一家大型零售店，拥有数千台支持通过Web应用程序和移动应用程序购物的服务器。假设我们正在处理三种与支付、库存和网络服务器日志相关的数据，每种数据都有一个相应的消费者：“支付处理器”、“库存处理器”和“网络服务器事件处理器”。此外，两个消费者之间存在重要的相互依存关系。在处理库存之前需要验证付款。最后，每种类型的数据都有不同的目的地。如果是支付事件，将输出发送到所有系统，如数据库、电子邮件系统、CRM等。如果是Web服务器事件，则只发送到数据库。如果是库存事件，则会发送到数据库和CRM。可以想象，这会很快变得非常复杂和混乱。而且这还不包括我们需要为每个消费者处理的慢消费者和容错问题。图3：由于多个生产者和消费者而导致的紧耦合挑战当然，所有这些都假设您正在处理单体架构，其中您有一个服务器接收和处理所有事件。您将如何处理微服务架构？在这种情况下，许多小型服务器，即微服务，将处理事件，它们都需要能够相互通信。突然之间，您不仅拥有多个生产者和消费者，而且它们分布在多个服务器上。微服务的一个主要好处是它们解决了根据不断变化的需求扩展特定服务的问题。不幸的是，微服务只能解决一些问题。我们的生产者和消费者之间仍然存在紧密耦合，我们保持库存微服务和支付服务之间的依赖关系。我们在原始流式处理示例中指出的问题仍然存在：我们还没有弄清楚当消费者崩溃时该怎么办。我们还没有找到一种方法来管理缓慢的消费者，而不会迫使我们显着增加缓冲区大小。我们没有办法保证数据不会丢失。这些只是一些主要挑战。让我们看看如何解决这些问题。图4：微服务世界中紧耦合的挑战专用流处理系统正如我们所见，流非常适合处理大量数据，但也带来了一系列挑战。为了应对这些挑战，引入了新的专用系统，例如ApacheKafka和RedisStreams。在Kafka和Redis流的世界里，服务器不再像流一样处于中心位置，其他一切都围绕着它们。数据工程师和数据架构师经常分享这种以流为中心的世界观。当流处于中心位置时，一切都变得流线型也就不足为奇了。图5显示了前面看到的紧耦合示例的直接映射。让我们看看它是如何在高层次上工作的。在这里，流和数据（事件）是一等公民，而不是处理它们的系统。任何对发送数据（生产者）、接收数据（消费者）或同时发送和接收数据（生产者和消费者）感兴趣的系统都连接到流处理系统。由于生产者和消费者是解耦的，因此可以随意添加额外的消费者或生产者。您可以收听任何您想要的活动。这使得它非常适合微服务架构。如果消费者速度慢，可以通过增加更多的消费者来增加消费。如果一个消费者依赖于另一个消费者，你可以简单地监听那个消费者的输出流，并处理它。例如，在上图中，库存服务在处理库存事件之前从库存流（紫色）和支付处理流（橙色）的输出接收事件。这就是解决相互依赖问题的方法。流中的数据是持久的（就像在数据库中一样）。任何系统都可以随时访问任何数据。如果由于某种原因数据未被处理，您可以重新处理它。许多曾经看起来令人生畏甚至无法克服的流挑战，可以通过将流置于中心而轻松解决。这就是为什么越来越多的人在他们的数据层中使用Kafka和RedisStreams，这就是为什么数据工程师将流视为他们世界的中心。原文链接：https://thenewstack.io/how-kafka-and-redis-solve-stream-processing-challenges/
