kafka简介

1.1 Apache Kafka是一个分布式流媒体平台。
1.1.1 流媒体平台有三个关键功能:
① 发布和订阅记录流,类似于消息队列或者企业消息传递系统
② 以容错持久的方式存储记录流
③ 处理记录发生的流
1.1.2 kafka通常用于两大类应用:
① 构建可在系统或应用程序之间可靠获取数据的实时流数据管道
② 构建实时流应用程序,用于转换或响应数据流
1.1.3 要了解卡夫卡如何做这些事情,需要了解以下三点:
① kafka作为一个集群运行在一台或多台可以跨越多个数据中心的服务器上。
② kafka集群在称为topic(主题)的类别中存储记录流
③ 每个记录由一个键、一个值和一个时间戳组成
1.1.4 kafka有四个核心API
① 允许应用程序发布的记录流至一个或多个kafka的topic
② 允许应用程序订阅一个或多个topic,并处理所产生的对他们记录的数据流
③ 允许应用程序充当流处理器,从一个或多个主题消耗的输入流,并产生一个输出流至一个或多个输出的主题。
④ 允许构建和运行卡夫卡主题连接到现在的应用程序或数据系统中重用生产者或消费者。例如:连接到关系型数据库的连接器可能会捕获对表的每个更改。
1.1.5 在kafka中,客户端和服务器之间的通信是通过一种简单的,高性能的,语言不可知的TCP协议完成的。该协议是版本控制的,并保持与旧版本的向后兼容性。例如:Java客户端(还有其它多种语言)
1.2 主题和日志
1.2.1 kafka核心抽象——主题
主题是记录发布到的类别名称。kafka的topic时钟是多用户的;也就是说,一个topic可以没有,或者一个或者多个订阅写入数据的消费者。对于每个主题,kafka集群都维护一个分区日志,如下所示:

每个分区都有一个有序的,不可变的记录序列,不断追加到结构化的提交日志中。分区中的记录每个分配一个联系的id号,称为偏移量,用于唯一标识分区内的每条记录。
kafka集群使用可配置的保留期持续保留所有已发布的记录,不管他们是否已被消耗。例如,如果保留策略设置为两天,则在记录发布后的两天内,保留策略可用于消耗,之后将被丢弃以释放空间。kafka的性能在数据大小方面实际上是不变的,因此长时间存储数据不成问题。

实际上,保留在每个消费者基础上的唯一元数据是该消费者在日志中的体校或位置。这个偏移量是由消费者控制的:消费者通常回来读取记录时现行地推进其偏移量,但实际上,由于位置由消费者控制,因此他可以按任何喜欢的顺序消费记录。例如:消费者可以充值为较旧的偏移量以重新处理来自过去的数据,或者跳至最近的记录并从“now"开始消费。
这种功能的组合意味着kafka消费者非常便宜,他们可以来来去去,对集群或者其他消费者没有太大的影响。例如,可以使用命令行工具来“追查”任何主题的内容,而无需更改任何现有客户端的内容。
日志中的分区有多种用途。首先,他们允许日志的大小超过适合单个服务器的大小。每个单独的分区必须适合托管它的服务器,但是一个topic可能有多个分区,它们作为并行的单位,因此它可以处理任意数量的数据。
1.2.2 分配
日志的分区分布在kafka集群中的服务器上,每个服务器处理数据并请求分区的一部分。每个分区都通过可配置数量的服务器进行复制以实现容错。
每个分区都有一台服务器充当“ leader”,零个或者多个服务器充当“ followers”(追随者)。领导处理分区的所有读取和写入请求,而“followers”被动的复制领导。如果领导失败,其中一个floower将自动成为新的leader。每个服务器都充当其中一些分区的leader和其他人的follower,因此负载在集群内平衡良好
1.2.3 地域复制
kafka MirrorMaker为集群提供地理复制支持,借助MirrorMaker,消息可以跨多个数据中心火云服务器区域进行复制。您可以在主动/被动场景中将其用于备份和恢复;或者在主动/被动方案中将数据置于更接近用户的位置,或支持数据本地化要求。
1.2.4 生产者
生产者将数据发布到他们选择的topic。制作人负责选择将那个记录分配给topic中的那个分区。这可以以循环方式完成,只是为了平衡负载,或者可以根据某种语义分区功能(例如基于记录汇总的某个键)完成。
1.2.5 消费者
消费者用消费者组名称标记自己,并且发布到主题的每个记录都被传递到每个订阅消费者组中的一个消费者实例。消费者实例可以在单独的进程中或在单独的机器上。
如果所有消费者实例具有相同的消费者组,则记录将有效地在消费者实例上进行负载均衡。
如果所有消费者实例具有不同的消费者组,则每条记录都将广播给所有消费者进程。

在Kafka中实现消费的方式是将日志中的分区划分为消费者实例,以便每个实例在任何时间点都是“公平分享”分区的独占消费者。这个维护组中成员资格的过程是由Kafka协议动态处理的。如果新实例加入该组,则他们将接管来自该组的其他成员的一些分区; 如果一个实例死亡,其分区将分配给其余实例。
卡夫卡只提供一个分区内记录的总顺序,而不是主题中不同分区之间的顺序。按分区排序与按键分区数据的能力相结合,足以满足大多数应用程序的需求。但是,如果您需要全部订单而不是记录,则可以通过仅有一个分区的主题来实现,但这意味着每个消费者组只有一个消费者进程。
1.2.6 多租户
通过配置那些主题可以禅城或使用数据来启用多租户。还有配额操作支持。管理员可以根据请求定义和执行配额一控制客户端使用的代理资源。
1.2.7 kafka功能
① 作为存储系统
任何允许发布消息与消费消息分离的消息队列都可以充当存储系统的空中消息。卡夫卡的不同之处在于它是一个非常好的存储系统。
写入Kafka的数据写入磁盘并进行复制以实现容错。Kafka允许生产者等待确认,以便在完全复制之前写入不被认为是完整的,并且即使写入的服务器失败也能保证持续写入。
Kafka磁盘结构使用的规模很大 - 无论您在服务器上有50 KB还是50 TB的持久性数据,Kafka都会执行相同的操作。
作为认真考虑存储并允许客户端控制其读取位置的结果,您可以将Kafka视为一种专用于高性能,低延迟提交日志存储,复制和传播的专用分布式文件系统。
② 作为消息系统
消息传统上有两种模式: 排队 发布 - 订阅 。在队列中,消费者池可以从服务器读取,并且每条记录都会转到其中的一个; 在发布 - 订阅记录被广播给所有消费者。这两种模式都有优势和劣势。排队的优势在于它允许您将多个用户实例中的数据处理分开,从而扩展您的处理。不幸的是,队列不是多用户的 - 一旦一个进程读取数据消失了。发布 - 订阅允许您将数据广播到多个进程,但无法进行扩展处理,因为每条消息都发送给每个订阅者。
卡夫卡的消费群体概念概括了这两个概念。与队列一样,消费者组允许您将一系列流程(消费者组成员)的处理分开。与发布 - 订阅一样,卡夫卡允许您向多个消费者群体广播消息。
卡夫卡模式的优点是每个主题都有这些属性 - 它可以扩展处理,也可以是多用户 - 不需要选择其中一个。
Kafka也比传统的消息系统有更强大的订单保证。
传统队列在服务器上按顺序保留记录,并且如果多个使用者从队列中消耗,则服务器按照它们存储的顺序提交记录。但是,尽管服务器按顺序提交记录,但记录会异步传送给消费者,因此它们可能会针对不同的消费者按顺序到达。这实际上意味着在并行消耗的情况下记录的排序会丢失。消息传递系统通常具有“排他消费者”的概念,只允许一个进程从队列中消费,但这当然意味着处理中没有并行性。
卡夫卡做得更好。通过在主题内部有一个并行概念 - 分区概念,Kafka能够在消费者流程池中提供订单保证和负载均衡。这是通过将主题中的分区分配给使用者组中的使用者来实现的,以便每个分区仅由组中的一位使用者使用。通过这样做,我们确保消费者是该分区的唯一读者,并按顺序使用数据。由于有很多分区,这仍然可以平衡许多消费者实例的负载。但请注意,消费者组中的消费者实例不能多于分区。
③ 用于流处理
仅读取,写入和存储数据流是不够的,目的是启用流的实时处理。
在Kafka中,流处理器是指从输入主题获取连续数据流,对该输入执行一些处理并生成连续数据流以输出主题的任何内容。
例如,零售应用程序可能会接受销售和装运的输入流,并输出一系列重新排序和对这些数据计算出的价格调整。
可以直接使用生产者API和消费者API进行简单的处理。然而,对于更复杂的转换,Kafka提供了完全集成的 Streams API 。这允许构建应用程序进行非平凡的处理,从而计算聚合关闭流或将流连接在一起。
这个工具有助于解决这类应用程序面临的难题:处理无序数据,重新处理代码更改的输入,执行有状态的计算等。
流API基于Kafka提供的核心原语构建:它使用生产者API和消费者API输入,使用Kafka进行有状态存储,并在流处理器实例之间使用相同的组机制来实现容错。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值