Kafka背景介绍
Kafka 是由 Linkedin 公司开发的，它是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式消息流平台，它同时也是一款开源的基于发布订阅模式的消息引擎系统。
这里要注意一点，Kafka在官网的定位其实是一款流处理平台，它除了支持常见的消息队列功能之外，还支持实时计算这类能力。不过kafka在实时计算这块没有flink做的更加完善，所以用的人不是很多，大家使用Kafka更多会用于消息队列。
Kafka与Zookeeper
Kafka早期版本和zookeeper其实是需要组合使用的，不过后边的架构设计中，在逐渐的解除和zk的耦合。早期的Kafka架构设计里面，Zookeeper主要是负责管理起具体的broker机器信息。
-
Broker启动的时候，把地址注册到broker上，也就是/kafka/broker/ids目录下写入broker的id。
-
然后多个broker争先抢占zk的一个节点，在/kafka/controller目录下，抢占到该节点的broker是Leader角色（分布式锁思路），其余的是follower角色。
Kafka的消息发送和消费链路
Kafka的消息发送和消费架构其实和前边我们所讲解的两款MQ的架构有点类似，我们先来看看下图的架构链路：
当producer发送消息抵达Broker之后，Broker会将发送过来的消息存放在不同的partition模块中，这里要注意，Kafka的partition你可以理解为类似于世RocketMQ里面的CommitLog，存储实际消息的一个结构，但是它和RocketMQ的commitlog不同，Kafka不会把所有的topic信息都往一个commitlog里面去顺序写入，而是按照topic为粒度去写入。
这样设计的好处在于：多个主题，多个partition模块管理，可以让多核cpu的计算机充分发挥其性能。
在Kafka的集群架构里面，不同的Partition文件会被分散到不同的Broker上存放，这样可以让不同的机器负责不同的Partition文件写入，可以保证同一个Topic下的消息写入不会只单单受限于单台机器的硬件性能。
Kafka的消息存储原理
topic下的消息存储结构如下图所示，在一个segment下边会有.log,.index,.timestamp文件存在，Kafka里面的消息存储实际上是存在一个个不同的segment里面的。
所谓的segment其实也是一个虚拟的概念，实际映射到物理磁盘上，分成了.log,.index,.timestamp文件的组合。
- .log文件
实际的数据存储文件，顺序写入存储。
- .index文件
索引文件，里面保存了具体消息存在于.log的地址信息。
- .timestamp文件
用于记录哪些消息是7天以内的，如果超过了7天，一般消息默认会被删除。