原理

概念

  • High Watermark：副本高水位值，简称HW，它表示该分区最新一条已提交消息(committed message)的位移
  • LEO：log end offset。从名字上来看似乎是日志结束位移，但其实是下一条消息的位移，即追加写下一条消息的位移

    稳定性相关原理

    当broker离开集群，控制器决定分区的新leader（首领）。

    leader失效

    如果follower在10秒内没有请求任何消息，或者虽然在请求消息，但在10s内没有请求最新的数据，那么它就会被认为是不同步的。在首领发生失效时，不同步的副本不可能成为新首领一一毕竟它没有包含全部的消息。
    只有同步的副本会成为新leader
    replica.lag.time.max.ms可以调整被认定不同步副本时间。

    Failover

    1.1版本前任何一块磁盘挂掉整个Broker会关闭。1.1版本后，坏掉磁盘数据会转移到其他磁盘，Broker仍然正常。有了这个机制RAID不是特别必要。

    性能相关原理

    索引

    稀疏索引，使用二分查找确定具体索引项。

    缓存较少刷盘

    为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,

    零复制

    Kafka直接从Linux文件系统中把数据发送到网络管道。不会在中间本地缓存。从而获得更好性能。

    其他

    Topic上限不能太多，性能会下降
    参考：https://yq.aliyun.com/articles/25379

    其他原理

    Balancing leadership

    preferred replicas preferred leader
    生产请求和获取请求都必须发送给分区的首领副本。如果 broker 收到一个针对特定分区的 请求，而该分区的首领在另 broker 上，那么发送请求的客户端会收到 个“非分区 首领”的错误响应。当针对特定分区的获取请求被发送到一个不含有该分区首领的 broker 上，也会出现同样的错误。 Kafka 客户端自己负责把生产请求和获取请求发送到正确的 broker 上。

    日志的合并

    经过一次次清理后，各个segment大小会慢慢变小。为了避免日志目录下有过多的小文件，kafka在每次日志清理后会进行小文件日志合并。kafka会保证合并后的segment大小不超过segmentSize(通过log.segments.bytes设置，默认值是1G)，且对应的索引文件占用大小之和不超过maxIndexSize（可以通过broker端参数log.index.interval.bytes设置，默认值为10MB）

备忘

单个 broker 可以轻松处理数 千个分区以及每秒百万级的消息量。每个集群都有 broker 同时充当了集群控制器的角色（自动 从集群的活跃成员中选举出来）。
https://lihuixin.iteye.com/blog/2392619
broker.id=0　注册到zk的/brokers/ids路径下，id重复不会注册成功
https://www.cnblogs.com/kaleidoscope/p/9768772.html

副本机制备忘录
https://www.cnblogs.com/huxi2b/p/5903354.html

连接Kafka的Client那台机器要配置HOST，要不然连接9092后，返回指定Broker主机名会导致连接不上。

clients.NetworkClient: [Consumer clientId=consumer-1, groupId=console-consumer-67312] Error connecting to node kudu1:9092 (id: 0 rack: null) java.net.UnknownHostException: kudu1: 未知的名称或服务