设计的动机: 能够作为一个统一的可以处理一家大公司可能有的所有实时数据的平台。

要做到这一点，我们需要考虑一个相当广泛的使用场景：

根据这些需求和目标，形成了 kafka 的分区模式和消费者模式， 同时加入了一些新的元素。因此，比起传统的消息系统，kafka 更像一个数据库日志。

• Topic是一类消息的集合，通常这些消息比较大，因此一个Topic会分成多个分区，数据按照某种规则送到各个分区上。
• 分区Partition相当与Topic的其中一个队列，到达同一个分区上的消息有一个偏移值，这个值会一次递增。
• 分区可以均衡各个broker之间的数据和请求压力；分摊处理不同消费者进程,使消费速度更快；每个Partition内可以保证严格的时序。
• 消息以顺序写磁盘的形式写入磁盘中，速度很快，甚至比随机写内存还快，这是kafka高吞吐的重要原因。
• 每个分区在磁盘中都是一个目录，目录下包含*.index, *.log, *.timeindex三类文件。*就是给文件第一条消息的offset。
• 由于具有持久化的功能，众多的数据不能放在一个文件中，因此每个分区的消息会分成块存成不同的文件，可以设置每个文件的大小，块文件大小到了就重新生成新的文件。
• 旧的数据可以被删除，可以配置成按照过期时间和数据大小删除。
• 创建Topic时，可以指定分成多少Partition，每个分区的复制因子是多少(不同复本在不同的broker上，因此复制因子不能超过broker个数)。
• 每个Topic的所有Partitions会分散在不同的broker上，如果是单个broker，那所有都分布在这一个broker上。
• Partition所有副本集中有一个是leader，其他是follower。follower像消费者一样从leader上拉取数据作为备份。
• Partition的复制因子为N，则可以容错N-1个broker挂掉而不丢失数据。
• 通常客户端无法控制是否新建topic，kafka查看其设置auto.create.topics.enable和num.partitions来自行处理是否新建topic以及topic的分区数目。

• 生产者直接将消息发送分区的leader broker，不经过任何路由层，包括zookeeper。
• 生产者确定每条消息送给那个partition，方式有round-robin，也可以根据指定的key计算哈希值让相同key的消息发送固定的分区(这适合消费着对消息位置比较敏感的场合)。
• 为了方便producer做到上面的功能，所有的kafka brokers都会回复Producer对分区元数据的请求。Producer得到分区的元数据就知道直接将数据送给那个broker了。
• 可以选择数据批处理功能，这是kafka高性能的一个原因，这样kafka可以将数据放在内存中，等数据累积的大小或者时间足够大再一起打包发往kafka，这样可以大大的减小服务器的I/O操作。因此，需要再节省服务器IO操作和实时性之间做出选择。
• 生产者使用push方式主动向kafka推送数据，而消费者以Pull的方式根据自己的消费能力向broker拉取数据。

• 和mqtt一样，消息有三种保证：最多投递一次(可能丢失，不会重新投递)；至少投递一次（不会丢失，且有可能重复）；有且仅有一次(不会丢失且只有一次).
• Publish的消息有committed的概念，committed的消息是只要复制该分区的broker有一个alive(broker alive的定义在后面)，这条消息就不会被丢失, 也可以说是这些消息已经到达了所有的ISR。
• 虽然定义的committed消息是所有ISR都复制了这条消息，但是考虑实时性等性能问题，producer往往设置只要收到几个ISR的ack就算这条消息已经圆满到达了。默认是ack=all。
• 想想一种场景：消息发往kafka时发生网络问题；消息committed之后发生网络问题。这样都不确定是否执行成功。
• 消息保证通用的逻辑是：要确保这个需要接收者给发送这一个确认信息。qos=1的逻辑是发送者暂时保留消息如果一定时间内没有收到接收者确认信息就重发; qos=2的逻辑是发送者收到接受者将消息投递给下一级用户之后的回复再删除。
• [对于Producer]：这种保证带来了很大的延时和性能问题，不是特别严格的场合不需要使用。因此需要producer指定是否需要这种保证，和等待确认的时间。
• [对于Consumer]：消费者有消费的偏移值，消费者正常时将这个值保存内存中，消费者挂了后，如果另起一个进程消费该如何确定消费的偏移？该怎么做呢？有一下选择：
• 选择1：消费者读取数据之后，将消费的offset保存在log里再处理数据，后面启动的进程读取该log，接着上次消费的数据消费，这是at-most-once清醒，因为没有处理就已经把offset保存到log了，如果消息处理失败就不会重复消费这条消息了。所有启动Kafka的时候我们会看到自动创建的topic：__consumer_offsets。
• 选择2：消费者读取数据之后，处理完数据之后再将将消费的offset保存在log，这样确保保存offset的消息一定是被处理过的。
• qos=2的情况，kafka还没有实现。
• 消息的offset，之前保存在zookeeper中，现在建议保存在kafka中。java的consumer API可以设置offsets.storage指定。

• 分区的副本因此在创建topic的时候指定。
• 保存同一分区的broker集合有不同的角色，leader，replicas和isr。
• leader是分区负责读写的broker，每个broker都可能是某些分区的leader，也可能是某些分区的副本broker。
• replicas是复制该分区数据的所有broker，不管这个broker是否alive，也包括这个分区的leader。
• isr(in-sync)是当前活着并且数据跟上leader的所有节点。复制的数据是否跟上leader。
• alive broker要满足两个条件：broker必须和zookeeper建立session，进而实现心跳机制；如果是slave，复制leader的数据不能差的太远，通过replica.lag.time.max.ms配置。满足这两个条件的就是in-snyc的node(ISR)，这样区别alive/failed的模糊概念。
• leader会跟踪Partition的ISR集合，如果ISR里面某个挂了，或者数据复制落后太多，leader会将其从ISR列表中删除。
• 配置brokers优雅关闭，一个broker fail之后需要选出以该broker作为leader的分区的新leader，优雅的关闭有这些好处：同步所有数据到disk，避免重启之后进行任何log恢复，log恢复会花费很长的时间，所以同步数据可以使重启更块；关闭之前会迁移作为leader的分区的数据到其他replicas，这样能加快新的leader转移, 减小分区不可用的时间到几ms。前者会再服务给stop（不是强制关闭）前自动执行，后者由controlled.shutdown.enable=true(默认就是true)设置。
• 有一个preferred replicas（优先副本）的概念, ISR里的第一个就是优先副本。一个服务器挂了，新的leader会选出来，挂了的服务器恢复之后也只能做follower，不能进行读写了，这样会造成imbalance，可以通过执行下面的脚本重新恢复preferred replicas: bin/kafka-preferred-replica-election.sh --zookeeper zk_host:port/chroot 执行上述指令很麻烦，可以设置服务器参数auto.leader.rebalance.enable=true实现自动平衡。