另一方面，Kafka Apache Kafka是用Scala和Java语言编写的，能够将消息从一个端点传递到另一个端点，是快速、可扩展、吞吐量高、容错的分布式“发布-订阅”
1.http://www.Sina.com/kafka可以被认为是专用于高性能、低延迟提交日志存储、复制和分发的分布式文件系统。
2. Kafka 作为存储系统Kafka的消费群体概念概述了这两个概念。 与队列一样，使用者组可以将进程拆分为一组作为使用者组成员的进程。 与订阅一样，Kafka可以向多个消费群体广播邮件。
在3. Kafka 作为消息传递系统Kafka中，流处理器是从输入主题获取连续数据流，对输入执行某些处理，以产生连续数据流并输出主题的处理器。
二、Kafka体系结构体系1 .物理模型
2 .逻辑模型
3 .体系结构
三、概念1. Broker (节点) Kafka集群包括一个或多个服务器，每个服务器节点被称为一个Broker。
Broker保存主题的数据。 如果一个Topic有n个Partition，而集群中有n个Broker，则每个Broker存储该Topic的一个Partition。
如果一个Topic有n个Partition，集群中有(N M )个Broker，其中n个Broker存储该Topic的一个Partition，其余m个Broker为该Topic的partition dediex
如果一个Topic具有n个Partition，并且集群中的Broker的数目小于n，则一个Broker存储该Topic的一个或多个Partition。 在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据的不均衡。
2. Topic )主题在Kafka中按主题对邮件进行分类，每个主题都有Topic Name。 生产者根据Topic Name向特定的Topic发送消息，消费者也根据Topic Name从对应的Topic中消费。
Topic相当于消息的分类标签，是逻辑概念。
物理上不同的Topic消息分别存储，逻辑上一个Topic消息存储在一个或多个中介中，但用户只需指定消息的Topic即可生产或消耗数据，而无需考虑数据存储在何处
3. Partition :分区Topic中的消息被拆分为一个或多个分区。 这是一个物理概念，对应于系统上的一个或多个目录。
分区内部的消息是有序的，但分区之间的消息是无序的。
主题是消息分类的一个单位，但每个主题可以进一步细分为一个或多个分区，一个分区只能属于一个主题。
主题和分区是逻辑概念。 例如，消息1和消息2被发送到主题1，可以进入同一分区或进入不同的分区。 因此，同一主题下的不同分区中包含的消息不同。 然后发送到分区对应的Broker节点。
4. Offset (偏移)分区可以视为只有一个分区中的消息有序。 Kafka在此队列的末尾添加一条消息，每个消息进入分区时，都会有一个偏移量，用于标识消息在该分区中的位置。 消费者消费的消息通过偏移量来识别。
5. Segment部分将分区进一步细分为几个Segment，每个Segment文件的大小相同。
6. Producer :生产者是消息的发布者，生产者向选定的主题发布数据。 生产者选择将哪个记录分配给主题的哪个分区。 也就是说，生产者生产的消息会写入某个Partition中。
7. Consumer :消费者可以从中介读取消息。 允许一个消费者同时在一个Partiton上消费多个主题消息，一个消费者可以在同一个Topic上消费多个分区消息。
8 .消费者组消费者组是Kafka提供的可扩展和容错的消费者机制。 组内有多个消费者，它们可以共享公共ID (即组ID )。 组中的所有消费者都已进行了调整，以消耗订阅主题中的所有分区。 Kafka保证，同一客户组中只有一个客户会消耗某个消息。
其实，Kafka保证了稳定的状态
下每一个 Consumer 实例只会消费某一个或多个特定的 Partition，而某个 Partition 的数据只会被某一个特定的 Consumer 实例所消费。
下面我们用官网的一张图, 来标识 Consumer 数量和 Partition 数量的对应关系。
9. Replizcas of partition：分区副本
副本是一个分区的备份，是为了防止消息丢失而创建的分区的备份。
10. Partition Leader
每个 Partition 有多个副本，其中有且仅有一个作为 Leader，Leader 是当前负责消息读写的 Partition。即所有读写操作只能发生于 Leader 分区上。
11. Partition Follower
所有 Follower 都需要从 Leader 同步消息，Follower 与 Leader 始终保持消息同步。Leader 与 Follower 的关系是主备关系，而非主从关系。
12. Broker Controller
Kafka集群的多个 Broker 中，有一个会被选举 Controller，负责管理整个集群中 Partition 和 Replicas 的状态。
只有 Broker Controller 会向 Zookeeper 中注册 Watcher，其他 Broker 及分区无需注册。即 Zookeeper 仅需监听 Broker Controller 的状态变化即可。
13. ZooKeeper
ZooKeeper 负责维护和协调 Broker，负责 Broker Controller 的选举。在 Kafka 0.9 之前版本，Offset 是由 ZooKeeper 负责管理的。
总结：ZooKeeper 负责 Controller 的选举，Controller 负责 Leader 的选举。
三、Kafka 的应用场景
四、Kafka 高可用
1. 副本
在0.8版本后引入副本则很好地解决宕机后数据丢失的问题。
副本是以Topic中每个Partition的数据为单位，每个Partition的数据会同步到其他物理节点上，形成多个副本。
每个Partition的副本都包括一个Leader副本和多个Follower副本，Leader由所有的副本共同选举得出，其他副本则都为Follower副本。
在生产者写或者消费者读的时候，都只会与Leader打交道，在写入数据后Follower就会来拉取数据进行数据同步。
2. 当某个Broker挂掉了？
甭担心，这个Broker上的Partition在其他Broker节点上还有副本。
3. 如果挂掉的是Leader怎么办？
那就在Follower中在选举出一个Leader即可，生产者和消费者又可以和新的Leader愉快地玩耍了，这就是高可用。
4. 多少个副本才算够用？
副本肯定越多越能保证Kafka的高可用，但越多的副本意味着网络、磁盘资源的消耗更多，性能会有所下降，通常来说副本数为3即可保证高可用，极端情况下将replication-factor参数调大即可。
5. Follower和Lead之间没有完全同步怎么办？
Follower和Leader之间并不是完全同步，但也不是完全异步，而是采用一种ISR机制（In-Sync Replica）。
每个Leader会动态维护一个ISR列表，该列表里存储的是和Leader基本同步的Follower。
如果有Follower由于网络、GC等原因而没有向Leader发起拉取数据请求，此时Follower相对于Leader是不同步的，则会被踢出ISR列表。
所以说，ISR列表中的Follower都是跟得上Leader的副本。
6. 一个节点宕机后Leader的选举规则是什么？
分布式相关的选举规则有很多，像ZooKeeper的Zab、Raft、Viewstamped Replication、微软的PacificA等。
而Kafka的Leader选举思路很简单，基于我们上述提到的ISR列表，当宕机后会从所有副本中顺序查找，如果查找到的副本在ISR列表中，则当选为Leader。
另外还要保证前任Leader已经是退位状态了，否则会出现脑裂情况（有两个Leader）。
7. 怎么保证不会有2个leader？
Kafka通过设置了一个controller来保证只有一个Leader。
https://mp.weixin.qq.com/s/R1en4V0Tlwlpt102BjotoA
因为一次 Kafka 宕机，我明白了 Kafka 高可用原理！
https://mp.weixin.qq.com/s/1-GpycMKdcgCjs1tSOg1Kg