【Kafka基本原理】

一、Kafka介绍

1、MQ的作用

MQ：MessageQueue，消息队列。 队列，是一种FIFO 先进先出的数据结构。消息则是跨进程传递的数据。
一个典型的MQ系统，会将消息消息由生产者发送到MQ进行排队，然后根据一定的顺序交由消息的消费者进
行处理。
QQ和微信就是典型的MQ。只不过他对接的使用对象是人，而Kafka需要对接的使用对象是应用程序。
MQ的作用主要有以下三个方面：
异步
例子：快递员发快递，直接到客户家效率会很低。引入菜鸟驿站后，快递员只需要把快递放到菜鸟驿
站，就可以继续发其他快递去了。客户再按自己的时间安排去菜鸟驿站取快递。
作用：异步能提高系统的响应速度、吞吐量。
解耦
例子：《Thinking in JAVA》很经典，但是都是英文，我们看不懂，所以需要编辑社，将文章翻译成其
他语言，这样就可以完成英语与其他语言的交流。
作用：
1、服务之间进行解耦，才可以减少服务之间的影响。提高系统整体的稳定性以及可扩展性。
2、另外，解耦后可以实现数据分发。生产者发送一个消息后，可以由一个或者多个消费者进行消费，
并且消费者的增加或者减少对生产者没有影响。
削峰
例子：长江每年都会涨水，但是下游出水口的速度是基本稳定的，所以会涨水。引入三峡大坝后，可以
把水储存起来，下游慢慢排水。
作用：以稳定的系统资源应对突发的流量冲击。

2、为什么要用Kafka

业务场景决定了产品的特点。
1、数据吞吐量很大： 需要能够快速收集各个渠道的海量日志
2、集群容错性高：允许集群中少量节点崩溃
3、功能不需要太复杂：Kafka的设计目标是高吞吐、低延迟和可扩展，主要关注消息传递而不是消息处理。
所以，Kafka并没有支持死信队列、顺序消息等高级功能。
4、允许少量数据丢失：Kafka本身也在不断优化数据安全问题，目前基本上可以认为Kafka可以做到不会丢
数据。

三、理解Kakfa的消息传递机制

在Kafka的技术体系中，有以下一些概念需要先熟悉起来：
客户端Client： 包括消息生产者 和 消息消费者。之前简单接触过。
消费者组：每个消费者可以指定一个所属的消费者组，相同消费者组的消费者共同构成一个逻辑消费者
组。每一个消息会被多个感兴趣的消费者组消费，但是在每一个消费者组内部，一个消息只会被消费一
次。
服务端Broker：一个Kafka服务器就是一个Broker。
话题Topic：这是一个逻辑概念，一个Topic被认为是业务含义相同的一组消息。客户端都通过绑定
Topic来生产或者消费自己感兴趣的话题。
分区Partition：Topic只是一个逻辑概念，而Partition就是实际存储消息的组件。每个Partiton就是一
个queue队列结构。所有消息以FIFO先进先出的顺序保存在这些Partition分区中。

四、Kafka集群服务

为什么要用集群？
单机服务下，Kafka已经具备了非常高的性能。TPS能够达到百万级别。但是，在实际工作中使用时，单机
搭建的Kafka会有很大的局限性。
一方面：消息太多，需要分开保存。Kafka是面向海量消息设计的，一个Topic下的消息会非常多，单机服
务很难存得下来。这些消息就需要分成不同的Partition，分布到多个不同的Broker上。这样每个Broker就只
需要保存一部分数据。这些分区的个数就称为分区数。
另一方面：服务不稳定，数据容易丢失。单机服务下，如果服务崩溃，数据就丢失了。为了保证数据安
全，就需要给每个Partition配置一个或多个备份，保证数据不丢失。Kafka的集群模式下，每个Partition都
有一个或多个备份。Kafka会通过一个统一的Zookeeper集群作为选举中心，给每个Partition选举出一个主
节点Leader，其他节点就是从节点Follower。主节点负责响应客户端的具体业务请求，并保存消息。而从节
点则负责同步主节点的数据。当主节点发生故障时，Kafka会选举出一个从节点成为新的主节点。
最后：Kafka集群中的这些Broker信息，包括Partition的选举信息，都会保存在额外部署的Zookeeper集
群当中，这样，kafka集群就不会因为某一些Broker服务崩溃而中断。

五、理解服务端的Topic、Partition和Broker

–create创建集群，可以指定一些补充的参数。大部分的参数都可以在配置文件中指定默认值。
partitons参数表示分区数，这个Topic下的消息会分别存入这些不同的分区中。示例中创建的
disTopic，指定了四个分区，也就是说这个Topic下的消息会划分为四个部分。
replication-factor表示每个分区有几个备份。示例中创建的disTopic，指定了每个partition有两个备
份。
2、–describe查看Topic信息。

partiton参数列出了四个partition，后面带有分区编号，用来标识这些分区。
Leader表示这一组partiton中的Leader节点是哪一个。这个Leader节点就是负责响应客户端请求的主
节点。从这里可以看到，Kafka中的每一个Partition都会分配Leader，也就是说每个Partition都有不同
的节点来负责响应客户端的请求。这样就可以将客户端的请求做到尽量的分散。
Replicas参数表示这个partition的多个备份是分配在哪些Broker上的。也称为AR。这里的0,1,2就对应
配置集群时指定的broker.id。但是，Replicas列出的只是一个逻辑上的分配情况，并不关心数据实际是
不是按照这个分配。甚至有些节点服务挂了之后，Replicas中也依然会列出节点的ID。
ISR参数表示partition的实际分配情况。他是AR的一个子集，只列出那些当前还存活，能够正常同步数
据的那些Broker节点。
接下来，我们还可以查看Topic下的Partition分布情况。在Broker上，与消息，联系最为紧密的，其实就
是Partition了。之前在配置Kafka集群时，指定了一个log.dirs属性，指向了一个服务器上的日志目录。进入
这个目录，就能看到每个Broker的实际数据承载情况。

六、Kafka集群的整体结构

1、Topic是一个逻辑概念，Producer和Consumer通过Topic进行业务沟通。
2、Topic并不存储数据，Topic下的数据分为多组Partition，尽量平均的分散到各个Broker上。每组
Partition包含Topic下一部分的消息。每组Partition包含一个Leader Partition以及若干个Follower Partition
进行备份，每组Partition的个数称为备份因子 replica factor。
3、Producer将消息发送到对应的Partition上，然后Consumer通过Partition上的Offset偏移量，记录自
己所属消费者组Group在当前Partition上消费消息的进度。
4、Producer发送给一个Topic的消息，会由Kafka推送给所有订阅了这个Topic的消费者组进行处理。但是
在每个消费者组内部，只会有一个消费者实例处理这一条消息。
5、最后，Kafka的Broker通过Zookeeper组成集群。然后在这些Broker中，需要选举产生一个担任
Controller角色的Broker。这个Controller的主要任务就是负责Topic的分配以及后续管理工作。在我们实验
的集群中，这个Controller实际上是通过ZooKeeper产生的。