@startuml

title: ReplicaManager#appendRecords

actor ReplicaManager as ReplicaManager

alt requiredAcks值合法

ReplicaManager -> ReplicaManager : 写入消息集到本地日志

ReplicaManager -> ReplicaManager : 构建写入结果状态

alt 等待其他副本完成写入

ReplicaManager -> ReplicaManager : 创建延时请求对象

ReplicaManager -> ReplicaManager : 交由 Puratory 管理

else

ReplicaManager -> ReplicaManager : 调用回调逻辑

end

else requiredAcks值非法

ReplicaManager -> ReplicaManager : 构造特定异常对象

ReplicaManager -> ReplicaManager : 封装进回调函数执行

end

@enduml

kafka高性能原理

       最近翻了下kafka官方关于kafka设计的文档，面试上用，这里就总结下自己了解到的kafka设计上支持那么大吞吐量的原因

消息传递及存储

       从上层设计来说，kafka的生产者支持批量发送消息（可以设置发送的内容最大大小和最长等待时间）当这些批量的消息到达kafak的broker上后会通过硬盘的线性写操作将日志记录进硬盘，这种操作的速度是很快的（中间也涉及到操作系统的pagecache，kafka也可以设置这种缓存刷盘的频率比如：一秒刷一次，每条消息刷一次，按照操作系统的配置去刷），这个是说从生产者发送消息给broker很快，那么消费者消费速度呢？kafka在消费上使用pull的方式去主动向broker节点请求获取消息，而具体的offset是由消费者去指定的（这个offset其实broker上也有维护一份，但是我理解的是拉取offset的决定权是掌握在消费者手里的，只不过如果消费者挂了后，其他替代的消费者如何知道原来的offset呢，那就需要broker也存一份），Kafka底层是通过linux的sendfile函数直接将消息存储的消息内容转发到网络的socket buffer然后在copy到NIC buffer发送到网络上。这个用到的是零拷贝技术，而正常的情况是需要以下几步：

      而kafka消费方式是通过消费者拉取的方式而消费者可以根据自己的消费速度批量拉取消息，消息又都是顺序读，所以kafka在发送消息给消费者的时候速度也很快。同时，kafka也支持数据的压缩，这种压缩的数据在生产者，broker，消费者都是一致的可以直接传输。

集群

       说到大吞吐量必须也得涉及到kafka集群，现将Kafka集群我认为的重点知识记录如下：

       主要涉及两个方面吧，**一个是多boker节点，一个是主从复制**。Kafka使用多croker节点来进行负载均衡，而生产者按照topic发送消息到broker的规则可以选用轮询或者指定规则，消费者按照group进行消费，每个group中只会有一个消费者消费同一条消息，如果同一个group中有消费者挂了，那么这个消费者对应消费的broker也会分配到同一个group中的其他消费者上。但是如果broker挂了呢？这就需要用到kafka的主从节点设置了。其实broker的从节点数据同步方式跟普通的消费者没什么区别，而在同步数据的时候主节点会维护一套ISR节点群，在这个节点群的从节点，kafka认为他们的数据是比较完整的，如果主节点挂了之后，这些从节点的任意一台节点都可以替换主节点。那么怎么保证一个消息会被同步到从节点了呢，这个可以在生产者配置acks=0,1,-1来决定一条消息只有在收到多少个从节点的确认后才算真正的落地成功，当选择-1的时候那么在ISR集合中的所有节点都要收到这条消息并返回确认后，这条消息才算发送成功，这个时候延迟也会比较高，所以可以根据线上系统的特点来综合判断这个配置如何设置。