Kafka快速部署以及集群优化
2021-08-04 11:13:00 4 举报AI智能生成
登录查看完整内容
如何快速部署Kafka使用教程
作者其他创作
大纲/内容
kafka
应用
1.构建实时的流数据管道，可靠地获取系统和应用程序之间的数据
2.构建实时流的应用程序，对数据流进行转换或反应
基本
Topic
Kafka将消息种子(Feed)分门别类，每一类的消息称之为一个主题(Topic).
分区
分区中的消息都被分了一个序列号，称之为偏移量(offset)，在每个分区中此偏移量都是唯一的。
Topic拥有多个分区意味着它可以不受限的处理更多的数据
分区可以作为并行处理的单元
群集中的所有Broker都可以作为Leader和Follower，但是一个Broker最多只能有一个Topic Partition的副本。Leader可被用来进行所有的读写操作。
Producer
发布消息的对象称之为主题生产者(Kafka topic producer)
Consumer
订阅消息并处理发布的消息的种子的对象称之为主题消费者(consumers)
Broker
已发布的消息保存在一组服务器中，称之为Kafka集群。集群中的每一个服务器都是一个代理(Broker). 消费者可以订阅一个或多个主题（topic），并从Broker拉数据，从而消费这些已发布的消息。
开启kafka
启动Zookeeper：bin/zookeeper-server-start.sh -daemon config/zookeeper.properties
启动Kafka 服务：bin/kafka-server-start.sh config/server.properties
创建主题：bin/kafka-topics.sh --create --zookeeper localhost:2182 --replication-factor 1 --partitions 1 --topic test
查看topic：bin/kafka-topics.sh --list --zookeeper localhost:2182
产生消息：bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
消费消息：bin/kafka-console-consumer.sh --zookeeper localhost:2182 --topic test --from-beginning
设置多个broker集群
1.为每个broker创建一个配置文件：cp config/server.properties config/server-1.properties
启动新节点：bin/kafka-server-start.sh config/server-1.properties &
创建一个新topic，把备份设置为：3：bin/kafka-topics.sh --create --zookeeper localhost:2182 --replication-factor 3 --partitions 1 --topic my-replicated-topic
查看集群：bin/kafka-topics.sh --describe --zookeeper localhost:2182 --topic my-replicated-topic
关键能力
1.发布和订阅消息
2.以容错的方式存储消息
3.在消息流发生时处理它们
四个核心
1.应用程序使用 Producer API 发布消息到1个或多个topic（主题）
2.应用程序使用 Consumer API 来订阅一个或多个topic，并处理产生的消息。
消息模型
队列
一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。
发布-订阅式
消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息
消费者组
一个发布在Topic上消息被分发给此消费者组中的一个消费者。 假如所有的消费者都在一个组中，那么这就变成了queue模型。 假如所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型。
3.应用程序使用 Streams API 充当一个流处理器，从1个或多个topic消费输入流，并生产一个输出流到1个或多个输出topic，有效地将输入流转换到输出流。
4.Connector API允许构建或运行可重复使用的生产者或消费者，将topic连接到现有的应用程序或数据系统。
分布式
分区被分布到集群中的多个服务器上，每个服务器处理它分到的分区。
根据配置每个分区还可以复制到其它服务器作为备份容错。
结构
Leader
处理此分区的所有的读写请求
follower
follower被动的复制数据。如果leader宕机，其它的一个follower会被推举为新的leader。
优化
Partitions
了解分区的数据速率，以确保提供合适的数据保存空间
数据速率决定了在给定时间内，所能保证的数据保存空间的大小
写Topic时请使用随机分区
分区在数据速率上的参差不齐难以管理
首先，“热”（有较高吞吐量）分区上的Consumer势必会比同组中的其他Consumer处理更多的消息，因此很可能会导致出现在处理上和网络上的瓶颈。
那些为具有最高数据速率的分区，所配置的最大保留空间，会导致Topic中其他分区的磁盘使用量也做相应地增长。
根据分区的Leader关系所实施的最佳均衡方案，比简单地将Leader关系分散到所有Broker上，要更为复杂。在同一Topic中，“热”分区会“承载”10倍于其他分区的权重。
Consumers
如果Consumers运行的是比Kafka 0.10还要旧的版本，那么请马上升级
调优Consumer的套接字缓冲区（socket buffers），以应对数据的高速流入
对于延迟为1毫秒或更多的高带宽的网络（如10Gbps或更高），请考虑将套接字缓冲区设置为8或16MB。
如果内存不足，也至少考虑设置为1MB。当然，也可以设置为-1，它会让底层操作系统根据网络的实际情况，去调整缓冲区的大小。
设计具有高吞吐量的Consumers，以便按需实施背压
我们应该保证系统只去处理其能力范围内的数据，而不要超负荷“消费”，进而导致进程中断“挂起”，或出现Consume group的溢出。
在Java虚拟机（JVM）中运行，Consumers应当使用固定大小的缓冲区，而且最好是使用堆外内存（off-heap）。
在JVM上运行各种Consumers时，请警惕垃圾回收对它们可能产生的影响
Producers
配置Producer，以等待各种确认
Kafka通过复制，来提供容错功能，因此单个节点的故障、或分区Leader关系的更改不会影响到系统的可用性。
如果没有用Acks来配置Producer（或称“fireand forget”）的话，则消息可能会悄然丢失。
为各个Producer配置Retries
就那些对于数据丢失零容忍的应用而言，请考虑设置为Integer.MAX_VALUE（有效且最大）。
为高吞吐量的Producer，调优缓冲区的大小
由于batch.size是按照分区设定的，而Producer的性能和内存的使用量，都可以与Topic中的分区数量相关联。因此，此处的设定值将取决于如下几个因素：
Producer数据速率
要生成的分区数；
可用的内存量。
请记住，将缓冲区调大并不总是好事，如果Producer由于某种原因而失效了，那么在堆内内存（on-heap）中的缓冲的数据量越多，其需要回收的垃圾也就越多。
检测应用程序，以跟踪诸如生成的消息数、平均消息大小、以及已使用的消息数等指标
Brokers
警惕垃圾回收对它们可能产生的影响，垃圾回收停滞的时间太长，则会产生集群掉线的风险。
在各个Brokers上，请压缩Topics所需的内存和CPU资源
日志压缩需要各个Broker上的堆栈（内存）和CPU周期都能成功地配合实现，而如果让那些失败的日志压缩数据持续增长的话，则会给Brokers分区带来风险。
通过网络吞吐量来监控Brokers
监控发向（transmit，TX）和收向（receive，RX）的流量，以及磁盘的I/O、磁盘的空间和CPU的使用率，而且容量规划是维护群集整体性能的关键步骤。
在群集的各个Brokers之间分配分区的Leader关系
Leader通常会需要大量的网络I/O资源。
Leader必须首先获取分区的数据，然后将两套副本发送给另两个Followers，进而再传输到多个需要该数据的Consumers上。
单个Leader所使用的网络I/O，至少是Follower的四倍。而且，Leader还可能需要对磁盘进行读操作，而Follower只需进行写操作。
按需修改Apache Log4j的各种属性
Kafka的Broker日志记录会耗费大量的磁盘空间，但是我们却不能完全关闭它。有时在发生事故之后，需要重建事件序列，那么Broker日志就会是我们最好的、甚至是唯一的方法。
禁用Topic的自动创建，或针对那些未被使用的Topics建立清除策略
对于那些具有持续高吞吐量的Brokers，请提供足够的内存，以避免它们从磁盘子系统中进行读操作
我们应尽可能地直接从操作系统的缓存中直接获取分区的数据。然而，这就意味着你必须确保自己的Consumers能够跟得上“节奏”，而对于那些延迟的Consumer就只能强制Broker从磁盘中读取了。
对于具有高吞吐量服务级别目标的大型群集，请考虑为Brokers的子集隔离出不同的Topic
如何确定需要隔离的Topics，则完全取决于自己的业务需要。例如，你有一些使用相同群集的联机事务处理系统。那么将每个系统的Topics隔离到不同Brokers子集中，则能够有助于限制潜在事件的影响半径。
在旧的客户端上使用新的Topic消息格式。应当代替客户端，在各个Brokers上加载额外的格式转换服务
不要错误地认为在本地主机上测试好Broker，就能代表生产环境中的真实性能了
0 条评论
回复 删除
下一页
