简介
Kafka 是由 linkedin 领英在 2010 年开发的消息系统。后来给 apache 开源了，由 scala 和 java 编写，该项目的目标是为处理实时数据提供一个统一的，高吞吐的，低延迟的平台
kafka 持久化的本质是一个按照分布式事务日志架构的大规模发布/订阅消息队列，这使得它很利于做企业的基础设置来处理流式数据
kafka 是一个消息中间件，可以作为消息队列
名词术语
- Topic：主题，用来对消息进行分类，每个进入 kafka 的消息都会被归类到一个 topic 下
- Partition：分区，每个 topic 主题会有若干个分区，用来提高消息的处理效率
- Broker：代理，用来实现数据存储的主机服务器
- Producer：生产者，消息的生产者
- Consumer：消费者，消息的消费者
- Consumer Group：消费者组，消息的消费者组成的组
一些解释
可以先了解下发布订阅者模型，然后再来看 kafka
topic 下多 partition
每个 topic 中可以划分多个分区，同一 topic 下不同分区消息不同，kafka 可以保证同一分区内的消息是有序的，但是无法保证不同分区的消息是有序的
每条消息发送到 broker 代理机上，会根据 partition 规则来选择存储到哪个 partition 上，如果 partition 设置合理的话，所有的消息会均匀的分布在不同的 partition 上
打个比方，比如创建了一个 topic 叫 test，其有 3 个 partition，在 kafka 的数据目录中我们能看到/tmp/kafka-log中会有 3 个目录，分别是test-0，test-1，test-2
kafka 中的消息
消息是 kafka 中基本数据单元，kafka 中一条消息由 kv 构成。当我们发送一条消息时候我们指定 key，kafka 根据 key 和 partition 机制判定当前这条消息应该发送并存储到哪个 partition 中
详细讲解
kafka 模型：生产者向 kafka 发送消息，消费者监听 kafka 来接收消息
当然一个服务也可以同时成为生产者和消费者
topic A 是生产者发送消息的目标地址，同时也是消费者监听的目标
一个 topic 是由多个 partition 分区构成的，这样是方便 topic 扩展功能，就像下图中两个管道一样。生产者发送消息给 topic，topic 的某个分区回去接收这个消息（由 topic 决定哪个分区接收消息，默认采用轮询策略）。但是消费监听的是 topic A 的所有分区
由 topic 决定消息进入哪个管道（partition 分区），默认采用轮询策略，同分区内消息是有序，不同分区消息的顺序无法判定，有时候可以配置 topic 让同类型消息走一个 partition，这样就能识别识别先后
我们看到生面这些逻辑结构，但是实际的物理存储又是怎样的呢？假如我们有如下两个 topic，每个 topic 有两个分区
实际物理上的存储是如下的，topic A 会把 #1 分区拷贝多份放在不同 node 物理机上，目的是增强其可靠性，万一一台 node 挂了其他的还能用，所以这些 #1 中 ZooKeeper 会指定一个 leader 主分区，其他都为辅的 #1 分区，leader 主要做消息收发，以及同步其他辅助分区的作用，这样 topic A 中 #1 就都含有了消息数据
然后 kafka 中存在多个 topic，在物理机中的存储是怎样的呢？可以看到下图，包含了 topic A（含有两个分区），topic B（含有两个分区），可以发现 topic A 的两个分区在物理机上并不是说分区 1 和分区 2 都必须要在同一个 node 上，对于 topic A 来讲只要能保证至少有一个 #1 在某个 node 上，#2 也在某个 node 上，其他的分区只不过是 follower，topic B 也是类似。不过注意最好不要让 topic A 的 #1 的 leader 和 #2 的 leader 出现在同一 node 上，否则一个 node 挂掉就比较麻烦了，leader 尽量分 node 存放
