Kafka安装、配置与调优

最新推荐文章于 2024-09-18 10:31:28 发布
最新推荐文章于 2024-09-18 10:31:28 发布
阅读量546 收藏
点赞数
文章标签： kafka 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ywbbbbb/article/details/132193650
版权

Kafka安装

Apache Kafka Quick Start

1. 下载资源包

Apache Kafka Downloads 下载Binary资源包

Apache ZooKeeper 下载Binary资源包（不带Source Release的那个）

Apache项目发布的时候基本都会有Binary和Source两个版本， Binary是编译好的能够直接使用的，Source是未编译的源代码。 为了更快地时候，我们一般会直接下载Binary二进制包

2. 启动Zookeeper

ZooKeeper: Because Coordinating Distributed Systems is a Zoo (apache.org)
添加配置文件：注意这个后缀是cfg

vim conf/zoo.cfg

tickTime=200
dataDir=/var/lib/zookeeper
clientPort=2181

启动zookeeper

bin/zkServer.sh start

如果Macos上运行Zookeeper出现了问题，可以参考一下文章：
解决Mac上安装Zookeeper问题：FAILED TO WRITE PID - 夜深nps - 博客园 (cnblogs.com)

3. 启动Kafka

进入Kafka应用目录

# 后台运行
bin/kafka-server-start.sh -daemon config/server.properties
# 查看日志
tail -f $KAFKA_HOME/logs/zookeeper.out

Kafka服务会默认占用9092端口

4. 创建主题测试收发

使用kafka-topics.sh命令行工具创建主题

➜ bin/kafka-topics.sh --create --topic quickstart-events --bootstrap-server localhost:9092
Created topic quickstart-events.

➜ bin/kafka-topics.sh --describe --topic quickstart-events --bootstrap-server localhost:9092
Topic: quickstart-events	TopicId: 9wroEws9SkiToPXeGV9sDg	PartitionCount: 1	ReplicationFactor: 1	Configs:
	Topic: quickstart-events	Partition: 0	Leader: 0	Replicas: 0	Isr: 0

可以看出kafka-topics.sh工具的命令行格式为

kafka-topics.sh --<operatetion> --<topicName> --boostrap-server <kafkaServerHost>

使用控制台工具测试收发：


➜ bin/kafka-console-producer.sh --topic quickstart-events --bootstrap-server localhost:9092
>first event
>second event
>^C%


➜ bin/kafka-console-consumer.sh --topic quickstart-events --from-beginning --bootstrap-server localhost:9092
first event
second event

安装Kafdrop 运维面板

如果你想通过Web UI的方式来对Kafka进行运维以减少使用Kafka运维工具的记忆存储的压力。那么obsidiandynamics/kafdrop: Kafka Web UI (github.com)会是一个不错的选择其支持Jar和Docker的运行方式，只需要简单的配置即可运行。

Docker运行

为了更快的部署Kafdrop，我们可以通过Docker快速构建：

docker run -d --rm -p 9000:9000 \
    -e KAFKA_BROKERCONNECT=host.docker.internal:9092 \
    -e JVM_OPTS="-Xms32M -Xmx64M" \
    -e SERVER_SERVLET_CONTEXTPATH="/" \
    obsidiandynamics/kafdrop

你可以通过host.docker.internal地址将主机的IP地址映射至docker容器中

随后Kafdrop会运行在9000端口，我们可以在浏览器中访问，它看起来像这样：
请添加图片描述

基本配置

Broker

broekr.id 任何broker都需要指定一个集群内部唯一的、整型的标识符。 默认配置下这个值为0。

port Kafka服务器占用端口，默认为9092。这个值可以被设置为任意可用的端口，但是如果低于1024，Kafka必须通过root身份进行启动，这并不是一个推荐的配置方式。

zookeeper.connect连接ZK的地址，默认值为2181，可以通过hostname:port/path的格式来着指定，如果不指定path则默认为/根目录。
如果你的ZK集群除了Kafka还被其他应用所使用，那么指定/path能够保证数据不会冲突。

log.dirs Kafka中Broker数据（包括消息、偏移量等）的存储位置，默认为/tmp/kafka-logs。可以通过,逗号分割多个文件路径，而Broker会将新的分区方在多个路径中最少存储分区的那个路径下，并且能够保证同一个分区的数据总是会放入同一个文件路径。

num.recovery.threads.per.data.dir Kafka中用于打开每一个目录下的分区日志文件的线程数量。

  • 当Kafka正常启动时，用于打开每个线程的日志文件

  • 当Kafka启动失败时，用于检查和阶段日志文件

  • 当Kafka关闭时，用于关闭日志文件。
    这个配置仅用于Kafka刚启动和关闭阶段用于文件的打开和关闭，所以理论上将其配置的更大一点以保证多个线程并行操作是合理的。
    当从异常关闭的Broker中进行回复时，这意味重新启动Broker可能需要较长的时间。
    线程数量是对于一个文件路径而言的，如果设置了3个文件存储路径，并且将这个线程数来那个设置为8，那么Kafka总共会启动24个线程。

  • auto.create.topics.enable当任何客户端访问某一个不存在的主题时，是否允许Broker自动创建主题。
    这个配置会可能会引发非预期的行为，所以尽可能的保证这个配置项是关闭的。

Topic默认配置项

Kafka的服务器（Broker）配置还能够为主题的创建指定许多默认的配置。其中包括一些较为重要的分区数和消息保留。 服务器应该将其中的配置项设置为基线值，以适应大多数主题。

  • num.partitions分区数量，默认值为1。主题的分区数量可以通过管理工具进行增加，但是注意，分区数量不能减少。 如果想要手动创建比默认设置更少的分区数，那么可以在通过kafka-topics工具手动指定分区数量。

分区数量是Kafka集群能够横向扩展的具体已实现，使用更多分区数量能够在集群中新增更多的的Broker时进行负载均衡。

尽可能的保证Partition分区数量等于或者是倍数于Broker的数量。使得Partition分区能够均衡的负载在每一个Broker上。 这并不是一个必须的选项，你也可以通过创建多个Topic来平衡消息的负载。

分区数量的设置是Kafka使用者面临的一个关键点，以下是影响分区数量的选择的几个重要因素：

  1. 你期望Topic达到多少的吞吐量？ 100KB/s还是1GB/s？
  2. 你期望消费单个分区的最大吞吐量是多少？你总是至少一个消费者从分区中读取数据。 如果你的消费者消费速度较慢，比如说需要将数据写入DB，那么DB的写入速度限制这你的消费者速度。（也就是说要考虑到单个分区的吞吐量是否和消费者的消费速度相匹配）。
  3. 同样，你期望生产者的最大吞吐量是多少？通常情况下生产者的生产速度会比消费者要快，
  4. 如果你需要使用Keys来指定消息存放的分区，那么在创建主题的时候就基于未来的使用率，而不是当前的使用率。（这样就能够避免未来需要增加分区数量，进而导致同样Key的新消息和旧消息不再存放于同一个分区上。）
  5. 考虑到磁盘的可用空间和网络的带宽。
  6. 要避免过度高估分区的数量，因为每个分区都会占用Broker上的资源，以及增加Leader的选举时间。

  • log.retention.ms/hours/minutes
    这是三个参数，都表示着日志的过期时间，默认情况下这个参数为168hours，也就是7天。 如果三个参数都指定了，那么kafka只会保证最小的时间单位的配置项生效，所以推荐使用ms作为配置。

    过期时间是根据消息的最后修改时间决定的，正常情况下这就是消息被消费的时间。但是当使用管理工具修改了分区数量，可能会导致分区消息的最后修改时间变更，进而产生非预期的行为。

  • log.retention.bytes
    一个分区中的日志保留的大小，当分区下的日志文件超过这个大小的时候，超过这个大小的日志文件会被清除。 注意这是一个分区中的大小，意味着一个主题的日志的大小取决于这个值 * 分区数量，并且也会随着分区数量的增加而增加。

    log.rentention.bytes和ms 基于时间和大小的两个策略是“或”的逻辑运算。 也就是当日志文件只要超过了时间点或者是大小，那么其就会被清除。

  • log.segement.bytes
    分区中一个日志文件（日志段这个概念可能会有些不好理解）的大小，默认值为1GB。一个日志文件包含着当前分区中的一段连续的日志，当达到文件大小上限之后关闭，创建出一个新的日志文件。

    减少日志文件的大小，意味着文件会更加频繁的关闭和创建，会减少整个磁盘的写入效率。 但是当主题有着较低的生产效率时，减少日志的文件的大小，却变得十分重要，因为log.retention的两个策略仅对于关闭的日志文件生效。

    假设一个文件的写入效率为100M每天，而log.retention.ms使用了默认值七天，这意味着消息文件在达到第7天的时候，会由于日志还未关闭，进而无法按预期被删除。而仅仅在第十天消息日志文件中的日志达到了上限，进而关闭该文件，随后打开新的日志文件时。这个本应该过期的日志文件才会被删除。

  • log.segement.ms
    由时间控制的日志文件的关闭策略，同retention一样，两者策略之间是“或”的逻辑运算。

    使用log.segement.ms时，如果多个分区的日志文件总是由于时间问题被同时关闭和创建，那么可能会产生磁盘的突刺，从而影响磁盘的性能。

  • message.max.bytes
    消息的最大字节数，默认值为1MB，当生产者发送超过了这个大小的消息时，Broker会返回一个错误。
    注意这个参数需要和消费者客户端的fetch.message.max.bytes以及Broker端的replica.fetch.max.bytes配置保持一致。否则，会导致消息的拉取无法获得完整的消息数据。

硬件选择

一个应用绕不开底层硬件的依赖，而影响应用性能的核心无外乎硬盘、内存、网络和CPU四个核心硬件。

磁盘

生产者的性能会直接的影响到Broker的磁盘吞吐量，因为只有当Broker将消息写入磁盘时，一个消息才能够被视为真正被生产出来。而生产者客户端会等待直至消息成功写入，才会响应成功。这意味着更快的磁盘写入能够有更低的生产者写入延迟。

这就是来到了经典的SSD和HHD的抉择。即使Kafka对于消息的写入是顺序写的，能够很大的利用磁盘的特性。但使用SSD磁盘总是要比HHD的性能更好；如果Kafka对于存储的容量有要求（比如说一天流量为1TB，而消息过期策略为7天，那么至少磁盘要有7TB的空间）。那么采用机械硬盘是更加经济的选择。

磁盘还和Broker中的Retention过期配置相关，你想要保留的日志时间越长、日志体积越大，那么你就应该需要越多的磁盘空间。

内存

内存影响着消费者的消费速度，正常情况下生产者的消息追加到Broker之后会立即的被消费者消费，生产者和消费者之间的消息进度差异十分的小。 这种情况下，Broker会将消息存储在系统的PageCache页缓存中，使得消费者的读取速度比Broker从磁盘中重新读取消息更快。 因此提供更多的内存空间用于页缓存将提高客户端的性能。

需要注意的是操作系统的PageCache页缓存会在多个应用程序之间共享，所以不推荐的将Kafka与其他的重要应用部署在同一台机器上。

网络

每当一个消息从生产者中通过网络入站连接至Broker写入数据， 可能会产生N个消费者的出站连接用于消息的消费。 一个生产者可能产生1MB的数入站据每秒，那么消费者可能消费nMB的出战数据每秒。

同样为了保证Kafka数据的高可用，其他Kafka应用级别的操作也会占用网络带宽，比如说集群复制。
当网络的带宽被生产和消费打满时，集群复制的滞后会变成一个十分常见的问题。

  • 所以每当发生集群复制滞后时，你就需要检查是否网络带宽一直处于占满的状态。

CPU

CPU在Kafka中仅用于消息的压缩，理想情况下，生产者和消费者今天当消息压缩后从发送至Broker能够减少磁盘和网络的占用。 但是为了校验消息中的checksum校验和以及分配消息的offset偏移量，Kafka需要在接收到来自生产中的压缩消息后，将其解压出来进行操作。校验无误后，然后再压缩存入磁盘。 这是Kafka中对于CPU有所要求的地方。

但是CPU不应该是Kafka选择硬件的主要因素，优先考虑磁盘和内存。

OS调优

Linux的众多发行版中都有能够对内核参数进行配置。 默认配置会对绝大多数的应用都工作的很好，但是依然有一小部分的配置项更改能够使得kafka broker具有更好的性能。

虚拟内存

虚拟内存优化的核心点在于避免内存交换(memory swapping)的成本。kafka是一个重度依赖于虚拟内存和页缓存的应用，如果虚拟内存页交换到磁盘，那么将会显著的影响到Kafka的性能。
交换空间能够防止OS由于内存不足而突然禁止进程。

关于虚拟内存的优秀文章：
Linux虚拟内存（swap）调优篇-“swappiness”,“vm.dirty_background_ratio”和“vm.dirty_ratio” - 尹正杰 - 博客园 (cnblogs.com)

使用虚拟内存会导致数据频繁的从内存写入磁盘，导致性能的下降。而通过配置项
vm.swappiness = 1 能够使得操作系统尽可能的不使用交换内存，而是使用真实物理内存。
查看当前配置

cat /proc/sys/vm/swappiness

临时修改配置

sysctl vw.swappiness=1

永久修改配置

echo "vm.swappiness=1" >> /etc/sysctl.conf

激活设置

sysctl -p

脏页Dirty Page

脏页是Linux内核中的概念，因为磁盘中的读写速度远赶不上内存的速度，所以系统可以将读写频繁的数据先放到内存中，这就叫高速缓存。而Linux中页是高速缓存的单位，当进程应用修改了高速缓存中的页数据时，该内存就会被标记为脏页（因为内存中的数据和磁盘中不一致），直至合适的时候将脏页的数据写入磁盘，以保持高速缓存中的数据和磁盘的一致。

Linux中提供了两个参数用于调整脏页的处理方式

  1. vm.dirty_background_ratio表示当前脏页所占内存比例达到多少时，Linux会启动后台会写线程，来将脏页异步的写回磁盘。 这个参数的默认值为10，而将其设置为5能够适用于绝大部分应用；
  2. vm.dirty_ratio 表示当脏页占内存比例达到多少时，Linux会阻塞直到脏页被写回磁盘。这个参数的默认值为20，但是我们可以将其设置为更大的值，60~80是一个合理的选择，但是这会带来一些风险，包括未刷新磁盘的数量和同步刷新引起的长时间I/O等待。 如果设置了较高的值，建议开启Kafka的复制功能，以防止系统崩溃造成数据丢失。

设置这两个参数前，你可以先观察当前操作系统的脏页数量，以调优至一个合理的值

cat /proc/vmstat | egrep "dirty|writeback"

磁盘文件系统

除了磁盘硬件的选择，Linux上的文件系统也影响着进程的性能。 目前有许多文件系统可供选择，最常见的两个就是EXT4（Fourth Extended File System）和XFS（Extends File System）。 XFS已经变成许多Linux发行版的默认文件系统了，因为其更适用于绝大多数的场景。

而EXT4在经过一些参数的调整之后能够表现得更好。

还有一个Linux参数会影响着磁盘的效率，那就是开启noatime选项，在文件系统的元数据中包含了三个时间戳：创建时间（ctime）、修改时间（mtime）和访问时间（atime）。前两者仅在文件被创建和修改的时候所变更，但接触时间不一样，每一次对文件的访问，不论是否修改了数据都会导致atime的变更。而atime的实际作用却并不大，很少有场景会使用它。
所以禁用atime是一个明智的选择。

网络Networking

调整Linux的默认网络参数是一个使得任何应用程序产生更高网络流量的常见手段。因为默认的Linux参数并不是为了大体量、高速数据传输而设置的。
在这一步的设置除了kafka，也是由于大多数的Web应用程序。

  • net.core.wmem_default和net.core.rmem_default控制着套接字发送和接收缓冲区大小，建议设置为131072（128K）是一个较为合理的数值。

  • net.core.wmem_max和net.core.rmem_max控制着套接字发送和接收缓冲区的最大大小，设置为2097152（2MB）是一个较为合理的数值。

  • 另外要控制TCP套接字的缓存区大小还需要额外通过ipv4.tcp_w/rmem来进行配置，其接受由空格隔开的由三个数值。建议将其设置为4096 65536 2048000其意味着缓冲区的最小、默认和最大大小为4KB、64KB和2MB。 注意这个参数不应该超过net.core.w/rmem_max所设定的值。

  • 还有一个十分有用的TCP调优参数net.ipv4.tcp_window_scaling=1。 能够使得客户端数据传输得更加有效率。允许数据在Broker端传输。

另外设置tcp_max_syn_backlog大于默认的1024能够使得LInux接受更大数量的并发连接。net.core.netdev_max_max_backlog大于默认的1000能够应对网络流量的突发，允许更多的流量包在内核排队等待处理。

G1 JVM垃圾收集器

G1垃圾收集器已经在JDK11之后的多个版本中被设置为了默认垃圾收集器，并且在生产环境中得到了稳定的保证。

在G1垃圾收集器中有两个参数影响着其垃圾收集的性能，分别为

  • MaxGCPausMills：预期的最大GC停顿时间，G1能够保证尽可能的使得每次垃圾回收都接近这个数值，默认为200。而Kafka对于堆内存的使用十分的高效，所以我们能够将其设置在20，以保证GC停顿不影响到Kafka正常的工作。
  • InitiatingHeapOccupancyPercent：初始GC时内存占用的百分比，默认值为45，也意味着只有当JVM的堆内存占用达到45%的时候，G1收集器才会开始第一次GC。而我们可以将其设置得更低一点，比如说35。

但Kafka中默认使用的JDK8中，使用的是CMS + Parnew。而G1垃圾收集器会有有着比CMS更高的内存占用，所以在切换Kafka的垃圾收集器前，先确保Kafka的堆内存至少能够分配4GB的大小，否则或许使用CMS能够以更低的内存开销获得更高的性能。

要想使得Kafka更换垃圾收集器，我们可以设置环境变量KAFKA_JVM_PERFORMANCE_OPTS

# export KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC -XX:MaxGCPauseMills=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true"

# bin/kafka-server-start.sh -daemon config/server.properties

Zookeeper

Kafka使用Zookeeper来存储自身的元数据包括Brokers、Topics和Partitions。 Kafka仅当集群自身发生调整时或者是Consumer Group的关系发生了变化时会对Zookeeper进行写入。 所以Kafka对于Zookeeper的流量占用是较小的。

所以我们能够使用一个Zookeeper集群来治理多个Kafka集群，并且通过Zookeeper的chroot path来隔离每一个Kafka集群中的数据。

前面提到了Consumer Group会对Kafka造成写入，Consumer消费者能够配置使用Zookeeper或者是Kafka来提交自身的消费便宜来那个。如果选择了Zookeeper，那么每一个Consumer会对他所消费的分区的偏移量对Zookeeper进行一次写入操作。这会对Zookeeper产生相当大的流量。 所以推荐的做法是使用Kafka Broker本身来提交偏移量从而消除对Zookeeper的依赖。

另外不建议将使用一个Zookeeper集群来同时管理Kafka集群和其他应用。因为当其他应用对Zookeeper产生了较大的流量时，可能会影响Kafka集群自身的治理，进而导致Kafka集群的所有Broker节点由于丢失了Zookeeper的连接导致同时下线。

ShityCode
关注
Kafka 之 Topic 配置
流华追梦的专栏
02-17 1025
Topic 就是数据主题，一个逻辑概念，可以用来区分业务系统。Kafka 中的 Topic 总是多订阅者模式，一个 Topic 可以拥有一个或者多个消费者来订阅它的数据。Topic 下的数据会被进一步分配到分区（Partition）中，Partition 是最小的存储单元，掌握着一个 Topic 的部分数据。每个 Partition 都是一个单独的 log 文件，每条记录（消息）都以追加的形式写入。事件被组织并持久地存储在 Topic 中，Topic 类似于文件系统中的文件夹，事件就是该文件夹中的文件。
Kafka配置详解-Topic配置
zqqcometo的专栏
12-19 3096
转载自：http://orchome.com/669 3.2 Topic配置 与topic相关的配置，服务器的默认值，也可可选择的覆盖指定的topic。如果没有给出指定topic的配置，则将使用服务器默认值。 可以通过-config选项在topic创建时设置。此示例使用自定义最大消息的大小和刷新率，创建一个名为my-topic的topic： &gt; bin/kafka-...
Kafka 下载安装及使用总结
最新发布
凡的博客
09-18 874
Kafka 下载安装及使用总结
Kafka：硬件配置选择和调优
程序员无羡的博客
04-03 1560
Kafka：硬件配置选择和调优
kafka topic配置(超详细的核心配置项说明)
巨魔战将
10-21 7957
topic核心配置 num.partitions 分区数量 设置策略 评估单分区吞吐量，考虑总的吞吐量 考虑消费者个数 可用的空间和贷款 分区大小限制 log.retention.ms topic数据保留时长 默认通过log.retention.hours配置时间，默认值为168小时，也就是7天 等同 log.retentions.hours log.reten...
【kafka系列教程43】kafka生产服务器配置
dcm19920115的博客
06-28 448
生产者服务器配置 Here is our server production server configuration: 这是我们的服务器生产服务器配置: # Replication configurations num.replica.fetchers=4 replica.fetch.max.bytes=1048576 replica.fetch.wait.max.ms=500 re...
kafka配置调优实践
11-12
Kafka 配置调优实践 Kafka 配置调优实践是指通过调整 Kafka 集群的参数配置来提高其吞吐性能。下面是 Kafka 配置调优实践的知识点总结： 一、存储优化 * 数据目录优先存储到 XFS 文件系统或者 EXT4，避免使用 EXT...
kafka集群生产性能调优业务场景
将臣三代的博客
06-24 407
Kafka 集群生产性能调优需要综合考虑硬件配置、Kafka 配置参数、客户端配置、操作系统和网络配置等多个方面。根据具硬件配置：使用高性能硬件，提高内存和 CPU 配置。Kafka 配置：优化日志配置、生产者配置、复制和分区配置。客户端配置：调整生产者的批量发送、压缩、确认机制等参数。操作系统和网络配置：优化文件描述符、页面缓存和网络设置。通过综合应用这些调优策略，可以显著提高 Kafka 集群的生产性能，满足高吞吐量、高可靠性等不同业务需求。
kafka配置调优1
08-08
【Kafka配置调优详解】 Kafka是一款高吞吐、分布式的流处理平台，它用于构建实时数据管道和流应用。在大型分布式系统中，为了保证高效稳定运行，对Kafka进行配置调优至关重要。本篇文章将深入解析Kafka的核心配置...
Kafka集群管理——配置与调优
m0_57983600的博客
06-13 333
集群是一种计算机系统， 它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机，比如工作站或超级计算机性能价格比要高得多。 集群的特点 集群拥有以下两个特点： 可扩展性：集群的性能不限制于单一的服务实体，新的服务实体可以动态的添加到集群，从而增强集群的性能。 高可用性：集群当
kafka中文文档topic配置参数
05-05
NULL 博文链接：https://bewithme.iteye.com/blog/2395202
kafka服务端常用配置
学无止境
11-09 635
toc 参数配置：config/server.properties zookeeper.connect 指明Zookeeper主机地址，如果zookeeper是集群则以逗号隔开，如： 172.6.14.61:2181,172.6.14.62:2181,172.6.14.63:2181 eg: zookeeper.connect=localhost:2181 (kafuka和zookeeper在同一台服务器上部署) listeners 监听列表，broker对外提供服务时绑定的IP和端口。 多个以逗号隔开，
Kafka学习笔记 --- Kafka服务端配置
杨鑫newlife的专栏
09-30 282
1.重要的客户端配置 Producer生产者最重要的三个配置： acks compression batch size 这最重要的是访问的大小。 下面是一个producer生产者server服务端的配置文件 # ZooKeeper zookeeper.connect=[list of ZooKeeper servers] # Log configuration ...
kafka topic配置(四)
XinhuaShuDiao的博客
02-09 1623
前面我们了解完broker的配置，现在我们来看下topic的配置： 1.cleanup.policy 字符串要么是“delete”，要么是“compact”，或者两者都是。此配置指定在旧日志段上使用的保留策略。默认策略(“delete”)将在达到保留时间或大小限制时丢弃旧段。“compact”设置将启用topic上的日志压缩。服务器提供的默认配置是log.cleanup.policy。 2.compression.type 指定给定topic的最终压缩类型。该配置接受标准的压缩编解码器('gzip'、'
Kafka中Topic级别配置
紫蝶侠的博客
05-18 436
Kafka中Topic级别配置
kafka服务器硬件配置选择与优化
c18802081049的博客
06-22 1830
磁盘吞吐量（重要，影响生产者）磁盘容量（制约集群规模) 生产者客户端的性能直接受到服务器端磁盘吞吐量的影响。 需要多大的磁盘容量取决于需要保留的消息数量，也需要考虑集群复制策略的影响。磁盘类型和容量规划 1.磁盘类型 HDD VS SSD 机械磁盘（HDD） 一般机械磁盘寻道时间是毫秒级的，若有大量随机I/O，则将会出现指数级的延迟，但是kafka是顺序读写的，因此对于机械磁盘的性能也是不弱的，所以，基于成本问题可以考虑。 固态硬盘（SSD） 读写速度可观，没有成本问题可以考虑。 JBOD VS RAID1
【kafka】Kafka中Topic级别配置
九师兄
04-22 613
1.概述 Kafka中topic级别配置 1.1 Topic级别配置 配置topic级别参数时，相同(参数)属性topic级别会覆盖全局的，否则默认为全局配置属性值。 创建topic参数可以设置一个或多个--config "Property(属性)",下面是创建一个topic名称为"my-topic"例子，它设置了2个参数max message size 和 flush rate. (A) 创建topic时配置参数 bin/kafka-topics.sh --zookeeper 192.168.2.225:
服务器最全安装、配置、启动Kafka集群
hellowangxiansheng的博客
04-11 778
（10）由于slave2节点也需要安装 kafka，因此可以先将master节点的 /opt/kafka 文件和 /etc/profile 文件拷贝到slave2的相同路径下。（9）由于slave1节点也需要安装 kafka，因此可以先将master节点的 /opt/kafka 文件和 /etc/profile 文件拷贝到slave1的相同路径下。（3）解压 kafka 文件到当前目录（/opt）下面，使用相对路径或者绝对路径均可，下面的命令使用绝对路径。（1）切换到 /opt 目录下。
Kafka集群调优与分布式搭建实战教程
1. **Kafka Java Consumer实战**：这部分内容将教你如何使用Java API与Kafka消费者进行交互，包括订阅主题、处理消息、配置消费者参数以及实现消费组等。 2. **Kafka集成框架**：Kafka通常与其他系统如Hadoop、...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值