点一下关注吧！！！非常感谢！！持续更新！！！
目前已经更新到了：
- Hadoop（已更完）
- HDFS（已更完）
- MapReduce（已更完）
- Hive（已更完）
- Flume（已更完）
- Sqoop（已更完）
- Zookeeper（已更完）
- HBase（已更完）
- Redis （已更完）
- Kafka （正在更新…）
章节内容
上节我们完成的内容：
- 生产消费结构
- Kafka 基本概念介绍
- Kafka 消费模式
- Kafka 核心API 介绍
- Kafka 优势
- Kafka 基本架构
核心概念
Producer
生产者创建消息。
该角色将消息发布到Kafka的Topic中，Broker接收到生产者的消息之后，Broker将消息追加到当前的 segment 文件中。
一般情况下，一个消息会被发布到一个特定的主题上：
- 默认情况下通过轮询把消息均衡的发布到主题的所有分区上
- 在某些情况下，生产者会把消息直接写到指定的分区，这通常是通过消息键和分区器来实现的，分区器为键的一个散列值，并将其映射到指定的分区上。这样可以保证同一个键的消息会被写到同一个分区上。
- 生产者也可以使用自定义分区器，根据不同的业务规则将消息映射到分区。
Consumer
消费者读取消息
- 消费者订阅一个或者多个主题，并按照消息生成顺序读取它们
- 消费者通过检查消息偏移量来区分已经读过的消息，偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在ZooKeeper或Kafka上。
- 消费者是消费组的一部分，群组保证每个分区只能被同一个消费者使用。
- 如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新消费。
Broker
一个独立的Kafka服务器称为Broker
- 如果某Topic有N个Partition，集群有N个Broker，每个Broker存储该Topic的一个Partition
- 如果某Topic有N个Partition，集群有（N+M）个Broker，那么其中有N个Broker存储该Topic的一个Partition
- 如果某Topic有N个Partition，集群中Broker数目少于N个，那么一个Broker存储该Topic的一个或多个Partition。在实际的生产环境中，尽量避免这种情况的发生，这种情况很容易导致Kafka集群数据不平衡。
Topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
物理上不同的Topic的消息分开存储
主题就好比数据库的表，尤其是分库分表之后的逻辑表。
Partition
- 主题可以被分为若干个分区，一个分区就是一个提交日志
- 消息以追加的方式写入分区，然后以先入先出的顺序读取
- 无法在整个主题范围内保证消息的有序，但可以保证消息在单个分区内的顺序
- Kafka通过分区来实现数据冗余和伸缩性
- 在需要严格保证消息的顺序的场景下，需要将Partition数目设置为1
Replicas
Kafka使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本，那些副本被保存在Broker上，每个Broker可以保存成百上千属于不同主题和分区的副本。
副本有以下的两种类型：
- 首领副本：每个分区都有一个首领副本，为了保证一致性，所有生产者请求和消费者请求都会经过这个副本。
- 跟随者副本：首领以外的副本都是跟随副本，跟随者副本不处理来自客户端的请求，它们唯一的任务就是从首领那里复制消息，保持与首领一致的状态。如果首领发生奔溃，其中一个跟随者就会被提升为新首领。
Offset
生产者
消息写入的时候，每一个分区都有一个Offset，这个Offset就是生产者的Offset，同时也是这个分区的最新最大的Offset。
有些时候没有指定某一个分区的Offset，这个工作Kafka帮我们完成。
消费者
这是某个分区的Offset情况，生产者写入的Offset是最新最大值12，当ConsumerA进行消费时，从0开始消费，一直消费到9，消费者的Offset就记录9，ConsumerB就记录在11。
等下一次消费的时候，他们可以选择从上一次消费的位置消费，也可以从头开始消费。
副本
Kafka通过副本来保证高可用，副本分为：首领副本（Leader）和追随者副本（Follower）。
