kafka总结

最新推荐文章于 2024-04-25 23:21:49 发布

W1ngLLL

最新推荐文章于 2024-04-25 23:21:49 发布

阅读量578

点赞数

分类专栏： kafka-c 文章标签： kafka

本文链接：https://blog.csdn.net/W1ngLLL/article/details/77507299

版权

kafka-c 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

kafka总结（新手）

基本概念

通信： 各组件通过TCP进行通信，确保集群中的各台机器相互连通。

Topic: 主题，每条发布到kafka集群的消息属于的类别，即kafka是面向topic的。

Broker: kafka的服务器，每部署一台kafka就是一个broker。

Producer & Consumer: 生产者和消费者。一般消息系统都有生产者和消费者的概念。生产者产生消息，即把消息放入Topic中，而消费者则从Topic中获取消息处理。一个生产者可以向多个Topic发送消息，一个消费者也可以同时从几个Topic接收消息。同样的，一个Topic也可以被多个消费者来接收消息。

Offset: 偏移量，消息在各自partition中唯一的ID

Partition: 分区，或者说分组。分组是Kafka提升吞吐量的一个关键设计。这样可以让消费者多线程并行接收消息。创建Topic时可指定Parition数量。一个Topic可以分为多个Partition，也可以只有一个Partition。每一个Partition是一个有序的，不可变的消息序列。每一个消息在各自的Partition中有唯一的ID。这些ID是有序的。称之为offset，offset在不同的Partition中是可以重复的，但是在一个Partition中是不可能重复的。越大的offset的消息是最新的。Kafka只保证在每个Partition中的消息是有序的，就会带来一个问题，即如果一个Consumer在不同的Partition中获取消息，那么消息的顺序也许是和Producer发送到Kafka中的消息的顺序是不一致的。kafka 分配的单位是 partition。

Consumer group: 每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 中的一个 Consumer 消费，但可以被多个 consumer group 消费。如果Consume的线程个数大于partition的个数，则会出现消费者空闲的情况。

replica: 副本，partition 的副本，保障 partition 的高可用。

leader & follower: 在一个集群中，只有一个leader，可以有多个follower。

Zookeeper： Kafka的运行依赖于Zookeeper。Topic、Consumer、Patition、Broker等注册信息都存储在ZooKeeper中。

特性

高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒

可扩展性：kafka集群支持热扩展

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失

容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）

高并发：支持数千个客户端同时读写

设计思想

consumegroup：消费者可以组成一个组，每条消息只能够被同组的一个消费者消费，如果一条消息想被多个消费者消费的话，消费者必须在不同的组中。

消息状态：在kafka中，消息的状态保存在消费者中，broker不关心消息被哪个消费者消费了，只会记录offset的值。

消息持久化：Kafka中会把消息持久化到本地文件系统中，并且保持极高的效率。

消息有效期：Kafka会长久保留其中的消息，以便consumer可以多次消费，当然其中很多细节是可配置的。

批量发送：Kafka支持以消息集合为单位进行批量发送，以提高push效率。

push-and-pull :Kafka中的Producer和consumer采用的是push-and-pull模式，即Producer只管向broker push消息，consumer只管从broker pull消息，两者对消息的生产和消费是异步的。

Kafka集群中broker之间的关系：是主从关系，各个broker在集群中地位一样，我们可以随意的增加或删除任何一个broker节点。

负载均衡方面： Kafka提供了一个 metadata API来管理broker之间的负载（对Kafka0.8.x而言，对于0.7.x主要靠zookeeper来实现负载均衡）。

同步异步：Producer采用异步push方式，极大提高Kafka系统的吞吐率（可以通过参数控制是采用同步还是异步方式）。

分区机制partition：Kafka的broker端支持消息分区，Producer可以决定把消息发到哪个分区，在一个分区中消息的顺序就是Producer发送消息的顺序，一个主题中可以有多个分区，具体分区的数量是可配置的。分区的意义很重大，后面的内容会逐渐体现。

离线数据装载：Kafka由于对可拓展的数据持久化的支持，它也非常适合向Hadoop或者数据仓库中进行数据装载。

插件支持：现在不少活跃的社区已经开发出不少插件来拓展Kafka的功能，如用来配合Storm、Hadoop、flume相关的插件。

架构组件

Kafka中发布订阅的对象是topic。我们可以为每类数据创建一个topic，把向topic发布消息的客户端称作producer，从topic订阅消息的客户端称作consumer。Producers和consumers可以同时从多个topic读写数据。一个kafka集群由一个或多个broker服务器组成，它负责持久化和备份具体的kafka消息。

topic：消息存放的目录即主题

Producer：生产消息到topic的一方（发送消息的一方）

Consumer：订阅topic消费消息的一方（接收处理消息的一方）

Broker：Kafka的服务实例就是一个broker

Topic&Partition

消息发送时都被发送到一个topic，其本质就是一个目录，而topic由是由一些Partition Logs(分区日志)组成,其组织结构如下图所示：

每个partition中的消息都是有顺序的，每条消息都又自己的offset

Kafka集群会保存所有的消息，不管消息有没有被消费；
我们可以设定消息的过期时间，只有过期的数据才会被自动清除以释放磁盘空间。比如我们设置消息过期时间为2天，那么这2天内的所有消息都会被保存到集群中，数据只有超过了两天才会被清除。

Kafka需要维持的元数据只有一个–消费消息在Partition中的offset值，Consumer每消费一个消息，offset就会加1。其实消息的状态完全是由Consumer控制的，Consumer可以跟踪和重设这个offset值，这样的话Consumer就可以读取任意位置的消息。

把消息日志以Partition的形式存放有多重考虑，第一，方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；第二就是可以提高并发，因为可以以Partition为单位读写了。

zookeeper的作用

kafka将元数据信息保存到了zookeeper中，但是发送给topic的数据是不保存到zookeeper的。kafka使用zookeeper实现动态集群的扩展，不需要更改生产者和消费者的配置，broker会在zookeeper中注册并保持相关的元数据。其中记录着Topic/Partion与broker的映射关系：每一个Topic的每一个Partion，得知道其对应的broker列表是什么，其中leader是谁，follower是谁。

Zookeeper 主要用来跟踪Kafka 集群中的节点状态, 以及Kafka Topic, message 等等其他信息. 同时, Kafka 依赖于Zookeeper, 没有Zookeeper 是不能运行起来Kafka 的.

Controller 选举:

Controller 是一个特殊的Broker, 其负责所有Partition 的leader/follower 关系.

Zookeeper 负责从Broker 中选举出一个作为Controller, 并确保其唯一性. 同时, 当Controller 宕机时, 选举一个新的.

集群 membership:

记录集群中都有哪些活跃着的Broker.

Topic 配置:

有哪些Topic, Topic 都有哪些Partition, Replica 存放在哪里, Leader 是谁.

配额(0.9.0+):

记录每个客户能够读写的数据量.

ACLs(0.9.0+):

记录对Topic 的读写控制.

high-level consumer(已废弃):

记录consumer group 及其成员和offset 信息.

PS: 在运行过程中, 如果先关闭掉了Zookeeper, 然后再去关闭Kafka, 会发现Kafka 后台一直结束不掉, 这是因为Kafka 会被block 在与Zookeeper 的重连过程中. 解决方法是重启Zookeeper , 然后先关闭Kafka 再关闭Zookeeper.

zookeeper环境搭建

首先，确保安装了jdk

将下载的zookeeper解压
zookeeper下载地址

配置zoo.cfg文件，配置项及配置示例如下所示。

注：配置文件中的“=”符号后不要有空格

修改完成zoo.cfg文件后再dataDir配置的目录下创建myid文件，文件中只需写在server.XXX部分填写的XXX即可。myid文件中的内容和集群中其他机器填写的不能相同。
创建完成之后启动，验证。

如果启动出现

java.io.IOException:Connection reset by peer
- 出现原因：配置文件中的maxClientCnxns设置过小。
- 解决办法：将zookeeper中的maxClientCnxns数改大即可。
Exception in thread “main” Java.lang.NoSuchMethodError: method java.lang.management.ManagementFactory.getPlatformMBeanServer with signature ()Ljavax.management.MBeanServer; was not found.
- 出现原因：java版本与使用的zookeeper版本不匹配。
- 解决办法：修改jdk版本并确认jdk版本是否支持zookeeper。

zookeeper配置项详解

参数名	参数说明
clientPort	客户端连接server的端口，即对外服务端口，一般设置为2181吧
dataDir	存储快照文件snapshot的目录。默认情况下，事务日志也会存储在这里。建议同时配置参数dataLogDir, 事务日志的写性能直接影响zk性能。
tickTime	ZK中的一个时间单元。ZK中所有时间都是以这个时间单元为基础，进行整数倍配置的。例如，session的最小超时时间是2*tickTime。
dataLogDir	事务日志输出目录。尽量给事务日志的输出配置单独的磁盘或是挂载点，这将极大的提升ZK性能
globalOutstandingLimit	最大请求堆积数。默认是1000。ZK运行的时候，尽管server已经没有空闲来处理更多的客户端请求了，但是还是允许客户端将请求提交到服务器上来，以提高吞吐性能。当然，为了防止Server内存溢出，这个请求堆积数还是需要限制下的。
preAllocSize	预先开辟磁盘空间，用于后续写入事务日志。默认是64M，每个事务日志大小就是64M。如果ZK的快照频率较大的话，建议适当减小这个参数。
snapCount	每进行snapCount次事务日志输出后，触发一次快照(snapshot), 此时，ZK会生成一个snapshot.文件，同时创建一个新的事务日志文件log.。默认是100000.（真正的代码实现中，会进行一定的随机数处理，以避免所有服务器在同一时间进行快照而影响性能）
traceFile	用于记录所有请求的log，一般调试过程中可以使用，但是生产环境不建议使用，会严重影响性能。
maxClientCnxns	单个客户端与单台服务器之间的连接数的限制，是ip级别的，默认是60，如果设置为0，那么表明不作任何限制。请注意这个限制的使用范围，仅仅是单台客户端机器与单台ZK服务器之间的连接数限制，不是针对指定客户端IP，也不是ZK集群的连接数限制，也不是单台ZK对所有客户端的连接数限制。
clientPortAddress	对于多网卡的机器，可以为每个IP指定不同的监听端口。默认情况是所有IP都监听 clientPort指定的端口。 New in 3.3.0
minSessionTimeoutmaxSessionTimeout	Session超时时间限制，如果客户端设置的超时时间不在这个范围，那么会被强制设置为最大或最小时间。默认的Session超时时间是在2 * tickTime ~ 20 * tickTime 这个范围
fsync.warningthresholdms	事务日志输出时，如果调用fsync方法超过指定的超时时间，那么会在日志中输出警告信息。默认是1000ms。
autopurge.purgeInterval	在上文中已经提到，3.4.0及之后版本，ZK提供了自动清理事务日志和快照文件的功能，这个参数指定了清理频率，单位是小时，需要配置一个1或更大的整数，默认是0，表示不开启自动清理功能。
autopurge.snapRetainCount	这个参数和上面的参数搭配使用，这个参数指定了需要保留的文件数目。默认是保留3个。
initLimit	Follower在启动过程中，会从Leader同步所有最新数据，然后确定自己能够对外服务的起始状态。Leader允许Follower在initLimit时间内完成这个工作。通常情况下，我们不用太在意这个参数的设置。如果ZK集群的数据量确实很大了，F在启动的时候，从Leader上同步数据的时间也会相应变长，因此在这种情况下，有必要适当调大这个参数了。
syncLimit	在运行过程中，Leader负责与ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。如果Leader发出心跳包在syncLimit之后，还没有从Follower那里收到响应，那么就认为这个F已经不在线了。注意：不要把这个参数设置得过大，否则可能会掩盖一些问题。
leaderServes	默认情况下，Leader是会接受客户端连接，并提供正常的读写服务。但是，如果你想让Leader专注于集群中机器的协调，那么可以将这个参数设置为no，这样一来，会大大提高写操作的性能。
server.x=[hostname]:nnnnn[:nnnnn]	这里的x是一个数字，与myid文件中的id是一致的。右边可以配置两个端口，第一个端口用于Follower和Leader之间的数据同步和其它通信，第二个端口用于Leader选举过程中投票通信。
group.x=nnnnn[:nnnnn]weight.x=nnnnn	对机器分组和权重设置
cnxTimeout	Leader选举过程中，打开一次连接的超时时间，默认是5s
skipACL	对所有客户端请求都不作ACL检查。如果之前节点上设置有权限限制，一旦服务器上打开这个开头，那么也将失效。
forceSync	这个参数确定了是否需要在事务日志提交的时候调用FileChannel.force来保证数据完全同步到磁盘。
jute.maxbuffer	每个节点最大数据量，是默认是1M。这个限制必须在server和client端都进行设置才会生效。

zookeeper配置文件示例

tickTime=2000 initLimit=10 syncLimit=5 dataDir=/opt/zookeeper-3.4.6/data clientPort=2181 // maxClientCnxns=60 // autopurge.snapRetainCount=3 server.0=dbslave0:2888:3888 server.1=dbslave1:2888:3888 server.2=dbslave2:2888:3888

zookeeper常用命令

启动zookeeper：
bin/zookeeper-server-start.sh start

停止zookeeper：
bin/zookeeper-server-stop.sh

查看zookeeper日志：
tail -100f logs/zookeeper.out

测试zookeeper之间是否连通组成集群：
bin/zookeeper-server-start.sh status

kafka环境搭建

在进行kafka搭建前确认zookeeper已经搭建完成

修改环境变量，将kafka的路径添加到环境变量中。例如：

修改环境变量

vim ~/.bash_profile

KAFKA_HOME=解压出的kafka目录

export KAFKA_HOME

添加KAFKA_HOME到PATH

PATH=xxx:KAFKA_HOME/bin（注：xxx为之前PATH中有的内容，只需在后边追加KAFKA_HOME/bin即可）

保存环境变量

source ~/.bash_profile

修改解压出的kafka的conf目录下的server.properties 示例配置文件：

# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
# 
#    http://www.apache.org/licenses/LICENSE-2.0
# 
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# see kafka.server.KafkaConfig for additional details and defaults
############################# Server Basics #############################
# The id of the broker. This must be set to a unique integer for each broker.
broker.id=0
############################# Socket Server Settings #############################
# The port the socket server listens on
port=9092
# Hostname the broker will bind to. If not set, the server will bind to all interfaces
#host.name=localhost
host.name=192.168.40.50
# Hostname the broker will advertise to producers and consumers. If not set, it uses the
# value for "host.name" if configured.  Otherwise, it will use the value returned from
# java.net.InetAddress.getCanonicalHostName().
#advertised.host.name=<hostname routable by clients>
# The port to publish to ZooKeeper for clients to use. If this is not set,
# it will publish the same port that the broker binds to.
#advertised.port=<port accessible by clients>
# The number of threads handling network requests
num.network.threads=3
# The number of threads doing disk I/O
num.io.threads=8
# The send buffer (SO_SNDBUF) used by the socket server
socket.send.buffer.bytes=102400
# The receive buffer (SO_RCVBUF) used by the socket server
socket.receive.buffer.bytes=102400
# The maximum size of a request that the socket server will accept (protection against OOM)
socket.request.max.bytes=104857600
############################# Log Basics #############################
# A comma seperated list of directories under which to store log files
log.dirs=/home/kafka/kafka/logs/kafka-logs
# The default number of log partitions per topic. More partitions allow greater
# parallelism for consumption, but this will also result in more files across
# the brokers.
num.partitions=5
# The number of threads per data directory to be used for log recovery at startup and flushing at shutdown.
# This value is recommended to be increased for installations with data dirs located in RAID array.
num.recovery.threads.per.data.dir=2
############################# Log Flush Policy #############################
# Messages are immediately written to the filesystem but by default we only fsync() to sync
# the OS cache lazily. The following configurations control the flush of data to disk. 
# There are a few important trade-offs here:
#    1. Durability: Unflushed data may be lost if you are not using replication.
#    2. Latency: Very large flush intervals may lead to latency spikes when the flush does occur as there will be a lot of data to flush.
#    3. Throughput: The flush is generally the most expensive operation, and a small flush interval may lead to exceessive seeks. 
# The settings below allow one to configure the flush policy to flush data after a period of time or
# every N messages (or both). This can be done globally and overridden on a per-topic basis.
# The number of messages to accept before forcing a flush of data to disk
#log.flush.interval.messages=10000
# The maximum amount of time a message can sit in a log before we force a flush
#log.flush.interval.ms=1000
############################# Log Retention Policy #############################
# The following configurations control the disposal of log segments. The policy can
# be set to delete segments after a period of time, or after a given size has accumulated.
# A segment will be deleted whenever *either* of these criteria are met. Deletion always happens
# from the end of the log.
# The minimum age of a log file to be eligible for deletion
log.retention.hours=168
# A size-based retention policy for logs. Segments are pruned from the log as long as the remaining
# segments don't drop below log.retention.bytes.
#log.retention.bytes=1073741824
# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=1073741824
# The interval at which log segments are checked to see if they can be deleted according 
# to the retention policies
log.retention.check.interval.ms=300000
# By default the log cleaner is disabled and the log retention policy will default to just delete segments after their retention expires.
# If log.cleaner.enable=true is set the cleaner will be enabled and individual logs can then be marked for log compaction.
log.cleaner.enable=false
############################# Zookeeper #############################
# Zookeeper connection string (see zookeeper docs for details).
# This is a comma separated host:port pairs, each corresponding to a zk
# server. e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002".
# You can also append an optional chroot string to the urls to specify the
# root directory for all kafka znodes.
zookeeper.connect=192.168.40.50:2181
# Timeout in ms for connecting to zookeeper
zookeeper.connection.timeout.ms=6000

kafka配置项详解

参数名	参数说明
broker.id	每个broker都可以用一个唯一的非负整数id进行标识；这个id可以作为broker的“名字”，并且它的存在使得broker无须混淆consumers就可以迁移到不同的host/port上。你可以选择任意你喜欢的数字作为id，只要id是唯一的即可。
log.dirs	kafka存放数据的路径。这个路径并不是唯一的，可以是多个，路径之间只需要使用逗号分隔即可；每当创建新partition时，都会选择在包含最少partitions的路径下进行。
port	server接受客户端连接的端口（默认是6667，可以修改为9092）
zookeeper.connect	ZooKeeper连接字符串的格式为：hostname:port，此处hostname和port分别是ZooKeeper集群中某个节点的host和port；为了当某个host宕掉之后你能通过其他ZooKeeper节点进行连接，你可以按照一下方式制定多个hosts：hostname1:port1, hostname2:port2, hostname3:port3.
message.max.bytes	server可以接收的消息最大尺寸。重要的是，consumer和producer有关这个属性的设置必须同步，否则producer发布的消息对consumer来说太大。
num.io.threads	server用来处理请求的I/O线程的数目；这个线程数目至少要等于硬盘的个数。
background.threads	用于后台处理的线程数目，例如文件删除；你不需要更改这个属性。
queued.max.requests	在网络线程停止读取新请求之前，可以排队等待I/O线程处理的最大请求个数。
host.name	broker的hostname；如果hostname已经设置的话，broker将只会绑定到这个地址上；如果没有设置，它将绑定到所有接口，并发布一份到ZK
advertised.host.name	如果设置，则就作为broker 的hostname发往producer、consumers以及其他brokers
advertised.port	此端口将给与producers、consumers、以及其他brokers，它会在建立连接时用到；它仅在实际端口和server需要绑定的端口不一样时才需要设置。
socket.send.buffer.bytes	SO_SNDBUFF 缓存大小，server进行socket 连接所用
socket.receive.buffer.bytes	SO_RCVBUFF缓存大小，server进行socket连接时所用
socket.request.max.bytes	server允许的最大请求尺寸；这将避免server溢出，它应该小于Java heap size
num.partitions	如果创建topic时没有给出划分partitions个数，这个数字将是topic下partitions数目的默认数值。（默认是1）
log.segment.bytes	topic partition的日志存放在某个目录下诸多文件中，这些文件将partition的日志切分成一段一段的；这个属性就是每个文件的最大尺寸；当尺寸达到这个数值时，就会创建新文件。此设置可以由每个topic基础设置时进行覆盖。
log.roll.hours	即使文件没有到达log.segment.bytes，只要文件创建时间到达此属性，就会创建新文件。这个设置也可以有topic层面的设置进行覆盖；
log.retention.minutes和log.retention.hours	每个日志文件删除之前保存的时间。默认数据保存时间对所有topic都一样。log.retention.minutes 和 log.retention.bytes 都是用来设置删除日志文件的，无论哪个属性已经溢出。这个属性设置可以在topic基本设置时进行覆盖。
log.retention.bytes	每个topic下每个partition保存数据的总量；注意，这是每个partitions的上限，因此这个数值乘以partitions的个数就是每个topic保存的数据总量。同时注意：如果log.retention.hours和log.retention.bytes都设置了，则超过了任何一个限制都会造成删除一个段文件。注意，这项设置可以由每个topic设置时进行覆盖
log.retention.check.interval.ms	检查日志分段文件的间隔时间，以确定是否文件属性是否到达删除要求。
log.cleaner.enable	当这个属性设置为false时，一旦日志的保存时间或者大小达到上限时，就会被删除；如果设置为true，则当保存属性达到上限时，就会进行log compaction。
log.cleaner.threads	进行日志压缩的线程数
log.cleaner.io.max.bytes.per.second	进行log compaction时，log cleaner可以拥有的最大I/O数目。这项设置限制了cleaner，以避免干扰活动的请求服务。
log.cleaner.io.buffer.size	log cleaner清除过程中针对日志进行索引化以及精简化所用到的缓存大小。最好设置大点，以提供充足的内存。
log.cleaner.io.buffer.load.factor	进行log cleaning时所需要的I/O chunk尺寸。你不需要更改这项设置。
log.cleaner.io.buffer.load.factor	log cleaning中所使用的hash表的负载因子；你不需要更改这个选项。
log.cleaner.backoff.ms	进行日志是否清理检查的时间间隔
log.cleaner.min.cleanable.ratio	这项配置控制log compactor试图清理日志的频率（假定log compaction是打开的）。默认避免清理压缩超过50%的日志。这个比率绑定了备份日志所消耗的最大空间（50%的日志备份时压缩率为50%）。更高的比率则意味着浪费消耗更少，也就可以更有效的清理更多的空间。这项设置在每个topic设置中可以覆盖。
log.cleaner.delete.retention.ms	保存时间；保存压缩日志的最长时间；也是客户端消费消息的最长时间，荣log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据；会被topic创建时的指定时间覆盖。
log.index.size.max.bytes	每个log segment的最大尺寸。注意，如果log尺寸达到这个数值，即使尺寸没有超过log.segment.bytes限制，也需要产生新的log segment。
log.index.interval.bytes	当执行一次fetch后，需要一定的空间扫描最近的offset，设置的越大越好，一般使用默认值就可以
log.flush.interval.messages	log文件“sync”到磁盘之前累积的消息条数。因为磁盘IO操作是一个慢操作，但又是一个“数据可靠性”的必要手段，所以检查是否需要固化到硬盘的时间间隔。需要在“数据可靠性”与“性能”之间做必要的权衡，如果此值过大，将会导致每次“发sync”的时间过长（IO阻塞），如果此值过小，将会导致“fsync”的时间较长（IO阻塞），如果此值过小，将会导致”发sync“的次数较多，这也就意味着整体的client请求有一定的延迟，物理server故障，将会导致没有fsync的消息丢失。
log.flush.scheduler.interval.ms	检查是否需要fsync的时间间隔
log.flush.interval.ms	仅仅通过interval来控制消息的磁盘写入时机，是不足的，这个数用来控制”fsync“的时间间隔，如果消息量始终没有达到固化到磁盘的消息数，但是离上次磁盘同步的时间间隔达到阈值，也将触发磁盘同步。
log.delete.delay.ms	文件在索引中清除后的保留时间，一般不需要修改
auto.create.topics.enable	是否允许自动创建topic。如果是真的，则produce或者fetch 不存在的topic时，会自动创建这个topic。否则需要使用命令行创建topic
controller.socket.timeout.ms	partition管理控制器进行备份时，socket的超时时间。
controller.message.queue.size	controller-to-broker-channles的buffer 尺寸
default.replication.factor	默认备份份数，仅指自动创建的topics，手动创建topic时会指定备份的数量
replica.lag.time.max.ms	如果一个follower在这个时间内没有发送fetch请求，leader将从ISR重移除这个follower，并认为这个follower已经挂了
replica.lag.max.messages	如果一个replica没有备份的条数超过这个数值，则leader将移除这个follower，并认为这个follower已经挂了
replica.socket.timeout.ms	leader 备份数据时的socket网络请求的超时时间
replica.socket.receive.buffer.bytes	备份时向leader发送网络请求时的socket receive buffer
replica.fetch.max.bytes	备份时每次fetch的最大值
replica.fetch.min.bytes	leader发出备份请求时，数据到达leader的最长等待时间
replica.fetch.min.bytes	备份时每次fetch之后回应的最小尺寸
num.replica.fetchers	从leader备份数据的线程数（默认1）
replica.high.watermark.checkpoint.interval.ms	每个replica检查是否将最高水位进行固化的频率（默认5000ms）
fetch.purgatory.purge.interval.requests	fetch 请求清除时的清除间隔（默认1000ms）
producer.purgatory.purge.interval.requests	producer请求清除时的清除间隔（默认1000ms）
zookeeper.session.timeout.ms	zookeeper会话超时时间。（默认6000ms）
zookeeper.connection.timeout.ms	客户端等待和zookeeper建立连接的最大时间（默认6000ms）
zookeeper.sync.time.ms	zk follower落后于zk leader的最长时间（默认2000ms）
controlled.shutdown.enable	是否能够控制broker的关闭。如果能够，broker将可以移动所有leaders到其他的broker上，在关闭之前。这减少了不可用性在关机过程中。(默认true)
controlled.shutdown.max.retries	在执行不彻底的关机之前，可以成功执行关机的命令数。（默认3）
controlled.shutdown.retry.backoff.ms	在关机之间的backoff时间（默认5000ms）
auto.leader.rebalance.enable	如果这是true，控制者将会自动平衡brokers对于partitions的leadership（默认true）
leader.imbalance.per.broker.percentage	每个broker所允许的leader最大不平衡比率（默认10）
leader.imbalance.check.interval.seconds	检查leader不平衡的频率（默认300）
offset.metadata.max.bytes	允许客户端保存他们offsets的最大个数（默认4096）
max.connections.per.ip	每个ip地址上每个broker可以被连接的最大数目
max.connections.per.ip.overrides	每个ip或者hostname默认的连接的最大覆盖
connections.max.idle.ms	空连接的超时限制（默认60000）
log.roll.jitter.{ms,hours}	从logRollTimeMillis抽离的jitter最大数目（默认0）
num.recovery.threads.per.data.dir	每个数据目录用来日志恢复的线程数目（默认1）
unclean.leader.election.enable	指明了是否能够使不在ISR中replicas设置用来作为leader（默认true）
delete.topic.enable	能够删除topic（默认false）
offsets.topic.num.partitions	分片提交到topic的偏移量，由于改变后的部署是目前不支持，我们建议使用较高的设定生产（默认50）
offsets.topic.retention.minutes	存在时间超过这个时间限制的offsets都将被标记为待删除（默认1140）
offsets.retention.check.interval.ms	offset管理器检查陈旧offsets的频率（默认600000）
offsets.topic.replication.factor	topic的offset的备份份数。建议设置更高的数字保证更高的可用性（默认3）
offset.topic.segment.bytes	offsets topic的segment尺寸。（默认104857600）
offsets.load.buffer.size	这项设置与批量尺寸相关，当从offsets segment中读取时使用。（默认5242880）
offsets.commit.required.acks	在offset commit可以接受之前，需要设置确认的数目，一般不需要更改（默认-1）

kafka环境变量配置

环境变量：
修改环境变量
vim  ~/.bash_profile
KAFKA_HOME=解压出的kafka目录
export KAFKA_HOME
添加KAFKA_HOME到PATH
PATH=xxx:KAFKA_HOME/bin （注：xxx为之前PATH中有的内容，只需在后边追加KAFKA_HOME/bin即可）

保存环境变量
source ~/.bash_profile

kafka常用命令

启动kafka
./bin/kafka-server-start.sh -daemon config/server.properties
创建topic
（*先创建一个测试的topic，测试成功后再创建下边的topic）
kafka-topics.sh --create --zookeeper 10.32.164.235:2181,10.32.164.236:2181,10.32.164.238:2181 --replication-factor 1 --partitions 3 --topic TOPIC_UOSP_PERFORMANCE
（注：红色的部分数字是和部署的kafka机器数有关的，部署两台就将红色部分修改为2，以此类推。
蓝色部分是zookeeper的地址，配置几台zookeeper就写几个，端口号默认使用2181）
查看创建的topic
kafka-topics.sh --list --zookeeper localhost:2181（注：localhost部分是要查看topic的zookeeper地址，如果部署多台，地址填多个，用英文逗号分隔）

kafka配置文件示例

    # Licensed to the Apache Software Foundation (ASF) under one or more
    # contributor license agreements.  See the NOTICE file distributed with
    # this work for additional information regarding copyright ownership.
    # The ASF licenses this file to You under the Apache License, Version 2.0
    # (the "License"); you may not use this file except in compliance with
    # the License.  You may obtain a copy of the License at
    # 
    #    http://www.apache.org/licenses/LICENSE-2.0
    # 
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    # see kafka.server.KafkaConfig for additional details and defaults

    ############################# Server Basics #############################

    # The id of the broker. This must be set to a unique integer for each broker.
    broker.id=0

    ############################# Socket Server Settings #############################

    # The port the socket server listens on
    port=9092

    # Hostname the broker will bind to. If not set, the server will bind to all interfaces
    #host.name=localhost
    host.name=192.168.40.50

    # Hostname the broker will advertise to producers and consumers. If not set, it uses the
    # value for "host.name" if configured.  Otherwise, it will use the value returned from
    # java.net.InetAddress.getCanonicalHostName().
    #advertised.host.name=<hostname routable by clients>

    # The port to publish to ZooKeeper for clients to use. If this is not set,
    # it will publish the same port that the broker binds to.
    #advertised.port=<port accessible by clients>

    # The number of threads handling network requests
    num.network.threads=3

    # The number of threads doing disk I/O
    num.io.threads=8

    # The send buffer (SO_SNDBUF) used by the socket server
    socket.send.buffer.bytes=102400

    # The receive buffer (SO_RCVBUF) used by the socket server
    socket.receive.buffer.bytes=102400

    # The maximum size of a request that the socket server will accept (protection against OOM)
    socket.request.max.bytes=104857600


    ############################# Log Basics #############################

    # A comma seperated list of directories under which to store log files
    log.dirs=/home/kafka/kafka/logs/kafka-logs

    # The default number of log partitions per topic. More partitions allow greater
    # parallelism for consumption, but this will also result in more files across
    # the brokers.
    num.partitions=5

    # The number of threads per data directory to be used for log recovery at startup and flushing at shutdown.
    # This value is recommended to be increased for installations with data dirs located in RAID array.
    num.recovery.threads.per.data.dir=2

    ############################# Log Flush Policy #############################

    # Messages are immediately written to the filesystem but by default we only fsync() to sync
    # the OS cache lazily. The following configurations control the flush of data to disk. 
    # There are a few important trade-offs here:
    #    1. Durability: Unflushed data may be lost if you are not using replication.
    #    2. Latency: Very large flush intervals may lead to latency spikes when the flush does occur as there will be a lot of data to flush.
    #    3. Throughput: The flush is generally the most expensive operation, and a small flush interval may lead to exceessive seeks. 
    # The settings below allow one to configure the flush policy to flush data after a period of time or
    # every N messages (or both). This can be done globally and overridden on a per-topic basis.

    # The number of messages to accept before forcing a flush of data to disk
    #log.flush.interval.messages=10000

    # The maximum amount of time a message can sit in a log before we force a flush
    #log.flush.interval.ms=1000

    ############################# Log Retention Policy #############################

    # The following configurations control the disposal of log segments. The policy can
    # be set to delete segments after a period of time, or after a given size has accumulated.
    # A segment will be deleted whenever *either* of these criteria are met. Deletion always happens
    # from the end of the log.

    # The minimum age of a log file to be eligible for deletion
    log.retention.hours=168

    # A size-based retention policy for logs. Segments are pruned from the log as long as the remaining
    # segments don't drop below log.retention.bytes.
    #log.retention.bytes=1073741824

    # The maximum size of a log segment file. When this size is reached a new log segment will be created.
    log.segment.bytes=1073741824

    # The interval at which log segments are checked to see if they can be deleted according 
    # to the retention policies
    log.retention.check.interval.ms=300000

    # By default the log cleaner is disabled and the log retention policy will default to just delete segments after their retention expires.
    # If log.cleaner.enable=true is set the cleaner will be enabled and individual logs can then be marked for log compaction.
    log.cleaner.enable=false

    ############################# Zookeeper #############################

    # Zookeeper connection string (see zookeeper docs for details).
    # This is a comma separated host:port pairs, each corresponding to a zk
    # server. e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002".
    # You can also append an optional chroot string to the urls to specify the
    # root directory for all kafka znodes.
    zookeeper.connect=192.168.40.50:2181

    # Timeout in ms for connecting to zookeeper
    zookeeper.connection.timeout.ms=6000

更多kafka相关学习知识在http://orchome.com

W1ngLLL

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
kafka总结

kafka总结（新手）基本概念通信：各组件通过TCP进行通信，确保集群中的各台机器相互连通。 Topic: 主题，每条发布到kafka集群的消息属于的类别，即kafka是面向topic的。 Broker: kafka的服务器，每部署一台kafka就是一个broker。 Producer & Consumer: 生产者和消费者。一般消息系统都有生产者和消费者的概念。生产者产生消息，即把消息放入
复制链接

扫一扫