前言
说这几个概念之前呢？先说几个问题
1.kakfa是什么？
Kafka 是一个分布式的基于发布/订阅模式的消息队列(Message Queue)，主要应用与大数据"实时"处理领域
2.kafka有什么作用
Kafka 本质上是一个 MQ(Message Queue)，使用消息队列的好处?(此处是面试题)
- 解耦：允许我们独立的扩展或修改队列两边的处理过程。
- 可恢复性：即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
- 缓冲：有助于解决生产消息和消费消息的处理速度不一致的情况。
- 灵活性&峰值处理能力：不会因为突发的超负荷的请求而完全崩溃，消息队列能够使关键组件顶住突发的访问压力（削峰）。
- 异步通信：消息队列允许用户把消息放入队列但不立即处理它。
1. producer - 生产者
顾名思义，生产者，生产消息的那个家伙。
在准确点形容就是：向 Kafka Broker 发消息的客户端。
既然发送消息了，那么消息就有可能存在丢失，比如消息发送失败了。
那怎么预防这类事情发生呢？
Kafka 在生产者上有一个可选的参数 ack，该参数指定了必须要有多少个分区副本收到消息，生产者才会认为消息写入成功：
acks=0 ：消息发送出去就认为已经成功了，不会等待任何来自服务器的响应
acks=1 ： 只要集群的首领节点收到消息，生产者就会收到一个来自服务器成功响应
acks=all ：只有当所有参与复制的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应
2. broker - 消息服务器
【这里只是举了一个消费者采用啦的模式，当然还有推的模式】
从这张图来理解broker的定位会更好记一点，可以理解为，生产者把消息给broker，consumer从broker拉取消息进行消费（数据处理）
来看下百科的解释
它的主要作用是在ZooKeeper 的帮助下管理和协调整个Kafka 集群。 集群中任意一台Broker 都能充当控制器的角色，但是在运行过程中，只能有一个Broker 成为控制器，来执行管理和协调的职责。
这么说来，broker就不是一台机器了，而是一个集群（类似于redis集群，同样有leader的选举和存活检测，不过这个就由zookeeper来帮助了，毕竟人家才是背后的大哥）
（记住这个图有点问题，后面会改正,看下面这句话就知道图不是很形象了）
那么实际的关系是：
一台 Kafka 机器就是一个 Broker。一个集群由多个 Broker 组成。一个 Broker 可以容纳多个 Topic。
这样看起来的话，当producer将消息投递到broker的时候，会存在一个很严重的问题，就是消息丢失。
既然存在那么如何解决呢？
2.1 消息在broker丢失了怎么办
脑补中。。
Broker丢失消息是由于Kafka本身的原因造成的，kafka为了得到更高的性能和吞吐量，将数据异步批量的存储在磁盘中。消息的刷盘过程，为了提高性能，减少刷盘次数，kafka采用了批量刷盘的做法。即，按照一定的消息量，和时间间隔进行刷盘。这种机制也是由于linux操作系统决定的。将数据存储到linux操作系统种，会先存储到页缓存（Page cache）中，按照时间或者其他条件进行刷盘（从page cache到file），或者通过fsync命令强制刷盘。数据在page cache中时，如果系统挂掉，数据会丢失。
刷盘触发条件有三：
主动调用sync或fsync函数
可用内存低于阀值
dirty data时间达到阀值。dirty是pagecache的一个标识位，当有数据写入到pageCache时，pagecache被标注为dirty，数据刷盘以后，dirty标志清除。
Broker配置刷盘机制，是通过调用fsync函数接管了刷盘动作。从单个Broker来看，pageCache的数据会丢失。
也就是说，理论上，要完全让kafka保证单个broker不丢失消息是做不到的，只能通过调整刷盘机制的参数缓解该情况。比如，减少刷盘间隔，减少刷盘数据量大小。时间越短，性能越差，可靠性越好（尽可能可靠）。这是一个选择题。
为了解决该问题，kafka通过producer和broker协同处理单个broker丢失参数的情况。一旦producer发现broker消息丢失，即可自动进行retry。除非retry次数超过阀值（可配置），消息才会丢失。此时需要生产者客户端手动处理该情况。那么producer是如何检测到数据丢失的呢？是通过ack机制，类似于http的三次握手的方式。
3. topic - 消息主题
topic是消息的逻辑分类，可以看做是一个消息类别的名称，同类消息发送到同一个Topic下面。
举个荔枝，订单消息，商品的信息，2个类型，他们的消息内容，消息格式可能会存在差异性，并且都有各自的生产者和消费者。
如果按照一个消息类型建立kafka系统，那么得搭建多少个系统能满足一个庞大的业务系统呢？
所以就有了Topic这个东西-逻辑分类，假如一个消息类型放到一个Topic中就合理了。
所以在生产消息时，就需要指定Topic了。这么想来是不是就合理了呢。
好了，到了总结时间了
1.消息生产时需要指定生产到哪个topic
2.每个topic就是一类消息
3.消费时需要指定消费那个topic数据
既然每个topic消息是一种类型，那么相信你面试过程中听过一个非常经典的面试题：kakfa如何保证顺序消费呢？
没错，单一partition内的消息天然有序的
假如有人问怎么保证有序，这下知道怎么回了吧，那么如何保证不同topic之间的顺序呢，这个得从自己的业务出发，植入相应的数据消费序号，或者消费者拿到数据后再放到自己的mq中消费了。
好了，结合上述，画出图吧
4.patition - 主题内分区
4.1定义
partition是个什么东西呢？
既然有topic了，分类都有了，还缺什么吗？
topic是逻辑的概念，partition是物理的概念。 啥是物理概念，就是物理上进行分离，分布在不同的实体机器上。
引用知乎上一个非常合适的荔枝来说明就在合适不过了
Kafka的设计也是源自生活，好比是为公路运输，不同的起始点和目的地需要修不同高速公路（主题topic）。高速公路上可以提供多条车道（分区partition），流量大的公路多修几条车道保证畅通，流量小的公路少修几条车道避免浪费。收费站好比消费者，车多的时候多开几个一起收费避免堵在路上，车少的时候开几个让汽车并道就好了。
说直白点呢，不同的公路就是topic， 公路上存在多条车道，每条车道就是分区partition
4.2 作用
如果没有分区，一个topic对应的消息集在分布式集群服务组中，就会分布不均匀，即可能导致某台服务器A记录当前topic的消息集很多，若此topic的消息压力很大的情况下，服务器A就可能导致压力很大，吞吐也容易导致瓶颈。
所以很明显partition的作用就来了：通过多分区实现负载均衡的效果，提高kafka访问吞吐率。
Topic 是一个逻辑概念，Partition 是最小的存储单元，掌握着一个 Topic 的部分数据。每个 Partition 都是一个单独的 log 文件；
借用下知乎图
那么patition和topic的关系就是
4.3 如何写入partition？
消息以追加的方式写入分区，然后以先入先出的顺序读取。Kafka 通过分区来实现数据的冗余和伸缩性，分区可以分布在不同的服务器上，这意味着一个 Topic 可以横跨多个服务器，以提供比单个服务器更强大的性能。
具体的方式有3种：
- 采用轮训的方式写入到每个partition中（默认采用的方式）
- producer指定写入到哪个partition中
- 自定义写入
producer指定写入到哪个partition中或者自定义写入有一个最好的利用点，就是不至于热点数据全部到一个partition中，导致数据严重倾斜。
5. groups - 消费组
消费者组内每个消费者负责消费不同分区的数据，提高消费能力。一个分区只能由组内一个消费者消费，消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
那么消费组和消费者的关系就是这样子了
6.概念说完了，那么如何消费数据呢？
6.1 pull(拉)模式
由消费者，主动从 broker 中读取数据
pull 模式可以根据 consumer 的消费能力以适当的速率消费消息。
优点：主动权在消费者手里，想什么时候要就要
缺点：如果 kafka 没有数据，消费者可能会陷入循环中
针对这一点，Kafka 的消费者在消费数据时会传入一个时长参数 timeout，如果当前没有数据可供消费，consumer 会等待一段时间之后再返回，这段时长即为 timeout
6.2 push （推）模式
消息有broker来决定，决定发送的效率。
它的目标是尽可能以最快速度传递消息，但是这样很容易造成 consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。
6.3 offset
由于 consumer 在消费过程中可能会出现断电宕机等故障，consumer 恢复后，需要从故障前的位置的继续消费，所以 consumer 需要实时记录自己消费到了哪个 offset，以便故障恢复后继续消费。
group + topic + partition（GTP） 才能确定一个 offset！
7.整体框架图
- producer：消息生产者
- consumer：消息消费者
- Topic：消息主题
- partition：主题内分区
- Brokers：消息服务器
- Groups：消费者组
