虽然流可以是处理大量数据的有效方式,但它们也有自己的挑战。让我们看看其中的一些。
成都做网站、网站建设服务团队是一支充满着热情的团队,执着、敏锐、追求更好,是创新互联的标准与要求,同时竭诚为客户提供服务是我们的理念。成都创新互联把每个网站当做一个产品来开发,精雕细琢,追求一名工匠心中的细致,我们更用心!
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,这也是为什么数据工程师将流视为世界的中心。
本文题目:Kafka和Redis如何解决流处理挑战
转载注明:http://www.shufengxianlan.com/qtweb/news40/8340.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联