实习项目中使用到，学习一下。
一些概念
消息
Kafka 的数据单元被称为消息。（理解上类似于数据库中的一条记录）消息由字节数组组成，本身对于Kafka来说没有特殊含义。
键
消息可有一个可选的元数据，也就是键。键同样也是一个字节数组，对Kafka来说也没有特殊含义。当消息以一种可控的方式写入不同分区时，会用到键。最简单的例子就是为键生成一个一致性散列值，然后使用散列值对主题分区进行取模，为消息选取分区。这样可以保证具有相同键的消息被写到相同的的分区。（理解上类似于HashMap中put的过程）
批次
为了提高效率，消息分批写入Kafka。每一个批次就是一组消息，这些消息属于同一个Topic和Partition。如果每一条消息都单独穿行于网络，会导致大量网络开销，造成网络拥塞。不过，这也要在时间延迟和吞吐量之间作出权衡：一个批次内消息数目越多，单位时间内要处理的消息就越多，单个消息的传输时间就越长。批次数据被压缩，可以提升数据的传输和存储能力，但要做额外的计算处理。（理解上类似于TCP发送端的优化算法，将多个数据包合在一起发生，那么Kafka是否也会导致粘包问题？？）
消息模式
由于对于Kafka来说，消息是晦涩难懂的字节数组，所以用一些额外的结构来定义消息内容，更容易理解，根据应用程序的需要，消息模式有很多选项可选。例如JSON、XML、Avro(Apache提供，一种紧凑的序列化格式，模式和消息体分开，模式发生变化，不需要重新生成代码；还支持强类型和模式进化，版本向前向后均兼容)等。
主题(Topic)和分区(Partition)
消息通过主题进行分类。（理解上就是数据库中的表）主题被分为若干个分区，一个分区就是一个提交日志。消息以追加的方式写入分区，先入先出的顺序读取，但是无法保证在整个Topic上的顺序。每一个分区都可以分布在不同的服务器上，这样，一个主题就可以横跨多个服务器，提供更强大的性能。
流
一般将一个主题不管有多少分区，都将其数据作为一个流。流是一组从生产者移动到消费者的数据。与Hadoop被设计用于在稍后某个时刻离线处理大量数据不同，流式处理用于实时处理。
生产者和消费者
Kafka的客户端就是Kafka系统的用户，被分为两种基本类型，生产者和消费者。
生产者创建消息，一般情况下，生产者默认会把消息均衡地分布到主题地所有分区上，而不关心特定消息会被写到哪个分区。当然，通过消息键和分区器可以将消息映射到指定的分区上。
消费者读取消息，消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。消费者通过检验消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，是一个不断递增的整数值，创建消息时，Kafka会将偏移量添加到消息中，在给定的分区中，每个消息的偏移量都是唯一的。消费者将每个分区最后读取的消息的偏移量保存在ZK或者Kafka上，如果消费者重启或者关闭，消息的读取状态也不会丢失。（这也是Kafka高可靠性的一点，即使一个主分片宕机后，Kafka客户端可以从副分片相应位移后继续消费，不会有重复消费的情况）
消费者群组(Group)
消费者是消费者组群的一部分，也就是存在多个消费者读取同一个Topic的情况。需要注意的是，一个Topic内的每个分区只能被同一个Group内的一个消费者使用，这种映射关系被称为消费者对分区的所有权关系。
通过这种方式，消费者可以消费包含大量消息的主题。而且，如果一个消费者失效，群组里的其他消费者可以接管失效悄费者的工作。
Broker
Kafka 集群包含一个或多个服务器，一个独立的服务器节点被称为broker。
broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个broker 可以轻松处理数千个分区以及每秒百万级的消息量。
broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。
broker 是集群的组成部分。每个集群都有一个broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。控制器负责管理工作，包括将分区分配给broker 和监控broker。在集群中， 一个分区从属于一个broker, i亥broker 被称为分区的首领。
保留消息
Kafka broker 默认的消息保留策略是这样的：要么保留一段时间（比如7 天），要么保留到消息达到一定大小的字节数（比如1GB ）。当消息数量达到这些上限时，旧消息就会过期井被删除，所以在任何时刻， 可用消息的总量都不会超过配置参数所指定的大小。主题可以配置自己的保留策略，可以将悄息保留到不再使用它们为止。例如，用于跟踪用户活动的数据可能需要保留几天，而应用程序的度量指标可能只需要保留几个小时。可以通过配置把主题当作紧凑型日志， 只有最后一个带有特定键的消息会被保留下来。这种情况对于变更日志类型的数据来说比较适用，因为人们只关心最后时刻发生的那个变更。（这也是与RabbitMq不同之处之一，RabbitMq消息被消费完之后直接删除）
多集群
随着Kafka 部署数量的增加，基于以下几点原因，最好使用多个集群。
- 数据类型分离
- 安全需求隔离
- 多数据中心（灾难恢复）
如果使用多个数据中心，就需要在它们之间复制消息。不过， Kafka 的消息复制机制只能在单个集群里进行，不能在多
个集群之间进行。
Kafka 提供了一个叫作Mirror Maker 的工具，可以用它来实现集群间的消息复制。
Mirror Maker 的核心组件包含了一个生产者和一个消费者，两者之间通过一个队列相连。消费者从一个集群读取消息，生产者把消息发送到另一个集群上
Kafka优势
多个生产者
Kafka 可以无缝地支持多个生产者，不管客户端在使用单个主题还是多个主题。
多个消费者
Kafka 也支持多个消费者从一个单独的消息流上读取数据，而且消费者之间直不影响。这与其他队列系统不同，其他队列系统的消息一旦被一个客户端读取，其他客户端就无法再读取它。另外，多个消费者可以组成一个群组，它们共享一个消息流，并保证整个群组对每个给定的消息只处理一次。
数据持久化
这要归功于Kafka 的数据保留特性。消息被提交到磁盘，根据设置的保留规则进行保存。每个主题可以设置单独的保留规则，以便满足不同消费者的需求，各个主题可以保留不同数量的消息。
- 消费者可能会因为处理速度慢或突发的流量高峰导致无陆及时读取消息，而持久化数据可以保证数据
不会丢失。 - 消费者可以在进行应用程序维护时离线一小段时间，而无需担心消息丢失或堵塞在生产者端。
- 消费者可以被关闭，但消息会继续保留在Kafka 里。消费者可以从上次中
断的地方继续处理消息。
伸缩性
Kafka 从一开始就被设计成一个具有灵活伸缩性的系统。随着需求不断增长，可以灵活方便增加broker。
高性能
通过横向扩展生产者、消费者和broker, Kafka 可以轻松处理巨大的消息流。在处理大量数据的同时，它还能保证亚秒级的消息延迟。
注：转载文章请注明出处，谢谢~