Apache Kafka与Redis流比较 - memurai

21-02-17 banq

流数据是一种非常常见的体系结构系统,因为它解决了我们必须每天处理的问题:即,可用数据太多。实时处理收到的传入数据可能是一项艰巨的任务,尤其是对于复杂的数据处理。但是,在生产者和消费者之间具有流缓冲可能是非常明智的安排。在这种情况下,Kafka和Redis流都可以异常有效地工作,因为它们提供了我们希望从流解决方案中获得的所有功能,并且可以根据需要进行扩展。

 

流到底是什么?

在继续之前,让我问以下问题:流到底是什么?简而言之,流是随时间分布的一系列数据元素。与批量一起发送大量数据相反,该流逐元素发送数据,就好像数据在传送带上一样。基于流的体系结构的工作方式是让一个或多个内容生产者将其元素发送到一个集中的位置(在Kafka术语中称为Brokers),然后将数据转发到接收者。除了有效处理实时数据之外,流处理系统(也称为消息队列)的另一个好处是它们可以充当该数据的缓冲区。这有助于创建始终响应的系统,即使传入消息量对于处理部分而言过大。在生产者和消费者之间留有缓冲,有助于消费者按照自己的节奏工作。这与直接连接生产者和消费者相反,后者可能在大量数据涌入而使消费者无法处理时潜在地使消费者泛滥。这将导致数据丢失和系统停机,而这正是消息队列试图解决的问题。

 

什么是Kafka?

Apache Kafka(或简称为Kafka)是一种流解决方案,如果要在体系结构中处理数据流,则必须考虑这一点。Kafka的主要功能(其中之一)是设计用于以最大的弹性处理大量信息。Kafka最初设计时考虑了日志处理,可以配置为每秒处理多达3000万个事件。但是,确实存在正确的安装Kafka并对其进行配置以可靠地处理大量流量的事实,这并非易事,因为可以使用大量信息。但是,解决方案周围的社区是其主要好处之一。可以使用三个关键概念来理解Kafka的基础知识:代理,主题和分区。下图是Kafka体系结构的高级概述。

该架构显示了Kafka集群是如何由代理组成的。这些代理是无状态的,ZooKeeper(群集工作所需的另一个组件)负责维护整个群集的状态。这有助于从Broker故障中恢复,因为ZooKeeper负责确定谁是主要经纪人,谁不是所有经纪人。生产者发送的消息存储在主题中。这些可以被视为逻辑通道,旨在帮助您组织和分类消息。消费者将使用这些主题仅提取他们感兴趣的消息。最后,可以对每个主题进行分区,并且每个分区都存储在不同的Broker中。Kafka将按照指示执行多次接收到的信息(也称为复制因子),

 

什么是Redis流?

许多人不知道Redis(和Memurai)的功能是可以用来处理流。的确,Redis对发布/订阅机制的支持时间最长,大多数读者可能已经知道。Pub / Sub允许不同的应用程序使用Redis作为消息总线进行通信:即,客户端在“通道”上发布“消息”,并且任何“监听”该“通道”的客户端都会收到该“消息”。

流将这一概念带入了一个新的高度。与发布/订阅不同,流客户端可以在将消息推送到流中很长时间后读取它们。另外,如果启用流,则消息本身将使用AOF和RDB持久性方法持久化。

最后,Redis流在功能上与Kafka非常等效。

以下是Redis流功能的摘要:

  • 与发布/订阅不同,消息一旦被使用就不会从流中删除。
  • Redis流可以以阻塞或非阻塞方式使用。
  • 流中的消息将具有键值结构(而不​​是简单的字符串),并且将具有唯一的序列ID。
  • 因此,消费者可以从流中的任何位置请求一系列ID。
  • 这意味着,如果使用者崩溃了,即使不活动的窗口足够大以至于在两次接收之间都收到了多条消息,它也可以从左边向右拾取。与发布/发布消息相比,这是一个显着的优势,在发布/发布消息中,发布消息并且如果没有订阅者,那么没人会收到它。
  • 消息仍然存在于AOF和RDB中。
  • 本质上,Redis流是使用此强大的NoSQL数据库处理生产者和消费者之间的异步通信的全新方式。Redis旨在使用稍微不同的方法来解决Kafka解决的相同问题。

 

高可用性和容错能力

解决高可用性和容错能力已成为大多数分布式系统的主要目标,因为它意味着即使在潜在的大故障期间也能够继续运行。这是因为分布式系统建立在“错误发生”的前提之上。因此,由于无法避免错误,因此应在系统体系结构中对其进行计划。因此,高可用性和容错性的概念已合并到这些系统中。因为它们是如此相似,所以这些概念有时会相互混淆,这里对它们进行了快速回顾:

  • 容错能力:这是一种从潜在灾难性故障中恢复而又不会在过程中丢失数据的能力。从本质上讲,该平台可以接受并处理问题,但在此期间可能无法使用。
  • 高可用性:这意味着即使在发生故障的情况下,平台始终可以访问。这并不意味着它在此期间将按预期工作,但是可以实现,并且如果使用了正确的数据保留策略,则在此过程中可能不会丢失数据。

Kafka是一个分布式系统,这意味着它可以(或应该)配置为在多个不同的服务器上运行。使用此配置,系统可以将接收到的数据复制到多台服务器上,并保持其同步版本。万一Broker发生故障,ZooKeeper将抓住该故障并提升一名备份Broker成为新的主管。然后,它将针对此更改更新连接到代理的每个客户端。这种行为为Kafka提供了任何支持流的组件都必须具备的两个主要功能:•抵抗故障的能力(即,避免在分布式组件之一发生故障时丢失数据)。•在该过程中保持可用的能力。如果将来有故障的代理重新合并到集群中,

Redis本身通过称为Sentinel的组件提供了高可用性。它本身是一个分布式系统,可以监视故障转移策略并将其提供给可能正在运行的Redis的不同实例。Sentinel使用主从机制工作,这意味着在任何给定时间只有Redis的单个实例将充当主节点。如果由于某种原因它掉线了,它的一个从属节点将接替。Redis的群集版本还使用非常复杂的逻辑在节点之间通信和共享从站,从而实现了高可用性和分区抵抗性(即,当群集的某些部分由于故障而被隔离时)。此外,Redis的群集配置通过分片数据并具有类似的内部主从节点配置来提供容错能力。群集中的所有节点都在不断地相互ping通,以在混合中找到“漏洞”,一旦检测到漏洞,它将重新配置自身以提升合适的从机。

 

什么时候使用其中一个?

Kafka是企业级生产解决方案,具有高度的弹性和鲁棒性。但是,设置,配置和维护Kafka并非易事。还应考虑物理(强大)服务器或虚拟机的成本。

Redis(在Linux上)和Memurai(在Windows上)也是具有类似级别的弹性和健壮性的企业级生产级解决方案,但是它们可以与xcopy一起部署并在2分钟内完成设置,而维护成本却几乎为零。目前,一支由单一开发人员组成的队伍正在其单主配置中使用Redis和Memurai。

 

                   

1
猜你喜欢