Kafka作为消息引擎系统，也是分布式流处理平台。本系列默认介绍的Kafka即为Apache Kafka
引用ApacheKafka官方的一句话介绍：Apache Kafka is an event streaming platform.
一个典型Kafka集群 = ProducerGroup + BrokerGroup+ ConsumerGroup + ZookeeperGroup。
Kafka有哪些主要的组成部分
- Broker：消息中间件处理节点。一个Kafka集群由多个broker组成，一个进程开一个broker。为了保证高可用,broker以机器为单位。每个broker里可以有且只有一个partition的leader,有多个follwer。
- Producer（消息生产者）：向Broker发送消息的客户端。
- Consumer（消息消费者）：从Broker读取消息的客户端，Consumer是通过offset进行标识消息被消费的位置。
其他概念性组成： 4.Topic:发布到Kafka集群的消息分类。物理上不同Topic的消息分开存储，逻辑上用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处。 5. Consumer Group：消费者组内，不同消费者同时消费各自订阅主题分区的数据，实现高吞吐。kafka的topic下的一条消息，只能被同一个消费者组的一个消费者消费。 6. Partition（分区）一个topic可以有多个分区（partition）,分到多个broker上，每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每条消息都会被分配一个有序的id（offset）。逻辑上可以把partition看出很大的数组，offset就是数组元素下标，每个数组元素存着每个消息的位置信息和大小等原数据，基于内存映射到磁盘，因此查找速度O(1) 7. Offset（消息位移）：partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息 8. Replica（副本）即kafka的同一条消息可以拷贝到多个地方提供数据冗余，这些地方叫副本。当集群某个节点故障时，该节点的partitiion数据不丢失。副本数设置参数： 9. Rebalance：消费集群中，消费者变化，所有消费者实例会重分配订阅主题分区的过程。是Kafka消费者端实现高可用的重要手段。
Kafka特性
Kafka在设计之初就旨在提供三个方面的特性：
- 提供一套API实现生产者和消费者；
- 降低网络传输和磁盘存储开销；———— 快速持久化、零拷贝技术
- 实现高伸缩性架构。——————分区机制（Partition）、完全的分布式系统
从中我们可以窥探出一些KafKa的设计思想： 消息状态： 在Kafka中，消息是否被消费的状态保存在Consumer中，Broker不会关心消息是否被消费或被谁消费，Consumer会记录一个offset值（指向partition中下一条将要被消费的消息位置），如果offset被错误设置可能导致同一条消息被多次消费或者消息丢失。 快速持久化：可以在 O(1) 的系统开销下，将消息持久化到本地日志文件中。 高吞吐、批量发送： Kafka支持以消息集合为单位进行批量发送，以提高效率。在一台普通的服务器上既可以达到10W/s的吞吐速率 Push vs. Pull： Kafka中的Producer和Consumer采用的是Push-and-Pull模式，即Producer向Broker Push消息，Consumer从Broker Pull消息。Push 模式的目标是尽可能以最快速度传递消息，但是这样很容易造成 Consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而Pull 模式则可以根据Consumer 的消费能力以适当的速率消费消息。对于Kafka而言，Pull 模式更合适。Pull 模式可简化 Broker 的设计，Consumer可自主控制消费消息的速率，同时Consumer可以自己控制消费方式（即可批量消费也可逐条消费），同时还能选择不同的提交方式从而实现不同的传输语义。 分区机制（Partition）： Kafka的Broker端支持消息分区，Producer可以决定把消息发到哪个Partition，在一个Partition中消息的顺序就是Producer发送消息的顺序，一个Topic中的Partition数是可配置的，Partition是Kafka高吞吐量的重要保证。 完全的分布式系统： Broker、Producer和Consumer都原生自动支持分布式，自动实现负载均衡
- 零拷贝技术(zero-copy)：减少IO操作步骤，提高系统吞吐量
特别之处
1.Kafka的follower副本,为什么不像MySQL一样对外提供读服务？
首先要清楚，MySQL的副节点提供读服务（或称读写分离）是为了减轻主节点的负载压力，这一点在Kafka采用分区方式，一个消息可以由多个broker上的partition处理。MysQL读写分离的风险是主从延迟会导致数据不一致。如果KafKa的追随者副本提供读服务一样会出现这个问题。举个例子：消费者从p0和p1两个节点获取topicA的消息，P0有某条消息而P1还没同步到，此时消费者先消费p0后消费P1则会出现乱序。
【未完待续】
