怎么添加网站 多少钱,个人怎么做淘宝客网站,网站建设兼职合同,沈阳哪家做网站最好消息中间件-Kafka
一、kafka简介
1、概念 Kafka是最初由Linkedin公司开发#xff0c;是一个分布式、支持分区#xff08;partition#xff09;、多副本的#xff08;replica#xff09;#xff0c;基于zookeeper协调的分布式消息系统#xff0c;它的最大的特性就是可以…消息中间件-Kafka
一、kafka简介
1、概念 Kafka是最初由Linkedin公司开发是一个分布式、支持分区partition、多副本的replica基于zookeeper协调的分布式消息系统它的最大的特性就是可以实时的处理大量数据以满足各种需求场景比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎web/nginx日志、访问日志消息服务等等用scala语言编写Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 2、Kafka特性
Kafka具有近乎实时性的消息处理能力即使面对海量消息也能够高效地存储消息和查询消息。 Kafka将消息保存在磁盘中它以顺序读写的方式访问磁盘从而避免了随机读写磁盘导致的性能瓶颈。Kafka支持批量读写消息并且会对消息进行批量压缩Kafka支持消息分区每个分区中的消息保证顺序传输而分区之间则可以并发操作具备高并发能力Kafka也支持在线增加分区支持在线水平扩展Kafka支持为每个分区创建多个副本其中只会有一个Leader副本负责读写其他副本只负责与Leader副本进行同步Kafka会将Leader副本均匀地分布在集群中的服务器上实现性能最大化同时具备较强的容灾能力
3、应用场景
在应用系统中可以将Kafka作为传统的消息中间件实现消息队列和消息的发布/订阅在某些特定场景下其性能要更优于RabbitMQ、ActiveMQ等传统的消息中间件Kafka也被用作系统中的数据总线将其接入多个子系统中子系统会将产生的数据发送到Kafka中保存之后流转到目的系统中Kafka还可以用作日志收集中心多个系统产生的日志统一收集到Kafka中然后由数据分析平台进行统一处理。日志会被Kafka持久化到磁盘所以同时支持离线数据处理和实时数据处理事件溯源 Kafka的持久化存储和顺序消息传递特性使其成为事件溯源的理想选择。通过将系统的事件以消息的形式写入Kafka的主题中可以实现对系统状态的完全恢复和追溯。这对于需要满足合规性要求或实现事件溯源的系统非常重要如金融交易系统、电子商务系统等。流媒体处理 Kafka在流媒体处理领域也有着广泛的应用。流媒体处理要求系统能够高效地处理大规模的音视频数据流。Kafka的高吞吐量和低延迟特性使其成为一个理想的流媒体处理平台。通过使用Kafka可以构建高性能的音视频处理系统实现实时的流媒体传输、转码、存储和分发。
4、数据持久化 在分布式系统中各个组件是通过网路连接起来的。一般认为网络传输是不可靠的当数据在两个组件之间进行传递的时候传输过程可能会失败。除非数据被持久化到磁盘否则就可能造成消息的丢失。Kafka把数据以消息的形式持久化到磁盘即使Kafka出现宕机也可以保证数据不会丢失通过这一方式规避了数据丢失风险。为了避免磁盘上的数据不断增长Kafka提供了日志清理、日志压缩等功能对过时的、已经处理完成的数据进行清除。在磁盘操作中耗时最长的就是寻道时间这是导致磁盘的随机I/O性能很差的主要原因。为了提高消息持久化的性能Kafka采用顺序读写的方式访问实现了高吞吐量。 5、扩展与容灾 Kafka的每个Topic主题都可以分为多个Partition分区每个分区都有多个Replica副本实现消息冗余备份。每个分区中的消息是不同的这类似于数据库中水平切分的思想提高了并发读写的能力。而同一分区的不同副本中保存的是相同的消息副本之间是一主多从的关系其中Leader副本负责处理读写请求Follower副本则只与Leader副本进行消息同步当Leader副本出现故障时则从Follower副本中重新选举Leader副本对外提供服务。这样通过提高分区的数量就可以实现水平扩展通过提高副本的数量就可以提高容灾能力。 Kafka的容灾能力不仅体现在服务端在Consumer端也有相关设计。Consumer使用pull方式从服务端拉 取消息并且在Consumer端保存消费的具体位置当消费者宕机后恢复上线可以根据自己保存的消费位 置重新拉取需要的消息进行消费这就不会造成消息丢失。也就是说Kafka不决定何时、如何消费消息 而是Consumer自己决定何时、如何消费消息。 Kafka还支持Consumer的水平扩展能力。我们可以让多个Consumer加入一个Consumer Group消费组在一个Consumer Group中每个分区只能分配给一个Consumer消费当Kafka服务端通过增加分区数量进行水平扩展后我们可以向Consumer Group中增加新的Consumer来提高整个Consumer Group的消费能力。当Consumer Group中的一个Consumer出现故障下线时会通过Rebalance操作将下线Consumer负责处理的分区分配给其他Consumer继续处理当下线Consumer重新上线加入Consumer Group时会再进行一次Rebalance操作重新分配分区。当然一个Consumer Group可以订阅很多不同的Topic每个Consumer可以同时处理多个分区 6、分区数据的顺序保证 Kafka保证一个分区内的消息的有序性但是并不保证多个partition之间的数据有顺序。 7、异步通信 Kafka为系统提供了异步处理能力。例如两个系统需要通过网络进行数据交换其中一端可以把一个消息放入Kafka中后立即返回继续执行其他路基不需要等待对端的响应。待后者将处理结果放入Kafka中之后前者可以从其中获取并解析响应。
二、Kfaka核心概念
消息 消息是Kafka中最基本的数据单元。消息由一串字节构成其中主要由key和value构成key和value也都是byte数组。key的主要作用是根据一定的策略将此消息路由到指定的分区中这样就可以保证包含同一key的消息全部写入同一分区中key可以是null。Topic/分区/Log Topic是用于存储消息的逻辑概念可以看作一个消息集合。每个Topic可以有多个生产者向其中推送push消息也可以有任意多个消费者消费其中的消息。每个Topic可以划分成多个分区每个Topic都至少有一个分区同一Topic下的不同分区包含的消息是不同的。每个消息在被添加到分区时都会被分配一个offset它是消息在此分区中的唯一编号Kafka通过offset保证消息在分区内的顺序offset的顺序性不跨分区即Kafka只保证在同一个分区内的消息是有序的同一Topic的多个分区内的消息Kafka并不保证其顺序性。同一Topic的不同分区会分配在不同的Broker上。分区是Kafka水平扩展性的基础我们可以通过增加服务器并在其上分配Partition的方式来增加Kafka的并行处理能力。 分区在逻辑上对应着一个Log当生产者将消息写入分区时实际上是写入到了分区对应的Log中。Log是一个逻辑概念可以对应到磁盘上的一个文件夹。Log由多个Segment组成每个Segment对应一个日志文件和索引文件。在面对海量数据时为避免出现超大文件每个日志文件的大小是有限制的当超出限制后则会创建新的Segment继续对外提供服务。这里要注意因为Kafka采用顺序I/O所以只向最新的Segment追加数据。保留策略与日志压缩 无论消费者是否已经消费了消息Kafka都会一直保存这些消息但并不会像数据库那样长期保存。为了避免磁盘被占满Kafka会配置相应的“保留策略”retention policy以实现周期性地删除陈旧的消息。 一种是根据消息保留的时间当消息在Kafka中保存的时间超过了指定时间就可以被删除 根据Topic存储的数据大小当Topic所占的日志文件大小大于一个阈值则可以开始删除最旧的消息。 Kafka会启动一个后台线程定期检查是否存在可以删除的消息。“保留策略”的配置是非常灵活的可以有全局的配置也可以针对Topic进行配置覆盖全局配置。
消息压缩 在很多场景中消息的key与value的值之间的对应关系是不断变化的就像数据库中的数据会不断被修改一样消费者只关心key对应的最新value值。此时可以开启Kafka的日志压缩功能Kafka会在后台启动一个线程定期将相同key的消息进行合并只保留最新的value值。 压缩过程 Broker 一个单独的Kafka服务器就是一个Broker。Broker的主要工作就是接收生产者发过来的消息分配offset之后保存到磁盘中同时接收消费者、其他Broker的请求根据请求类型进行相应处理并返回响应。在一般的生产环境中一个Broker独占一台物理服务器。分区副本 每个分区的副本集合中都会选举出一个副本作为Leader副本Kafka在不同的场景下会采用不同的选举策略所有的读写请求都由选举出的Leader副本处理其他都作为Follower副本Follower副本仅仅是从Leader 副本处把数据拉取到本地之后同步更新到自己的Log中。一般情况下同一分区的多个副本会被分配到不同的Broker上这样当Leader所在的Broker宕机之后可以重新选举新的Leader继续对外提供服务。ISRIn-Sync Replica集合 ISRIn-Sync Replica集合表示的是目前“可用”alive且消息量与Leader相差不多的副本集合,其中每个副本必须满足副本所在节点必须维持着与ZooKeeper的连接与副本最后一条消息的offset与Leader副本的最后一条消息的offset之间的差值不能超出指定的阈值* 每个分区中的Leader副本都会维护此分区的ISR集合。写请求首先由Leader副本处理之后Follower副本会从Leader上拉取写入的消息这个过程会有一定的延迟导致Follower副本中保存的消息略少于Leader副本只要未超出阈值都是可以容忍的。如果一个Follower副本出现异常比如宕机发生长时间GC而导致Kafka僵死或是网络断开连接导致长时间没有拉取消息进行同步就会违反上面的两个条件从而被Leader副本踢出ISR集合。当Follower副本从异常中恢复之后会继续与Leader副本进行同步当Follower副本“追上”即最后一条消息的offset的差值小于指定阈值Leader副本的时候此Follower副本会被Leader副本重新加入到ISR中。HW HWHighWatermark和LEO与上面的ISR集合紧密相关。HW标记了一个特殊的offset当消费者处理消息的时候只能拉取到HW之前的消息HW之后的消息对消费者来说是不可见的。与ISR集合类似HW也是由Leader副本管理的。当ISR集合中全部的Follower副本都拉取HW指定消息进行同步后Leader副本会递增HW的值。LEOLog End Offset LEO是所有的副本都会有的一个offset标记它指向追加到当前副本的最后一个消息的offset。当生产者向Leader副本追加消息的时候Leader副本的LEO标记会递增当Follower副本成功从Leader副本拉取消息并更新到本地的时候Follower副本的LEO就会增加。
HW与LEO的关系如下图 ①Producer向此Partition推送消息。 ②Leader副本将消息追加到Log中并递增其LEO。 ③Follower副本从Leader副本拉取消息进行同步。 ④Follower副本将拉取到的消息更新到本地Log中并递增其LEO。 ⑤当ISR集合中所有副本都完成了对offset11的消息的同步Leader副本会递增HW。 在①~⑤步完成之后offset11的消息就对生产者可见了。
为什么kafka数据冗余要设计成这样 常见的数据同步包括同步复制和异步复制。 同步复制要求所有能工作的Follower副本都复制完这条消息才会被认为提交成功。一旦有一个 Follower副本出现故障就会导致HW无法完成递增消息就无法提交生产者获取不到消息。这 种情况下故障的Follower副本会拖慢整个系统的性能甚至导致整个系统不可用。 异步复制中Leader副本收到生产者推送的消息后就认为此消息提交成功。Follower副本则异步 地从Leader副本同步消息。这种设计虽然避免了同步复制的问题但同样也存在一定的风险。现在 假设所有Follower副本的同步速度都比较慢它们保存的消息量都远远落后于Leader副本。 此时Leader副本所在的Broker突然宕机则会重新选举新的Leader副本而新Leader副本中没有原来 Leader副本的消息这就出现了消息的丢失而有些消费者则可能消费了这些丢失的消息状态变得不可控。 Kafka权衡了同步复制和异步复制两种策略通过引入了ISR集合巧妙地解决了上面两种方案存在的 缺陷当Follower副本的延迟过高时Leader副本被踢出ISR集合消息依然可以快速提交生产者可以快速得到响应避免高延时的Follower副本影响整个Kafka集群的性能。当Leader副本所在的Broker突然宕机的时候会优先将ISR集合中Follower副本选举为Leader副本新Leader副本中包含了HW之前的全部消息这就避免了消息的丢失。值得注意是Follower副本可以批量地从Leader副本复制消息这就加快了网络I/OFollower 副本在更新消息时是批量写磁盘加速了磁盘的I/O极大减少了Follower与Leader的差距。Cluster(集群)与Controller(指挥中心) 多个Broker可以做成一个Cluster集群对外提供服务每个Cluster当中会选举出一个Broker来担任 ControllerController是Kafka集群的指挥中心而其他Broker则听从Controller指挥实现相应的功能。 Controller负责管理分区的状状态、管理每个分区的副本状态、监听Zookeeper中数据的变化等工作。 Controller也是一主多从的实现所有Broker都会监听Controller Leader的状态当Leader Controller出现故障时则重新选举新的Controller Leader。生产者 生产者Producer的主要工作是生产消息并将消息按照一定的规则推送到Topic的分区中。这里选 择分区的“规则”可以有很多种例如根据消息的key的Hash值选择分区或按序轮询全部分区的方式。消费者 消费者Consumer的主要工作是从Topic中拉取消息并对消息进行消费。某个消费者消费到 Partition的哪个位置offset的相关信息是Consumer自己维护的。 如下图 Consumer Group 消费者组 在Kafka中多个Consumer可以组成一个Consumer Group一个Consumer只能属于一个Consumer Group。Consumer Group保证其订阅的Topic的每个分区只被分配给此Consumer Group中的一个消费者处理。如果不同Consumer Group订阅了同一TopicConsumer Group彼此之间不会干扰。这样如果要实现一个消息可以被多个消费者同时消费“广播”的效果则将每个消费者放入单独的一个Consumer Group如果要实现一个消息只被一个消费者消费“独占”的效果则将所有Consumer放入一个Consumer Group中。 消费者组消费消息如图 Consumer Group除了实现“独占”和“广播”模式的消息处理Kafka还通过Consumer Group实现了消费者的水平扩展和故障转移。在上图中当Consumer3的处理能力不足以处理两个Partition中的数据时可以通过向Consumer Group中添加消费者的方式触发Rebalance操作重新分配分区与消费者的对应关系从而实现水平扩展。如下图所示添加Consumer4之后Consumer3只消费Partition2中的消息Partition3中的消息则由Consumer4来消费。 下面来看消费者出现故障的场景当Consumer4宕机时Consumer Group会自动重新分配分区如下图所示由Consumer3接管Consumer4对应的分区继续处理。 注Consumer Group中消费者的数量并不是越多越好当其中消费者数量超过分区的数量时会导 致有消费者分配不到分区从而造成消费者的浪费
三、Kafak消息处理流程图
单个Kafka Server单体模式 Kafka的每个Topic主题都可以分为多个Partition分区每个分区都有多个Replica副本实现消息冗余备份。每个分区中的消息是不同的这类似于数据库中水平切分的思想提高了并发读写的能力。而同一分区的不同副本中保存的是相同的消息副本之间是一主多从的关系其中Leader副本负责处理读写请求Follower副本则只与Leader副本进行消息同步当Leader副本出现故障时则从Follower副本中重新选举Leader副本对外提供服务。集群Kafak Server 集群模式 如上所示生产者会根据业务逻辑产生消息之后根据路由规则将消息发送到指定分区的Leader副本所在的Broker上。在Kafka服务端接收到消息后会将消息追加到Log中保存之后Follower副本会与 Leader副本进行同步当ISR集合中所有副本都完成了此消息的同步后则Leader副本的HW会增加并向生产者返回响应。 当消费者加入到Consumer Group时会触发Rebalance操作将分区分配给不同的消费者消费。随后消费者会恢复其消费位置并向Kafka服务端发送拉取消息的请求Leader副本会验证请求的offset以及其他相关信息最后返回消息。
