整体架构
1.生产者
RecordAccumulator：内部有一个BufferPool，用来实现ByteBuffer的复用和实现缓存。BufferPool只针对特定大小的ByteBuffer进行管理，由batch.size指定，默认值16384B，即16KB。消息大小超过batch.size，创建的ProducerBatch，这段内存区域不会被复用。
InFlightRequests：缓存已经发出去但还没有收到响应的请求
2.消费者
消费组：消息发布到主题后，只会被投递给订阅它的每个消费组中的一个消费者;对于分区数固定的情况，一味地增加消费者并不会让消费能力一直得到提升，如果消费者过多，消费者的个数大于分区个数的情况，就会有消费者分配不到任何分区
分区分配策略
RangeAssignor分配策略
假设n=分区数/消费者数，m=分区数%消费者数量，那么前m个消费者每个分配n+1个分区，后面的（消费者数量-m）个消费者每个分配n个分区。
RoundRobinAssignor分配策略：依次轮询分配给每个消费者
StickyAssignor分配策略：在消费者数量发生变化后，尽量跟之前保持一致
自定义分区策略：PartitionAssignor
3.Broker 服务代理节点。
主题与分区
主题：主题是逻辑概念
分区：一个主题横跨多个broker 一个分区只属于一个主题
副本：同一分区的副本保存相同的消息
主副本负责读写
从副本负责与主副本间同步
Kafka通过多副本机制实现了故障的自动转移，当Kafka集群中某个broker失效时仍然能保证服务可用。Broker上的数据存储格式
存储：
磁盘存储
磁盘页缓存
磁盘IO流程
零拷贝: 所谓的零拷贝是指将数据直接从磁盘文件复制到网卡设备中，而不需要经由应用程序之手。
存储格式
清理规则
（1）日志删除（Log Retention）：按照一定的保留策略直接删除不符合条件的日志分段。(时间,日志大小,日志起始偏移量)
（2）日志压缩（Log Compaction）：针对每个消息的key进行整合，对于有相同key的不同value值，只保留最后一个版本。 Kafka会定期将相同key的消息进行合并，只保留最新的value值。
在Kafka的日志管理器中会有一个专门的日志删除任务来周期性地检测和删除不符合保留条件的日志分段文件，这个周期可以通过broker端参数log.retention.check.interval.ms来配置，默认值为300000，即5分钟
快速检索
高可靠：多副本
使用中一些问题：
Kafka 没有租户概念，需要手动维护多个集群，不方便运维。
Kafka 集群扩容后需要做 Reassign Partitions，IO 消耗大。
Kafka 监控体系不完善，排查问题较为繁琐。
在线业务消息重置不方便，实现起来较为麻烦，需要停掉消费组。
Kafka 不支持死信队列和延迟队列。
Kafka 没有官方维护和支持的 Go 语言客户端。
在 Kafka 中支持 schema，需要引入额外组件，不方便维护。
可灵活扩容的消息中间件 pulsar pulsar.apache.org/
