Apache Kafka 是一款开源的消息引擎系统，也是分布式流处理平台，使用的是纯二进制的字节序列。
kafka术语
Topic: 发布订阅的对象是主题（Topic） 生产者程序通常持续不断地向一个或多个主题发送消息
Producer: 向主题发布消息的客户端应用程序称为生产者（Producer）
Consumer: 订阅这些主题消息的客户端应用程序就被称为消费者（Consumer）
Broker: Kafka 的服务器端由被称为 Broker 的服务进程构成，即一个 Kafka 集群由多个 Broker 组成，Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。虽然多个 Broker 进程能够运行在同一台机器上，但更常见的做法是将不同的 Broker 分散运行在不同的机器上，这样如果集群中某一台机器宕机，即使在它上面运行的所有 Broker 进程都挂掉了，其他机器上的 Broker 也依然能够对外提供服务。这其实就是 Kafka 提供高可用的手段之一。分区的leader副本只存在于其中一个broker中
实现高可用的另一个手段就是备份机制（Replication）。备份的思想很简单，就是把相同的数据拷贝到多台机器上，而这些相同的数据拷贝在 Kafka 中被称为副本（Replica）。
副本：Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。
Kafka 定义了两类副本：领导者副本（Leader Replica）和追随者副本（Follower Replica）。前者对外提供服务，这里的对外指的是与客户端程序进行交互；而后者只是被动地追随领导者副本而已，不能与外界进行交互。
副本的工作机制：生产者总是向领导者副本写消息；而消费者总是从领导者副本读消息。至于追随者副本，它只做一件事：向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步。通过副本选举实现故障转移。
分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区。（修改分区数一定要比原有分区数大）一个topic 可以拥有若干个partition（从 0 开始标识partition ），分布在不同的broker 上， 实现发布与订阅时负载均衡。producer 通过自定义的规则将消息发送到对应topic 下某个partition，以offset标识一条消息在一个partition的唯一性。
一个partition拥有多个replica，提高容灾能力。
**Kafka 中的分区机制 **指的是将每个主题划分成多个分区（Partition），每个分区是一组有序的消息日志。生产者生产的每条消息只会被发送到一个分区中
在Kafka中，一个Partition对应物理机器上的一个文件夹，文件夹命名会以Topic名称加序号表示。换句话说，Partition在Broker中以文件夹的形式存在。每个Partition文件夹中会有多个大小相等的日志段文件（Segment File），消息生产者生产的消息发送到Broker后就会以追加到日志文件末尾的方式持久化到Partition中。
如果在Kafka运行时调整Topic的Partition数量，会直接影响Message根据Key的顺序问题。如果调整Replication数量，会给集群带来较大的性能压力，因为涉及到Zookeeper要重新选举Leader一系列操作。
副本如何与这里的分区联系在一起呢？
实际上，副本是在分区这个层级定义的。每个分区下可以配置若干个副本，其中只能有 1 个领导者副本和 N-1 个追随者副本。生产者向分区写入消息，每条消息在分区中的位置信息由一个叫位移（Offset）的数据来表征。分区位移总是从 0 开始，假设一个生产者向一个空分区写入了 10 条消息，那么这 10 条消息的位移依次是 0、1、2、…、9。
消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。
Kafka 的三层消息架构：
第一层是主题层，每个主题可以配置 M 个分区，而每个分区又可以配置 N 个副本。
第二层是分区层，每个分区的 N 个副本中只能有一个充当领导者角色，对外提供服务；其他 N-1 个副本是追随者副本，只是提供数据冗余之用。
第三层是消息层，分区中包含若干条消息，每条消息的位移从 0 开始，依次递增。
Kafka体系架构 = M个producer +N个broker +K个consumer+ZK集群
消费者组：Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。
重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。
一个topic 可以让若干个consumer消费，若干个consumer组成一个 consumer group ，一条消息只能被consumer group 中一个consumer消费，若干个partition 被若干个consumer 同时消费，达到消费者高吞吐量
当创建topic的时候Kafka会保证所有副本均匀地在broker上保存。
两种消息模型，即点对点模型（Peer to Peer，P2P）和发布订阅模型。这里面的点对点指的是同一条消息只能被下游的一个消费者消费，其他消费者则不能染指。在 Kafka 中实现这种 P2P 模型的方法就是引入了消费者组（Consumer Group）。所谓的消费者组，指的是多个消费者实例共同组成一个组来消费一组主题。这组主题中的每个分区都只会被组内的一个消费者实例消费，其他消费者实例不能消费它。为什么要引入消费者组呢？主要是为了提升消费者端的吞吐量。多个消费者实例同时消费，加速整个消费端的吞吐量（TPS）。另外这里的消费者实例可以是运行消费者应用的进程，也可以是一个线程，它们都称为一个消费者实例（Consumer Instance）。
消费者组里面的所有消费者实例不仅“瓜分”订阅主题的数据，而且它们还能彼此协助。假设组内某个实例挂掉了，Kafka 能够自动检测到，然后把这个 Failed 实例之前负责的分区转移给其他活着的消费者。
每个消费者在消费消息的过程中必然需要有个字段记录它当前消费到了分区的哪个位置上，这个字段就是消费者位移（Consumer Offset）。注意，这和上面所说的位移完全不是一个概念。上面的“位移”表征的是分区内的消息位置，它是不变的，即一旦消息被成功写入到一个分区上，它的位移值就是固定的了。而消费者位移则不同，它可能是随时变化的，毕竟它是消费者消费进度的指示器嘛。另外每个消费者有着自己的消费者位移，因此一定要区分这两类位移的区别。消息在分区中的位移称为分区位移，而把消费者端的位移称为消费者位移。
