免费个人网站建站能上传视频吗,机械毕业设计代做网站,手机版网站建设方案,wordpress新用户提醒Kafka快速实战以及基本原理详解
基本概念
Kafka是一个分布式、支持分区、多副本#xff0c;基于ZK的分布式消息系统#xff0c;最大的特性就是可以实时的处理大量数据以满足各种需求场景#xff0c;比如Hadoop的批处理系统、低延迟的实时系统、Storm/Spark流式处理引擎、日…Kafka快速实战以及基本原理详解
基本概念
Kafka是一个分布式、支持分区、多副本基于ZK的分布式消息系统最大的特性就是可以实时的处理大量数据以满足各种需求场景比如Hadoop的批处理系统、低延迟的实时系统、Storm/Spark流式处理引擎、日志等使用场景 日志收集 可以用Kafka收集各种服务的日志通过Kafka以统一接口服务的方式开放给各种Consumer比如Hadoop、Hbase、Solr等 消息系统 解耦、消息等 用户活动跟踪 记录用户的各种活动。如浏览网页、搜索、点击等按照不同类型放到不同的Topic中然后订阅者通过这些topic来做实时的监控分析或者装载到Hadoop、数仓中做离线分析和挖掘 运营指标 记录运营监控数据包括收集各种分布式应用的数据生产各种操作的集中反馈比如告警和报告
组成部分 Broker 消息中间件处理节点一个Kafka节点就是一个Broker一个或者多个Broker可以组成一个Kafka集群 Topic Kafka根据topic对消息进行归类发布到Kafka集群的每条消息都需要指定一个Topic Producer 生产者向Broker发送消息的客户端 Consumer 消费者从Broker读取消息的客户端 ConsumerGroup 每个Consumer属于一个特定的ConsumerGroup一条消息可以被多个不同的ConsumerGroup消费但是一个ConsumerGroup中只能有一个Consumer能够消费该消息 Partition 物理上的概念一个Topic可以分为多个Partition每个Partition内部消息是有序的(类似于RocketMQ中的MessageQueue)
消息模式
单播消息 一条消息只能被某一个消费者消费类似Queue模式只需让所有消费者在同一个消费组里 多播消息 一条消息能被多个消费者消费类似于发布/订阅模式针对Kafka同一条消息只能被同一个消费组的一个消费者消费的特性要实现多播只要保证消费者属于不同消费组即可
消息传递机制 基本概念 Kafka的消息发送者和消费者通过Topic的逻辑概念进行业务沟通但是实际上所有的消息是存在服务端的Partition这样的一个数据结构当中的客户端: 包括消息生产者和消息消费者消费者组: 每个消费者可以指定一个所属的消费者组相同消费者组的消费者共同构成一个逻辑消费者组每一个消息可以被多个消费组的其中一个消费者消费一次服务端Broker: 一个Kafka服务就是一个Broker主题Topic: Topic只是一个逻辑概念一个Topic被认为是业务含义相同的一组消息客户端通过绑定Topic来生产或者消费消息分区Partition Partition是实际存储消息的组件每个Partition就是一个Queue队列结构所有消息满足先进先出的顺序保存在Partition中 Topic、Partition和Broker的关系 Kafka设计需要支持海量数据通过将数据拆分成多个Partition每个Broker只存储部分数据用来提升集群吞吐量对于每个Topic下的多个Partition只有一个leader来负责客户端请求并且遵循主备模式来应对单点故障并且提升了读取并行度Topic可以有多个Partition每个Partition是一个有序的MessageQueueMessage会被按顺序存入commitlog中对应的每个Message会存在一个唯一的标识offset对于这些消息默认保留最近一周的消息也可以通过配置进行更改存储消息的数据量也不会影响Kafka的性能 问题: 为什么要对Topic的数据进行分区存储 commitlog会受到所在机器的文件系统大小的限制分区之后可以将不同的分区放在不同的机器上相当于分布式存储理论上一个Topic可以处理任意数量的数据并且能提升并行度 每个Consumer基于自己维护在commitlog中的offset进行消费实际业务中我们可以通过指定offset进行消息重复消费、顺序逐条消费、跳过等操作并且不会影响到集群以及其它Consumer支持增加Topic的Partition数量但不支持减少
集群消费
多个Partition分布在Kafka集群中不同的Broker上每个Broker可以请求备份其它Broker上Partition的数据Kafka集群支持配置Partition备份的数量针对每个Partition都会有一个Broker起到leader的作用来进行读写请求其它作为follower进行备份来保证多副本数据与消费的一致性如果leader宕了followe中会选举一个新leader生产者 生产者将消息发送到Topic中同时负责指定某个Partition进行存放可以通过轮询进行负载均衡或关键字key进行指定通常情况下选择关键字key较多主要是为了保证具有相同key的消息能够被发送到同一个Partition从而保证消息的有序性 备注 在日志系统中可能会将日志的某个字段(如user_id)作为key以确保同一个用户的日志消息能够被发送到同一个Partition并按照发送的顺序进行消费如果不关心消息的有序性或者消息本身就没有key那么也可以不指定key让分区采用轮询的方式来选择Partition 消费者 队列模式 同一个消费组下有多个消费者但是消息只会分配给其中一个 发布/订阅模式 多个消费组下的其中一个消费者可以收到广播消息 消息有序 一个Partition同一时刻在一个消费者组下只有一个消费者进行消费从而保证消息有序消费者组下的消费者不能比一个Topic下的Partition数量多否则多出来的消费者就消费不到消息Kafka只能保证在Partition的范围内保证消息消费的局部有序性不能保证在同一个Topic下多个Partition的全局消费有序性(和RocketMQ一样只能保证局部有序不能保证全局有序)问题: 如何保证消息顺序消费 如果要保证全局有序可以将Topic的Partition数量置1将消费者组下的消费者数量也置为1但是这样影响了消费性能所以Kafka全局消费有序很少用
