1.kafka基本原理简介
1.1名词简介：
1.producer： 消息生产者，发布消息到 kafka 集群的终端或服务。 2.broker： kafka 集群中包含的服务器。 3.topic： 每条发布到 kafka 集群的消息属于的类别，即 kafka 是面向 topic 的。 4.partition： partition 是物理上的概念，每个 topic 包含一个或多个 partition。kafka 分配的单位是 partition。 5.consumer： 从 kafka 集群中消费消息的终端或服务。 6.Consumer group： high-level consumer API 中，每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 中的一个 Consumer 消费，但可以被多个 consumer group 消费。 7.replica： partition 的副本，保障 partition 的高可用。 8.leader： replica 中的一个角色， producer 和 consumer 只跟 leader 交互。 9.follower： replica 中的一个角色，从 leader 中复制数据。 10.controller： kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover。 12.zookeeper： kafka 通过 zookeeper 来存储集群的 meta 信息。
1.2 kafka原理：
1.2.1拓扑图
1.2.2 zookeeper 节点
1.2.3 写入流程：
1. producer 先从 zookeeper 的 "/brokers/.../state" 节点找到该 partition 的 leader 2. producer 将消息发送给该 leader 3. leader 将消息写入本地 log 4. followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK 5. leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK
1.2.4 kafka的存储机制：
kafka通过topic来分主题存放数据 主题内又有分区 分区还可以有多个副本 ，分区的内部还细分为若干个segment。
所谓的分区 其实就是在 kafka对应存储目录下创建的文件夹，文件夹的名字是主题名加上分区编号 编号从0开始。
所谓的segment 其实就只在分区对应的文件夹下产生的文件。一个分区会被划分成大小相等的若干segment 这样一方面保证了分区的数据被划分到多个文件中保证不会产生体积过大的文件 另一方面可以基于这些segment文件进行历史数据的删除 提高效率。
一个segment又由 一个.log和一个.index文件组成，其中.log文件为数据文件用来存放数据分段数据 .index为索引文件保存对对应的.log文件的索引信息。这两个文件的命名规则为：partition全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值，数值大小为64位，20位数字字符长度，没有数字用0填充。
而在.index文件中 保存了对对应 .log文件的索引信息，通过查找.index文件可以获知每个存储在当前segment中的offset在.log文件中的开始位置 而每条日志 有其固定格式 保存了 包括offset编号 日志长度 key的长度 等相关信息 通过这个固定格式中的数据可以确定出当前offset的结束位置 从而对数据进行读取
真正开始读取指定分区中 某个offset对应的数据时 先根据offset和当前分区 的所有segment的名称做比较 确定出数据在哪个segment中 查找该segment的索引文件 确定当前offset在数据文件中的开始位置 从该位置开始读取数据文件 在根据数据格式判断结果 最终 获取到完整数据。
1.2.5 消息可靠性保证：
在Kafka中维护了 一个AR列表 包括所有的分区的副本
AR又分为ISR和OSR
只有ISR内的副本都同步了leader中的数据，该数据才能被提交，才能被消费者访问
OSR内的副本是否同步了leader的数据，不影响数据的提交，OSR内的follower 尽力的去同步leader，可能数据版本或落后
AR = ISR + OSR
最开始所有的副本都在ISR中 在kafka工作的过程中 如果某个副本同步速度慢于replica.lag.time.max.ms指定的阈值，则被踢出ISR 存入OSR 如果后续速度恢复可以回到ISR中
LEO - LogEndOffset - 分区的最新的数据的offset
HW - HighWatermark - 只有写入的数据被 同步到 所有的ISR中的 副本后，数据才认为已提交，HW更新到该位置，HW之前的数据才可以被消费者访问，保证 没有 同步完成的数据不会被消费者 访问到
在leader宕机后，只能从ISR列表中选取新的leader，无论ISR中哪个副本被选为 新的leader都知道HW之前的数据，可以保证在切换了leader后，消费者可以继续看到 之前已经 提交的数据
AR ISR OSR LEO HW 这些信息都被保存在Zookeeper中
1.2.6 生产者生产数据的可靠性
生产者向leader发送数据时，可以选择需要的可靠性级别
通过request.required.acks参数配置：
1 - 生产者发送数据给leader，leader收到数据后发送成功信息，生产者收到后认为发送数据成功 ，如果一直收不到成功消息，则生产者认为发送数据失败会自动重发数据.
当leader宕机时，可能丢失数据
0 - 生产者不停向leader发送数据，而不需要leader反馈成功消息
这种模式效率最高，可靠性最低
可能在发送过程中丢失数据
可能在leader宕机时丢失数据
-1 - 生产者发送数据给leader，leader收到数据后要等到ISR列表中的所有副本都同步数据完成后，才向生产者发送成功消息，如果一只收不到成功消息，则认为发送数据失败会自动重发数据.
这种模式下可靠性很高，但是 当ISR列表中只剩下leader时，当leader宕机让然有可能丢数据
此时可以配置min.insync.replicas指定要求观察ISR中至少要有指定数量的副本，默认该值为1，需要改为大于等于2的值
这样当生产者发送数据给leader但是发现ISR中只有leader自己时，会 收到异常表明数据写入失败
此时无法写入数据 保证了数据绝对不丢
虽然不丢但是可能会多数据，例如生产者发送数据给leader，leader同步数据给ISR中的follower，同步到一半leader宕机，此时选出新的leader，可能具有部分此次提交的数据，而生产者收到失败消息重发数据，新的leader接受 数据则数据重复了
1.2.7 HW截断机制
如果leader宕机 选出了新的leader 而新的leader并没有完全同步之前leader的所有数据，之后接受了后续新的数据，此时旧的leader恢复，则会发现新的leader中的数据和自己持有的数据不一致，此时旧的leader会将自己的数据阶段到之前宕机之前的hw位置，之后同步新leader的数据
如果ISR中的follower同步了leader中的部分数据，之后leader宕机，follower也宕机，此时选出新的leader可能同步了部分之前 leader的数据，之后接受新的数据，此时follower恢复过来，发现 自己持有的 数据和新 的leader的数据不一致，此时阶段数据到 之前的 hw将，然后和 新的leader同步 数据
1.2.8 leader选举
当leader宕机时 会选择ISR中的一个follower成为新的leader
如果ISR中的所有副本都宕机 怎么办
unclean.leader.election.enable=false
策略1：必须等待ISR列表中的副本活过来才选择其成为leader继续工作
unclean.leader.election.enable=true
策略2：选择任何一个活过来的副本 - 可能不在ISR中 - 成为leader继续工作
策略1，可靠性有保证，但是可用性低，只有最后挂了leader活过来kafka才能恢复
策略2，可用性高，可靠性没有保证，任何一个副本活过来就可以继续工作，但是有可能存在数据不一致的情况
1.2.9 kafka可靠性的保证
At most once: 消息可能会丢，但绝不会重复传输
At least once：消息绝不会丢，但可能会重复传输
Exactly once：每条消息肯定会被传输一次且仅传输一次
kafka最多保证At least once，可以保证不丢 但是可能会重复,为了解决重复需要引入唯一标识和去重机制，kafka提供了GUID实现了唯一标识，但是并没有提供自带的去重机制，需要开发人员基于业务规则自己去重.
2.集群配置：
broker.id ：
每个broker都可以用一个唯一的非负整数id进行标识；这个id可以作为broker的“名字”，并且它的存在使得broker无须混淆consumers就可以迁移到不同的host/port上。你可以选择任意你喜欢的数字作为id，只要id是唯一的即可。
log.dirs：
kafka存放数据的路径。这个路径并不是唯一的，可以是多个，路径之间只需要使用逗号分隔即可；每当创建新partition时，都会选择在包含最少partitions的路径下进行。
port：
server接受客户端连接的端口。
zookeeper.connect：
ZooKeeper连接字符串的格式为：hostname:port，此处hostname和port分别是ZooKeeper集群中某个节点的host和port；为了当某个host宕掉之后你能通过其他ZooKeeper节点进行连接，你可以按照一下方式制定多个hosts：
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper 允许你增加一个“chroot”路径，将集群中所有kafka数据存放在特定的路径下。当多个Kafka集群或者其他应用使用相同ZooKeeper集群时，可以使用这个方式设置数据存放路径。这种方式的实现可以通过这样设置连接字符串格式，如下所示：
hostname1：port1，hostname2：port2，hostname3：port3/chroot/path
这样设置就将所有kafka集群数据存放在/chroot/path路径下。注意，在你启动broker之前，你必须创建这个路径，并且consumers必须使用相同的连接格式。
message.max.bytes：
server可以接收的消息最大尺寸。重要的是，consumer和producer有关这个属性的设置必须同步，否则producer发布的消息对consumer来说太大，默认是1000000。
num.network.threads：
server用来处理网络请求的网络线程数目；一般你不需要更改这个属性，默认为3。
num.io.threads：
server用来处理请求的I/O线程的数目；这个线程数目至少要等于硬盘的个数，默认是8。
background.threads：
用于后台处理的线程数目，例如文件删除；你不需要更改这个属性，默认是4。
queued.max.requests：
在网络线程停止读取新请求之前，可以排队等待I/O线程处理的最大请求个数，默认500。
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 连接所用，默认100 * 1024
socket.receive.buffer.bytes：
SO_RCVBUFF缓存大小，server进行socket连接时所用，默认100 * 1024
socket.request.max.bytes：
erver允许的最大请求尺寸； 这将避免server溢出，它应该小于Java heap size，默认100 * 1024 * 1024
num.partitions：
如果创建topic时没有给出划分partitions个数，这个数字将是topic下partitions数目的默认数值1。
log.segment.bytes：
topic partition的日志存放在某个目录下诸多文件中，这些文件将partition的日志切分成一段一段的；这个属性就是每个文件的最大尺寸；当尺寸达到这个数值时，就会创建新文件。此设置可以由每个topic基础设置时进行覆盖。
查看 the per-topic configuration section
log.roll.hours：
即使文件没有到达log.segment.bytes，只要文件创建时间到达此属性，就会创建新文件。这个设置也可以有topic层面的设置进行覆盖；
查看the per-topic configuration section
log.retention.minutes和log.retention.hours：
每个日志文件删除之前保存的时间。默认数据保存时间对所有topic都一样。
log.retention.minutes 和 log.retention.bytes 都是用来设置删除日志文件的，无论哪个属性已经溢出。
这个属性设置可以在topic基本设置时进行覆盖。
查看the per-topic configuration section
log.retention.bytes：
每个topic下每个partition保存数据的总量；注意，这是每个partitions的上限，因此这个数值乘以partitions的个数就是每个topic保存的数据总量。同时注意：如果log.retention.hours和log.retention.bytes都设置了，则超过了任何一个限制都会造成删除一个段文件。
注意，这项设置可以由每个topic设置时进行覆盖。
查看the per-topic configuration section
log.retention.check.interval.ms：
检查日志分段文件的间隔时间，以确定是否文件属性是否到达删除要求，默认5 minutes。
log.cleaner.enable：
当这个属性设置为false时，一旦日志的保存时间或者大小达到上限时，就会被删除；如果设置为true，则当保存属性达到上限时，就会进行log compaction。
log.cleaner.threads：
进行日志压缩的线程数，默认1
log.cleaner.io.max.bytes.per.second：
进行log compaction时，log cleaner可以拥有的最大I/O数目。这项设置限制了cleaner，以避免干扰活动的请求服务
log.cleaner.io.buffer.size：
log cleaner清除过程中针对日志进行索引化以及精简化所用到的缓存大小。最好设置大点，以提供充足的内存，默认500*1024*1024。
log.cleaner.io.buffer.load.factor
进行log cleaning时所需要的I/O chunk尺寸。你不需要更改这项设置。
log.cleaner.io.buffer.load.factor
log cleaning中所使用的hash表的负载因子；你不需要更改这个选项。
log.cleaner.backoff.ms
进行日志是否清理检查的时间间隔，默认：15000
log.cleaner.min.cleanable.ratio
这项配置控制log compactor试图清理日志的频率（假定log compaction是打开的）。默认避免清理压缩超过50%的日志。这个比率绑定了备份日志所消耗的最大空间（50%的日志备份时压缩率为50%）。更高的比率则意味着浪费消耗更少，也就可以更有效的清理更多的空间。这项设置在每个topic设置中可以覆盖， 默认0.5。
查看the per-topic configuration section。
log.cleaner.delete.retention.ms：
保存时间；保存压缩日志的最长时间；也是客户端消费消息的最长时间，荣log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据；会被topic创建时的指定时间覆盖，默认1day。
log.index.size.max.bytes：
每个log segment的最大尺寸。注意，如果log尺寸达到这个数值，即使尺寸没有超过log.segment.bytes限制，也需要产生新的log segment，默认：10*1024*1024
log.index.interval.bytes：
当执行一次fetch后，需要一定的空间扫描最近的offset，设置的越大越好，一般使用默认值就可以，默认4096
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 | true | 是否允许自动创建topic。如果是真的，则produce或者fetch 不存在的topic时，会自动创建这个topic。否则需要使用命令行创建topic |
| controller.socket.timeout.ms | 30000 | partition管理控制器进行备份时，socket的超时时间。 |
| controller.message.queue.size | Int.MaxValue | controller-to-broker-channles的buffer 尺寸 |
| default.replication.factor | 1 | 默认备份份数，仅指自动创建的topics |
| replica.lag.time.max.ms | 10000 | 如果一个follower在这个时间内没有发送fetch请求，leader将从ISR重移除这个follower，并认为这个follower已经挂了 |
| replica.lag.max.messages | 4000 | 如果一个replica没有备份的条数超过这个数值，则leader将移除这个follower，并认为这个follower已经挂了 |
| replica.socket.timeout.ms | 30*1000 | leader 备份数据时的socket网络请求的超时时间 |
| replica.socket.receive.buffer.bytes | 64*1024 | 备份时向leader发送网络请求时的socket receive buffer |
| replica.fetch.max.bytes | 1024*1024 | 备份时每次fetch的最大值 |
| replica.fetch.min.bytes | 500 | leader发出备份请求时，数据到达leader的最长等待时间 |
| replica.fetch.min.bytes | 1 | 备份时每次fetch之后回应的最小尺寸 |
| num.replica.fetchers | 1 | 从leader备份数据的线程数 |
| replica.high.watermark.checkpoint.interval.ms | 5000 | 每个replica检查是否将最高水位进行固化的频率 |
| fetch.purgatory.purge.interval.requests | 1000 | fetch 请求清除时的清除间隔 |
| producer.purgatory.purge.interval.requests | 1000 | producer请求清除时的清除间隔 |
| zookeeper.session.timeout.ms | 6000 | zookeeper会话超时时间。 |
| zookeeper.connection.timeout.ms | 6000 | 客户端等待和zookeeper建立连接的最大时间 |
| zookeeper.sync.time.ms | 2000 | zk follower落后于zk leader的最长时间 |
| controlled.shutdown.enable | true | 是否能够控制broker的关闭。如果能够，broker将可以移动所有leaders到其他的broker上，在关闭之前。这减少了不可用性在关机过程中。 |
| controlled.shutdown.max.retries | 3 | 在执行不彻底的关机之前，可以成功执行关机的命令数。 |
| controlled.shutdown.retry.backoff.ms | 5000 | 在关机之间的backoff时间 |
| auto.leader.rebalance.enable | true | 如果这是true，控制者将会自动平衡brokers对于partitions的leadership |
| leader.imbalance.per.broker.percentage | 10 | 每个broker所允许的leader最大不平衡比率 |
| leader.imbalance.check.interval.seconds | 300 | 检查leader不平衡的频率 |
| offset.metadata.max.bytes | 4096 | 允许客户端保存他们offsets的最大个数 |
| max.connections.per.ip | Int.MaxValue | 每个ip地址上每个broker可以被连接的最大数目 |
| max.connections.per.ip.overrides |
| 每个ip或者hostname默认的连接的最大覆盖 |
| connections.max.idle.ms | 600000 | 空连接的超时限制 |
| log.roll.jitter.{ms,hours} | 0 | 从logRollTimeMillis抽离的jitter最大数目 |
| num.recovery.threads.per.data.dir | 1 | 每个数据目录用来日志恢复的线程数目 |
| unclean.leader.election.enable | true | 指明了是否能够使不在ISR中replicas设置用来作为leader |
| delete.topic.enable | false | 能够删除topic |
| offsets.topic.num.partitions | 50 | The number of partitions for the offset commit topic. Since changing this after deployment is currently unsupported, we recommend using a higher setting for production (e.g., 100-200). |
| offsets.topic.retention.minutes | 1440 | 存在时间超过这个时间限制的offsets都将被标记为待删除 |
| offsets.retention.check.interval.ms | 600000 | offset管理器检查陈旧offsets的频率 |
| offsets.topic.replication.factor | 3 | topic的offset的备份份数。建议设置更高的数字保证更高的可用性 |
| offset.topic.segment.bytes | 104857600 | offsets topic的segment尺寸。 |
| offsets.load.buffer.size | 5242880 | 这项设置与批量尺寸相关，当从offsets segment中读取时使用。 |
| offsets.commit.required.acks | -1 | 在offset commit可以接受之前，需要设置确认的数目，一般不需要更改 |
3.生产环境调优：
315
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
