Kafka学习笔记

1.Kafka简介
Apache Kafka是一款开源的消息引擎系统。维基百科的定义,消息引擎系统是一组规范。企业利用这组规范在不同系统之间传递语义准确的消息,实现松耦合的异步式数据传递。通俗来讲,就是系统A发送消息给消息引擎系统,系统B从消息引擎系统中读取A发送的消息。

消息引擎系统要设定具体的传输协议,即我用什么方法把消息传输出去,常见的方法有2种:点对点模消息引擎系统要设定具体的传输协议,即用什么方法把消息传输出去,常见的方法有2种:点对点模型;发布/订阅模型。

Kafka同时支持这两种消息引擎模型。系统A不能直接发送消息给系统B,中间还要隔一个
消息引擎呢,是为了“削峰填谷”。例如:Kafka 能够将瞬时增加的订单流量全部以消息形式保存在对应的主题中,既不影响上游服务的 TPS,同时也给下游子服务留出了充足的时间去消费它们(上游可以比作是点击支付事件,下游是调用支付api)。

kafka术语
kafka主要功能是提供一套完备的消息发布与订阅解决方案

发布订阅的对象是主题(Topic)

向主题发布消息的客户端应用程序称为生产者(Producer)
订阅这些主题消息的客户端应用程序就被称为消费者
生产者和消费者统称为客户端(Clients)

Kafka 的服务器端由被称为 Broker,Broker负责接收和处理客户端发送过来的请求,以及对消息进行持久化。

  • kafka将Broker 分散运行在不同的机器上,这样如果集群中某一台机器宕机,即使在它上面运行的所有 Broker 进程都挂掉了,其他机器上的 Broker 也依然能够对外提供服务。这其实就是 Kafka 提供高可用的手段之一。

数据备份,把相同的数据拷贝到多台机器上,而这些相同的数据拷贝在 Kafka 中被称为副本(Replica)。

Kafka 定义了两类副本:领导者副本(Leader Replica)和追随者副本(Follower Replica)
前者对外提供服务,这里的对外指的是与客户端程序进行交互;而后者只是被动地追随领导者副本而已,不能与外界进行交互。

副本的工作机制:生产者总是向领导者副本写消息;而消费者总是从领导者副本读消息。追随者副本:向领导者副本发送请求,请求领导者把最新生产的消息发给它,这样它能保持与领导者的同步。
倘若领导者副本积累了太多的数据以至于单台 Broker 机器都无法容纳了,就会分区(Partitioning):把数据分割成多份保存在不同的 Broker 上,这样解决伸缩性的问题。

Kafka Broker 持久化数据,消息日志(Log)来保存数据,只能追加写入,这也是实现 Kafka 高吞吐量特性的一个重要手段。通过日志段(Log Segment)机制,定期地删除日志消息以回收磁盘。

重平衡(Rebalance),假设组内某个实例挂掉了,Kafka 自动检测到,然后把这个 Failed 实例之前负责的分区转移给其他活着的消费者。
在这里插入图片描述
kafka用途
Apache Kafka 是消息引擎系统,也是一个分布式流处理平台

  • 提供一套 API 实现生产者和消费者;
  • 降低网络传输和磁盘存储开销;
  • 实现高伸缩性架构。

集群参数配置
Broker的配置

  1. 存储信息:
  • log.dirs:指定了 Broker 需要使用的若干个文件目录路径,比如/home/kafka1,/home/kafka2,/home/kafka3这样
  1. ZooKeeper,分布式协调框架(比如集群都有哪些 Broker 在运行、创建了哪些 Topic,每个 Topic 都有多少分区以及这些分区的 Leader 副本都在哪些机器上等信息),例如zk1:2181,zk2:2181,zk3:2181/kafka1
  2. Broker 连接相关
  • listeners:可以配置内网IP
  • advertised.listeners:主要是为外网访问用的,例如listener.security.protocol.map=CONTROLLER:PLAINTEXT
  • host.name/port:
  1. 第四组参数是关于 Topic 管理的。三个参数,一般都设为false:
  • auto.create.topics.enable:是否允许自动创建 Topic
  • unclean.leader.election.enable:是否允许 Unclean Leader 选举
  • auto.leader.rebalance.enable:是否允许定期进行 Leader 选举
  1. 数据留存方面
  • log.retention.{hours|minutes|ms},控制一条消息数据被保存多长时间,hours=168
  • log.retention.bytes:这是指定 Broker 为消息保存的总磁盘容量大小,这个值默认是 -1,表示无限制
  • message.max.bytes:控制 Broker 能够接收的最大消息大小,默认 1000012=976KB

Topic 级别参数
Topic参数优先级大于Broker

  • retention.ms:规定了该 Topic消息被保存的时长,默认是 7 天,设置了这个值,会覆盖掉 Broker端的全局参数值。
  • retention.bytes:规定了要为该 Topic 预留多大的磁盘空间。当前默认值是 -1,表示可以无限使用磁盘空间。

建议将 JVM 堆大小设置成 6GB

生产者消息分区机制
作用就是提供负载均衡和伸缩性,不同的分区能够被放置到不同节点的机器上,而数据的读写操作也都是针对分区这个粒度而进行的,这样每个节点的机器都能独立地执行各自分区的读写请求处理。并且,我们还可以通过添加新的节点机器来增加整体系统的吞吐量。
分区除了提供负载均衡这种最核心的功能之外,利用分区也可以实现其他一些业务级别的需求,比如实现业务级别的消息顺序的问题

1.自定义分区策略

int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);

2.轮询策略
有非常优秀的负载均衡表现,它总是能保证消息最大限度地被平均分配到所有分区上,默认情况下它是最合理的分区策略,常用的分区策略之一。
在这里插入图片描述
3.随机策略
老版本用,性能不如轮询
在这里插入图片描述
4.按消息键保序策略
Kafka 允许为每条消息定义消息键,简称为 Key
在这里插入图片描述
实现代码

List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
return Math.abs(key.hashCode()) % partitions.size();

5.按地理位置分区策略
针对大规模kafka集群,跨城市、跨国家

生产者压缩算法
kafka压缩发生在:生产者端和Broker端

Kafka 共有两大类消息格式,社区分别称之为 ==V1 版本和 V2 ==版本。V2 版本是 Kafka 0.11.0.0 中正式引入的。

v2就是把消息的公共部分抽取出来放到外层消息集合里面,这样就不用每条消息都保存这些信息了。

V1版本每条消息执行CRC校验

无消息丢失配置
Kafka 只对“已提交”的消息(committed message)做有限度的持久化保证。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值