扫盲Kafka，看这一篇就够了！
# 为什么要使用 Kafka 消息队列？
解耦、削峰：传统的方式上游发送数据下游需要实时接收，如果上游在某些业务场景：例如上午十点会流量激增至顶峰，那么下游资源可能会扛不住压力。但如果使用消息队列，就可以将消息暂存在消息管道中，下游可以按照自己的速度逐步处理；
可扩展：通过横向扩展生产者、消费者和broker, Kafka可以轻松处理巨大的消息流；
高吞吐、低延迟：在一台普通的服务器上既可以达到10W/s的吞吐速率；
容灾性：kafka通过副本replication的设置和leader／follower的容灾机制保障了消息的安全性。
# Kafka 的特性
高吞吐、低延迟：kakfa 最大的特点就是收发消息非常快，kafka 每秒可以处理几十万条消息，它的最低延迟只有几毫秒。
高伸缩性： 每个主题(topic) 包含多个分区(partition)，主题中的分区可以分布在不同的主机(broker)中。
持久性、可靠性： Kafka 能够允许数据的持久化存储，消息被持久化到磁盘，并支持数据备份防止数据丢失，Kafka 底层的数据存储是基于 Zookeeper 存储的，Zookeeper 我们知道它的数据能够持久存储。
容错性： 允许集群中的节点失败，某个节点宕机，Kafka 集群能够正常工作
高并发： 支持数千个客户端同时读写
# Kafka的使用场景
日志收集：一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口服务的方式开放给各种 consumer，例如hadoop、Hbase、Solr、flink等。
消息系统：解耦和生产者和消费者、缓存消息等。
用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这 些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到 hadoop、数据仓库中做离线分析和挖掘。
运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反 馈，比如报警和报告。
# Kafka基本概念
kafka是一个分布式的，分区的消息(官方称之为commit log)服务。
producer通过网络发送消息到Kafka集群，然后consumer来进行消费，如下图：
服务端(brokers)和客户端(producer、consumer)之间通信通过TCP协议来完成。
# broker
一个独立的 Kafka 服务器叫 Broker。broker 的主要工作是，接收生产者的消息，设置偏移量，提交消息到磁盘保存；为消费者提供服务，响应请求， 返回消息。在合适的硬件上，单个 broker 可以处理上千个分区和每秒百万级的消息量。
多个 broker 可以组成一个集群。每个集群中 broker 会选举出一个集群控制器。控制器会进行管理，包括将分区分配给 broker 和监控 broker。
集群里，一个分区从属于一个 broker，这个 broker 被称为首领。但是分区可以被分配给多个 broker，这个时候会发生分区复制。
集群中 Kafka 内部一般使用管道技术进行高效的复制。
# 消息和批次
消息，Kafka 里的数据单元，也就是我们一般消息中间件里的消息的概念（可以比作数据库中一条记录）。消息由字节数组组成。消息还可以包含键 （可选元数据，也是字节数组），主要用于对消息选取分区。
作为一个高效的消息系统，为了提高效率，消息可以被分批写入 Kafka。批次就是一组消息，这些消息属于同一个主题和分区。如果只传递单个消息， 会导致大量的网络开销，把消息分成批次传输可以减少这开销。但是，这个需要权衡（时间延迟和吞吐量之间），批次里包含的消息越多，单位时间内处理的消息就越多，单个消息的传输时间就越长（吞吐量高延时也高）。如果进行压缩，可以提升数据的传输和存储能力，但需要更多的计算处理。
# 主题Topic和消息日志Log
可以理解Topic是一个类别的名称，同类消息发送到同一个Topic下面。对于每一个Topic，下面可以有多个分区(**Partition)**日志文件:
Kafka 通过分区（Partition）来实现数据冗余和伸缩性，因为分区可以分布在不同的服务器上，那就是说一个主题可以跨越多个服务器（这是 Kafka 高性能的一个原因，多台服务器的磁盘读写性能比单台更高）。
Partition是一个有序的message序列，这些message按顺序添加到一个叫做commit log的文件中。每个partition中的 消息都有一个唯一的编号，称之为offset，用来唯一标示某个分区中的message。
每个partition，都对应一个commit log文件。一个partition中的message的offset都是唯一的，但是不同的partition 中的message的offset可能是相同的。
kafka一般不会删除消息，不管这些消息有没有被消费。只会根据配置的日志保留时间(log.retention.hours)确认消息多 久被删除，默认保留最近一周的日志消息。kafka的性能与保留的消息数据量大小没有关系，因此保存大量的数据消息日 志信息不会有什么影响。
每个consumer是基于自己在commit log中的消费进度(offset)来进行工作的。在kafka中，消费offset由consumer自己来维护；一般情况下我们按照顺序逐条消费commit log中的消息，当然我可以通过指定offset来重复消费某些消息， 或者跳过某些消息。
kafka中的consumer对集群的影响是非常小的，添加一个或者减少一个consumer，对于集群或者其他consumer 来说，都是没有影响的，因为每个consumer维护各自的消费offset。
# replica 副本
Kafka 中消息的备份又叫做 副本（Replica），为保证集群的高可用性，kafka提供副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。Kafka 定义了两类副本：领导者副本（Leader Replica） 和 追随者副本（Follower Replica），前者对外提供服务，后者只是被动跟随。
# Topic，Partition和Broker
一个topic，代表逻辑上的一个业务数据集，比如订单相关操作消息放入订单topic，用户相关操作消息放入用户topic，对于大型网站来说，后端数据都是海量的，订单消息很可能是非常 巨量的，如果把这么多数据都放在一台机器上可定会有容量限制问题，那么就可以在 topic内部划分多个partition来分片存储数据，不同的partition（分区）可以位于不同的机器上，每台机器上都运行一个Kafka的 进程Broker。
partitions分布在kafka集群中不同的broker上，每个broker可以请求备份其他broker上partition上的数据。kafka集群支持配置一个partition备份的数量。
针对每个partition，都有一个broker起到“leader”的作用，0个或多个其他的broker作为“follwers”的作用。leader处理所有的针对这个partition的读写请求，而followers被动复制leader的结果，不提供读写(主要是为了保证多副本数据与消费的一致性)。如果这个leader失效了，其中的一个follower将会自动的变成新的leader。
分区复制带来的好处是，提供了消息冗余。一旦首领 broker 失效，其他 broker 可以接管领导权。当然相关的消费者和生产者都要重新连接到新的首领上。
生产者默认情况下把消息均衡分布到主题的所有分区上，如果需要指定分区，则需要使用消息里的消息键和分区器。
为什么要对Topic下数据进行分区存储？
1、commit log文件会受到所在机器的文件系统大小的限制，分区之后可以将不同的分区放在不同的机器上，相当于对 数据做了分布式存储，理论上一个topic可以处理任意数量的数据。
2、为了提高并行度
# Producers 生产者
生产者将消息发送到topic中去，同时负责选择将message发送到topic的哪一个partition中。通过roundrobin做简单的 负载均衡。也可以根据消息中的某一个关键字来进行区分。通常第二种方式使用的更多。
# Consumers 消费者
传统的消息传递模式有2种：队列( queue) 和（publish-subscribe）
queue模式：多个consumer从服务器中读取数据，消息只会到达一个consumer。
publish-subscribe模式：消息会被广播给所有的consumer。
Kafka基于这2种模式提供了一种consumer的抽象概念：consumer group。
queue模式：所有的consumer都位于同一个consumer group 下。
publish-subscribe模式：所有的consumer都有着自己唯一的consumer group。
上图说明：由2个broker组成的kafka集群，某个主题总共有4个partition(P0-P3)，分别位于不同的broker上。这个集群 由2个Consumer Group消费， A有2个consumer instances ，B有4个消费者实例。一个分区只有在一个消费者组中一个消费者，而一个消费者可以有多个分区。
# 消费者群组
消费者群组（Consumer Group）指的就是由一个或多个消费者组成的群体，生产者与消费者的关系就如同餐厅中的厨师和顾客之间的关系一样，一个厨师对应多个顾客，也就是一个生产者对应多个消费者。
通常一个topic会有几个consumer group，每个consumer group都是一个逻辑上的订阅者（ logical subscriber ）。每个consumer group由多个consumer instance组成，从而达到可扩展和容灾的功能。消费者组，可以并行消费同一topic中的消息。
群组可以保证每个分区只被一个消费者使用。
# offset
对于Kafka中的分区而言，它的每条消息都有唯一的offset，用来表示消息在分区中对应的位置。
消费者订阅主题，一个或者多个，并且按照消息的生成顺序读取。消费者通过检查所谓的偏移量来区分消息是否读取过。偏移量是一种元数据，一个不断递增的整数值，创建消息的时候，Kafka 会把他加入消息。在一个主题中一个分区里，每个消息的偏移量是唯一的。每个分区最后读取的消息偏移量会保存到 Zookeeper 或者 Kafka 上，这样分区的消费者关闭或者重启，读取状态都不会丢失。
# 消费顺序
**一个partition同一个时刻在一个consumer group中只能有一个consumer instance在消费，**从而保证消费顺序。 consumer group中的consumer instance的数量不能比一个Topic中的partition的数量多，否则，多出来的 consumer消费不到消息。
Kafka只在partition的范围内保证消息消费的局部顺序性，不能在同一个topic中的多个partition中保证总的消费顺序 性。
如果有在总体上保证消费顺序的需求，那么我们可以通过将topic的partition数量设置为1，将consumer group中的 consumer instance数量也设置为1，但是这样会影响性能，所以kafka的顺序消费很少用。
# 保留消息
在一定期限内保留消息是 Kafka 的一个重要特性，Kafka broker 默认的保留策略是：要么保留一段时间（7 天），要么保留一定大小（比如 1 个 G）。 到了限制，旧消息过期并删除。但是每个主题可以根据业务需求配置自己的保留策略（开发时要注意，Kafka 不像 Mysql 之类的永久存储）。
# 架构图
# kafka工作流程
# 生产流程
先从zk获取对应分区的leader在哪个broker
broker进程上的leader将消息写入到本地log中
follower从leader上拉取消息，写入到本地log，并向leader发送ACK
leader接收到所有的ISR中的Replica的ACK后，并向生产者返回ACK
# 消费流程
- 每个consumer都可以根据分配策略，获得要消费的分区
- 获取到consumer对应的leader处于哪个broker以及offset
- 拉取数据
- 消费者提交offset
