Kafka 源码解析之高性能架构（零）

欢迎你们关注 github.com/hsfxuebao/j… ，但愿对你们有所帮助，要是以为能够的话麻烦给点一下Star哈

1、服务端设计

1.1服务端请求如何处理？

1.2 Reactor设计模式

1.3 高性能高并发设计

1.4 顺序读写-高性能

Kafka是将消息记录持久化到本地磁盘中的，通常人会认为磁盘读写性能差， 对Kafka性 能如何保证提出质疑。 

实际上无论是内存仍是磁盘， 快或慢关键在于寻址的方式， 磁盘分为顺序读写与随机读写， 内存也同样分为顺序读写与随机读写。基于磁盘的随机读写确实很慢， 但磁盘的顺序读写性能却很高， 通常而言要高出磁盘随机读写三个数量级， 一些状况下磁盘顺序读写性能甚至要高于内存随机读写

1.5 跳表设计

log文件：消息存储     index文件：索引信息     成对出现

1.6 稀疏索引

1.7 零拷贝

1.7.1  非零拷贝

1.7.2 零拷贝

1.8 服务端设计总结

高并发高性能的网络设计

顺序读写

跳表设计  稀疏索引  零拷贝

2、Producter设计

2.1 批处理

2.2 内存池设计

2.3 总结

批处理

内存池设计

封装同一服务器请求

3、Consumer设计

3.1 P2P模型和发布订阅模型

P2P模型： 也称点对点模型， 指同一条消息只能被一个消费者消费， 也就是说一个消息若是被这个消费者 消费了， 其他的消费者就都不能消费了， 传统的消息系统用的就是这种方式。

 发布订阅模型： 容许消息被多个Consumer消费， 可是一个Consumer须要订阅主题的全部分区。

3.2 Consumer Group设计

同一个消费组是P2P方式，一个消费只能被同一个组的一个消费者消费

不一样组是订阅模式，一个消息能够被不一样的消费组消费

一个分区同一时间只会被同组一个消费者消费

3.3 偏移量存储

3.3.1 老版本架构方案（0.8版本）

ZK不擅长高并发操做

ZK不适合高频读写操做

3.3.2 新版本的架构方案

kafka自然的支持高并发、高可用、高性能

3.4 总结

Consumer Group 的设计

偏移量存储改造