Kafka的主要特点：
1. 为发布和订阅提供高吞吐量，每秒可产生25万消息（50MB），每秒可处理55万消息（110MB）
2. 可进行持久化操作
3. 分布式系统，支持热扩展
4. 消息被处理的状态是consumer维护，不是server维护
5. 支持online和offline场景
Kafka架构：
分布式架构，Producer、Broker、Consumer都有多个，采用Push-and-Pull的模式，消息由Producer产生，Push进Broker，Broker起到中间缓存和分发的作用，Consumer从Broker Pull消息做处理，消息的产生和消费是异步的。
一些概念
1.Broker：Kafka集群中包含的服务器
2.Topic：每条发不到Kafka集群的消息所属的类别
3.Partition：分区，物理概念，每个topic包含一个或多个partition，Kafka同一个Partition内保证消息有序性
4.Producer：消息生产者，向Broker写消息
5.Consumer：消费者，从Broker读取消息
6.Consumer Group：每个Consumer属于一个特定的ConsumerGroup，每个分区分配给消费者组中不同的而且是唯一的消费者，并确保一个分区只属于一个消费者
7.replication：partition的副本，保障partition的高可用，同一个partition可能有多个replication，多个replication选举leader，其他replication作为folloer从leader复制数据
8.leader：replica中的一个角色，producer和consumer只跟leader交互
9.follower：replica中的一个角色，从leader中复制数据
10.controller：Kafka集群中的一个服务器，用来进行leader election以及各种failover
11.zookeeper：Kafka通过zookeeper来存储集群的meta信息
Topic和Partition
消息发送时都被发送到一个topic，其本质就是一个目录，而topic由是由一些Partition Logs(分区日志)组成,其组织结构如下图所示：
每个Partition中的消息都是有序的，生产的消息被不断追加到PartitionLog上，其中的每一个消息被赋予唯一的offset值。Kafka集群会保存所有的消息，不管消息有没有被消费，我们可以设定消息的过期时间，只有过期的数据才会被自动清除以释放磁盘空间。Kafka需要维持的元数据只有一个，消费消息在Partition中的offset值，Consumer每消费一条消息，offset值加1，Consumer可以重置offset值来读取任意位置的消息。
发布消息
producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 patition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。
消息路由：
producer 发送消息到 broker 时，会根据分区算法选择将其存储到哪一个 partition。其路由机制为：
1.指定了 patition，则直接使用。
2.未指定 patition 但指定 key，通过对 key 的 value 进行hash 选出一个 patition。
3.patition 和 key 都未指定，使用轮询选出一个 patition。
Zookeeper在Kafka中的作用
Kafka在zk中的一些存储结构
1.Broker Node的注册
当一个Kafka broker启动后，会向zookeeper注册自己的节点信息，该节点为一个临时节点，当broker断开和zookeeper的连接时，其临时节点将会被删除。
路径：/broker/ids/[0...N]
其中[0..N]表示broker id（broker id唯一，不可以重复）,znode的值为对应broker的相关信息，如下：
{
"jmx_port": -1, //JMX的端口号
"timestamp": "1460082147315",//broker启动的时间戳
"host": "xx.xxx.xxx.xxx",//host
"version": 1,//默认的版本
"port": 9092 //broker进程的对外监听的端口号
}
2.Broker Topic注册
当一个broker启动时,会向zookeeper注册自己持有的topic和partitions信息，为临时节点
路径：/broker/topics/[topic]/partitions/[0...N]
其中[0..N]表示partition索引号。其znode下的信息如下：
{
"controller_epoch": 17,//中央控制器的总的选举次数
"leader": 0, //此partition的broker leader的id
"version": 1, //默认版本号
"leader_epoch": 1,//此partition的leader选举的次数
"isr": [ 0 ] //同步副本组brokerId顺序列表
}
3.Consumer id注册
在kafka consumer的配置参数中有consumer.id，为临时节点
路径：/consumers/[group_id]/ids/[consumer_id]
{
"version": 1,
"subscription": { "user11": 1 },
"pattern": "static",
"timestamp": "1460083658252"
}{“topic_name”:#streams…},即表示此consumer目前所消费的topic + partitions列表
4.Consumer offset 跟踪
用来跟踪每个consumer group目前所消费的partition中最大的offset，此znode为永久节点
路径：/consumers/[group_id]/offsets/[topic]/[partition_id]
可以看出offset跟group_id有关,以表明当group中一个消费者失效,其他consumer可以继续消费
5.PartitionOwner注册
用来标记partition被哪个consumer消费，为临时节点
路径：/consumers/[group_id]/owners/[topic]/[partition_id]
问题：
1. Kafka如何保证消息顺序一致性？
（1）一个topic只用一个partition，不推荐
（2）使用同一个key，这样相同key的消息会落在同一个partition
2. 如何删除Kafka的旧数据？有几种方式？Kafka读取消息的时间复杂度？
（1）基于时间：log.retention.hours=168
（2）基于大小：log.retention.bytes=1073741824
3. Kafka消息消费采用什么模型？为什么使用Pull而不用Push？Pull有什么缺点，Kafka是如何解决的？
（1）Push模型很容易使得Consumer来不及处理消息，可能造成消息丢失，典型表现就是拒绝服务以及网络拥塞
（2）Pull模型，可以使消费者自主控制消费消息的速率，也可控制逐条消费或批量消费
（3）Pull模型缺点，如果没有数据，consumer会陷入无限循环中等待数据到达，为避免这种情况，pull请求中有参数，允许消费者请求在等待数据到达的长轮询中进行阻塞。
参考资料：
https://blog.csdn.net/qq_35641192/article/details/80956244
https://blog.csdn.net/taoy86/article/details/80271784
https://www.cnblogs.com/yinchengzhe/p/5111648.html
https://blog.csdn.net/ouyang111222/article/details/51094912
