消息交付语义

最多一次 
最少一次 
精确一次 


判断一个节点是否存活

节点维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接
follower节点及时与leader 同步，延时不能太久

producer 如何将数据发送到 broker 的 leader(主节点)

存活节点列表  
topic 目标分区的 leader

类似 AS 的 智能客户端

consumer 消费消息时，向 broker 发送 fetch 请求 消费特定分区的消息，
指定 offset ， 从指定位置开始消费消息

采用 Pull 模式
consumer 可以自主决定是否批量从 broker 拉取数据
Pull 缺点   consumer 不断的轮询

push 模式，当 broker 推送的速率远大于 consumer 消费的速率时，consumer 可能崩溃。

存储消息格式

固定长度的头部 + 可变长度的字节数组
头部 = 版本号 + CRC32 校验码

消息长度: 4 bytes (value: 1+4+n)
版本号: 1 byte
CRC 校验码: 4 bytes
具体的消息: n bytes

topic  parition 
分段 
容易定期清除或删除已经消费完文件，减少磁盘占用

通过索引信息快速定位 message
index 元数据全部映射到 memory 
索引文件稀疏存储 

与 传统消息系统 区别
持久化日志 日志可以被重复读取和无限期保留
分布式系统 集群 可以灵活伸缩 内部复制数据，提升容错能力和高可用性
支持实时流式处理


副本分布策略

副本因子（副本数）不能大于 Broker个数
第一个分区（编号为0）的第一个副本位置 从 brokerList 随机选择
其他分区第一个副本位置依次往后移

假设 5 个 Broker，5 个分区，第一个分区 P0 放在第四个 Broker 上 B3，
那么 第二个分区将会放在第五 个 Broker 上  B4 ；第三个分区将会放在第一个 Broker 上 B0 
第四个分区将会放在第二个 Broker 上  B1

P0 P1 P2 P3 P4
B3 B4 B0 B1 B2

剩余的副本相对于第一个副本放置位置 由 nextReplicaShift 决定，这个数随机产生


分区目录分布策略

log.dirs  数据存放目录
可以配置多个目录 逗号分隔 分布在不同的磁盘提升读写性能

会在分区目录最少的文件夹中创建新的分区目录  注意 不是磁盘使用量最少的目录 ！！！

分区目录名 = Topic名+分区ID

partition 数据存储

topic 的多个 partition 以文件夹的形式保存到 broker 
分区序号从0开始

Partition 文件下有多个 segment（xxx.index，xxx.log）

segment 文件大小可配置 默认为 1g
新的 segment 以上一个 segment 最后一条消息的偏移量命名

ack 机制

request.required.acks  三个值 0 1 -1

0 不等待 broker 的 ack，这个延迟最低 
1 等待 leader 副本确认 

-1  所有的 follower 副本 ack 之后 ，leader ack


分区内消息有序

数据分布策略

消息 （key，value）  
key 用于分区