上一阶段给大家讲的是Redis，接下来这一阶段，我给你大家更新Kafka的知识分享哦!!!
企业中离线业务场景实时业务场景都需要使用到kafka
Kafka具备数据的计算能力和存储能力，但是两个能力相对（MR/SPARK，HDFS）较弱.
Kafka角色的角色与hbase比较像，层级关系比较多。
1、消息队列的介绍
消息：是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
消息队列（Message Queue）：是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在
2、消息队列的应用场景
消息队列在实际应用中包括如下四个场景：
应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；
3、消息队列的两种模式
消息队列包括两种模式，点对点模式（point to point， queue）和发布/订阅模式（publish/subscribe，topic）
3.1 点对点模式
点对点模式下包括三个角色：
消息队列
发送者 (生产者)：生产数据的程序/人/对象
接收者（消费者）：处理队列内的数据的程序/人/对象
消息发送者生产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。
点对点模式特点：
• 每个消息只有一个接收者（Consumer）(即一旦被消费，消息就不再在消息队列中)；
• 发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；
• 接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；
3.2 发布/订阅模式
发布/订阅模式下包括三个角色：
角色主题（Topic）：消息得分类，分组（王者荣耀，QQ飞车）
发布者(Publisher)：生产者
订阅者(Subscriber)：消费者
发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
发布/订阅模式特点：
• 每个消息可以有多个订阅者；
• 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
• 为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；
4、kafka的基本介绍
4.1 kafka的基本介绍
官网：http://kafka.apache.org/
kafka是一个分布式，分区的，多副本的，多订阅者的消息发布订阅系统（分布式MQ系统），可以用于搜索日志，监控日志，访问日志等。
最初由linkedin公司开发，使用scala语言编写，
Kafka is a distributed,partitioned,replicated commit logservice。
kafka对消息保存时根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。
Kafka:是一个分布式的（可以多节点），分区的，多副本的，多订阅者的消息发布订阅系统。
Kafka对消息分类使用topic（一个分类，一个类别）
生产者：Producer(制造数据、生产数据的，将消息推送到队列的)
消费者：Consumer（读取数据的，浏览数据的，在队列中获取数据）
服务器：Broker
4.2 kafka的好处
1、可靠性：分布式的，分区，复制和容错。
2、可扩展性：kafka消息传递系统轻松缩放，无需停机。
3、耐用性：kafka使用分布式提交日志，这意味着消息会尽可能快速的保存在磁盘上，因此它是持久的。
4、性能：kafka对于发布和定于消息都具有高吞吐量。即使存储了许多TB的消息，他也爆出稳定的性能。
kafka非常快：保证零停机和零数据丢失
Kafka的补充说明：
kafka消息保留在磁盘上，并在集群内复制以防止数据丢失（不能提高数据的读取效率）。
消费端为拉模型来主动拉取数据。
1、Consumer Group：每一个Consumer属于一个特定的Consumer Group（可以为每个Consumer指定 groupName）
2、Broker：kafka集群中包含一个或者多个服务实例
3、Topic：每条发布到kafka集群的消息都有一个类别，分类
4、Partition：Partition是一个物理上的概念，每个Topic包含一个或者多个Partition
5、segment：一个partition当中存在多个segment文件段，每个segment分为两部分，.log文件和.index文件，
其中.index文件是索引文件，主要用于快速查询.log文件当中数据的偏移量位置
.log存放数据文件
4.3 分布式的发布与订阅系统
apache kafka是一个分布式发布-订阅消息系统和一个强大的队列，可以处理大量的数据，并使能够将消息从一个端点传递到另一个端点，kafka适合离线和在线消息消费。
kafka消息保留在磁盘上，并在集群内复制以防止数据丢失。
kafka构建在zookeeper同步服务之上。它与apache和spark非常好的集成，应用于实时流式数据分析
4.4 kafka的主要应用场景
指标分析
kafka通常用于操作监控数据。用于接收、聚合来自多种应用程序的统计信息， 以便于向产生环境中的数据集中反馈数据
日志聚合解决方法
kafka可用于跨组织从多个服务器收集日志，并使他们以标准的合适提供给多个服务器。
流式处理
流式处理框架（spark，storm，flink）从主题中读取数据，对齐进行处理，并将处理后的数据写入新的主题，供用户和应用程序使用，kafka的强耐久性在流处理的上下文中也非常的有用。
5、kafka的架构介绍
1、生产者API
允许应用程序发布记录流至一个或者多个kafka的主题（topics）。
2、消费者API
允许应用程序订阅一个或者多个主题，并处理这些主题接收到的记录流。
3、StreamsAPI
允许应用程序充当流处理器（stream processor），从一个或者多个主题获取输入流，并生产一个输出流到一个或 者多个主题，能够有效的变化输入流为输出流。
4、ConnectAPI
允许构建和运行可重用的生产者或者消费者，能够把kafka主题连接到现有的应用程序或数据系统。例如：一个连接到关系数据库的连接器可能会获取每个表的变化。
6、kafka架构内部细节剖析
从左到右流程架构图
从上到下流程架构图
补充说明：
kafka支持消息持久化，消费端为拉模型来拉取数据，消费状态和订阅关系有客户端负责维护，消息消费完后，不会立即删除，会保留历史消息。因此支持多订阅时，消息只会存储一份就可以了。
Broker：kafka集群中包含一个或者多个服务实例，这种服务实例被称为Broker
Topic：每条发布到kafka集群的消息都有一个类别，这个类别就叫做Topic
Partition：Partition是一个物理上的概念，每个Topic包含一个或者多个Partition
segment：一个partition当中存在多个segment文件段，每个segment分为两部分，.log文件和.index文件，其中.index文件是索引文件，主要用于快速查询.log文件当中数据的偏移量位置
Producer：负责发布消息到kafka的Broker中。
Consumer：消息消费者,向kafka的broker中读取消息的客户端
Consumer Group：每一个Consumer属于一个特定的Consumer Group（可以为每个Consumer指定 groupName）
.log:存放数据文件
.index：存放.log文件的索引数据
7、kafka主要组件说明
7.1 kafka当中的生产者(Producer)r说明
producer主要是用于生产消息，是kafka当中的消息生产者，生产的消息通过topic进行归类，保存到kafka的broker里面去
7.2 kafka当中的主题（Topic）说明
1、kafka将消息以topic为单位进行归类
2、topic特指kafka处理的消息源（feeds of messages）的不同分类。
3、topic是一种分类或者发布的一些列记录的名义上的名字。kafka主题始终是支持多用户订阅的；也就是说，一个主题可以有零个，一个或者多个消费者订阅写入的数据。
4、在kafka集群中，可以有无数的主题。
5生产者和消费者消费数据一般以主题为单位。更细粒度可以到分区级别。
7.3 kafka当中的分区（Partition）说明
kafka当中，topic是消息的归类，一个topic可以有多个分区，每个分区保存部分topic的数据，所有的partition当中的数据全部合并起来，就是一个topic当中的所有的数据，
一个broker服务下，是否可以创建多个分区？
可以的，broker数与分区数没有关系； 在kafka中，每一个分区会有一个编号：编号从0开始
每一个分区的数据是有序的
说明-数据是有序 如何保证一个主题下的数据是有序的？（生产是什么样的顺序，那么消费的时候也是什么样的顺序）
多个分区时无序的.分区数在创建topic时设置，并后期可以修改。
topic的Partition数量在创建topic时配置。
Partition数量决定了每个Consumer group中并发消费者的最大数量 （效率最高的情况）。
Partition = 并发度: 刚刚好，效率最高
Partition > 并发度：有部分消费者消费多个分区的数据。
Partition < 并发度 :有部分消费者闲置（任意时刻一个分区内的一条数据只能被消费组中的一个消费者消费）
例如：Consumer group A 有两个消费者来读取4个partition中数据；Consumer group B有四个消费者来读取4个 partition中的数据
7.4 kafka当中partition的副本数说明
kafka分区副本数（kafka Partition Replicas)
副本数（replication-factor）：控制消息保存在几个broker（服务器）上，一般情况下小于等于broker的个数
例如：一个broker服务下，是否可以创建多个副本因子？
不可以；创建主题时，副本因子应该小于等于可用的broker数。 副本因子过程图
副本因子操作以分区为单位的。每个分区都有各自的主副本和从副本；
主副本叫做leader，从副本叫做 follower（在有多个副本的情况下，kafka会为同一个分区下的所有分区，设定角色关系：一个leader和N个 follower），处于同步状态的副本叫做in-sync-replicas(ISR);
follower通过拉的方式从leader同步数据。
消费者和生产者都是从leader读写数据，不与follower交互。
副本因子的作用：让kafka读取数据和写入数据时的可靠性。
副本因子是包含本身，同一个副本因子不能放在同一个Broker中。
如果某一个分区有三个副本因子，就算其中一个挂掉，那么只会剩下的两个中，选择一个leader，但不会在其他的broker中，另启动一个副本（因为在另一台启动的话，存在数据传递，只要在机器之间有数据传递，就会长时间占用网络IO，kafka是一个高吞吐量的消息系统，这个情况不允许发生）所以不会在零个broker中启动。
如果所有的副本都挂了，生产者如果生产数据到指定分区的话，将写入不成功。
lsr表示：当前可用的副本（是一个列表，表示数据副本在那几个节点上）
7.5 kafka当中的segment说明
一个partition当中有多个segment文件组成，每个segment文件，包含两部分，一个是.log文件，另外一个是.index文件，其中.log文件包含了我们发送的数据存储，.index文件，记录的是我们.log文件的数据索引值，以便于我们加快数据的查询速度
索引文件与数据文件的关系
既然它们是一一对应成对出现，必然有关系。索引文件中元数据指向对应数据文件中message的物理偏移地址
比如：索引文件中3,497代表：数据文件中的第三个message,它的偏移地址为497。再来看数据文件中，
Message 368772表示：在全局partiton中是第368772个message。
注：segment index file采取稀疏索引存储方式，它减少索引文件大小，通过mmap可以直接内存操作，稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间，但查找起来需要消耗更多的时间。
7.6 kafka当中的partition的offset
任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），
offset是一个long类型数字，它唯一标识了一条消息，消费者通过（offset，partition，topic）跟踪记录。
7.7 kafka分区与消费组的关系
消费组： 由一个或者多个消费者组成，同一个组中的消费者对于同一条消息只消费一次。
某一个主题下的分区数，对于消费组来说，消费者应该小于等于该主题下的分区数。如下所示：
如：某一个主题有4个分区，那么消费组中的消费者应该小于4，而且最好与分区数成整数倍1 2 4同一个分区下的数据，在同一时刻，不能同一个消费组的不同消费者消费
总结：分区数越多，同一时间可以有越多的消费者来进行消费，消费数据的速度就会越快，提高消费的性能
7.8 kafka当中的consumer
consumer是kafka当中的消费者，主要用于消费kafka当中的数据，任何一个消费者都必定需要属于某一个消费组当中。
任意时刻，一个分区当中的数据，只能被kafka当中同一个消费组下面的一个线程消费
8、consumer消费者消费数据流程
流程描述
Consumer连接指定的Topic partition所在leader broker，采用pull方式从kafkalogs中获取消息。对于不同的消费模式，会将offset保存在不同的地方
1、 Consumer连接指定的Topic partition所在leader broker
2、 采用pull方式从kafkalogs中获取消息。
高阶API: 隐藏Consumer与Broker细节,封装好的接口。工程师直接使用，无需关注细节。
低阶API:使用灵活，用户自己维护连接Controller Broker，存储，更新offset。
实时计算：实时成产-实时传递-实时计算-实时存储-实时展现
官网关于high level API 以及low level API的简介
http://kafka.apache.org/0100/documentation.html#impl_consumer
9、kafka的log-存储机制
9.1、kafka中log日志目录及组成
kafka在我们指定的log.dir目录下，会创建一些文件夹；名字是【主题名字-分区名】所组成的文件夹。 在【主题名字-分区名】的目录下，会有两个文件存在，如下所示：
#索引文件
00000000000000000000.index
#日志内容
0000000000000000000.log
在目录下的文件，会根据log日志的大小进行切分，.log文件的大小为1G的时候，就会进行切分文件；
在kafka的设计中，将offset值作为了文件名的一部分
比如：topic的名字为：test，有三个分区，生成的目录如下如下所示：
test-0
test-1
test-2
kafka日志的组成
segment file组成：由两个部分组成，分别为index file和data file，此两个文件一一对应且成对出现； 后缀.index和.log分别表示为segment的索引文件、数据文件。
segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个全局 partion的最大offset（偏移message数）。数值最大为64位long大小，19位数字字符长度，没有数字就用0 填充。
通过索引信息可以快速定位到message。通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作；
通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。 稀疏索引：为了数据创建索引，但范围并不是为每一条创建，而是为某一个区间创建；
好处：就是可以减少索引值的数量。
不好的地方：找到索引区间之后，要得进行第二次处理。
10、kafka的offset查找过程
比如：要查找绝对offset为7的Message：
上图的左半部分是索引文件，里面存储的是一对一对的key-value，其中key是消息在数据文件（对应的log文件）中的编号，比如“1,3,6,8……”，分别表示在log文件中的第1条消息、第3条消息、第6条消息、第8条消息……，那么为什么在index文件中这些编号不是连续的呢？这是因为index文件中并没有为数据文件中的每条消息都建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。但缺点是没有建立索引的Message也不能一次定位到其在数据文件的位置，从而需要做一次顺序扫描，但是这次顺序扫描的范围就很小了。
其中以索引文件中元数据3,4597为例，其中3代表在右边log数据文件中从上到下第3个消息(在全局partiton表示第4597个消息)，
其中4597表示该消息的物理偏移地址（位置）为4597。
kafka Message的物理结构及介绍
kafka Message的物理结构，如下图所示：
kafka中log CleanUp
kafka中清理日志的方式有两种：delete和compact。
删除的阈值有两种：过期的时间和分区内总日志大小。
在kafka中，因为数据是存储在本地磁盘中，并没有像hdfs的那样的分布式存储，就会产生磁盘空间不足的情况，可以采用删除或者合并的方式来进行处理
可以通过时间来删除、合并：默认7天（log.retention.hours）
还可以通过字节大小、合并：默认-1 无限制（log.retention.bytes）
相同的key，保存offset值大的（最新的消息记录）
11、kafka消息不丢失制
11.1、生产者生产数据不丢失
11.1.1、生产者数据不丢失过程图
说明：有多少个分区，就启动多少个线程来进行同步数据
11.1.2、发送数据方式
可以采用同步或者异步的方式-过程图
可以采用同步或者异步的方式
同步：发送一批数据给kafka后，等待kafka返回结果
1、生产者等待10s，如果broker没有给出ack相应，就认为失败。
2、生产者重试3次，如果还没有相应，就报错
异步：发送一批数据给kafka，只是提供一个回调函数。
1、先将数据保存在生产者端的buffer中。buffer大小是2万条
2、满足数据阈值或者数量阈值其中的一个条件就可以发送数据。
3、发送一批数据的大小是500条
说明：如果broker迟迟不给ack，而buffer又满了，开发者可以设置是否直接清空buffer中的数据。
11.1.3、ack机制（确认机制）
生产者数据不抵事，需要服务端返回一个确认码，即ack响应码；ack的响应有三个状态值
0：生产者只负责发送数据，不关心数据是否丢失，响应的状态码为0（丢失的数据，需要再次发送 ）
1：partition的leader收到数据，响应的状态码为1
-1：所有的从节点都收到数据，响应的状态码为-1
说明：如果broker端一直不给ack状态，producer永远不知道是否成功；producer可以设置一个超时时间10s，超 过时间认为失败。
11.2、kafka的broker中数据不丢失
在broker中，保证数据不丢失主要是通过副本因子（冗余），防止数据丢失
11.3、消费者消费数据不丢失
在消费者消费数据的时候，只要每个消费者记录好offset值即可，就能保证数据不丢失。
12、kafka监控及运维
在开发工作中，消费在Kafka集群中消息，数据变化是我们关注的问题，当业务前提不复杂时，我们可以使用Kafka 命令提供带有Zookeeper客户端工具的工具，可以轻松完成我们的工作。随着业务的复杂性，增加Group和 Topic，那么我们使用Kafka提供命令工具，已经感到无能为力，那么Kafka监控系统目前尤为重要，我们需要观察 消费者应用的细节。
kafka-eagle概述
为了简化开发者和服务工程师维护Kafka集群的工作有一个监控管理工具，叫做 Kafka-eagle。这个管理工具可以很容易地发现分布在集群中的哪些topic分布不均匀，或者是分区在整个集群分布不均匀的的情况。它支持管理多个集群、选择副本、副本重新分配以及创建Topic。同时，这个管理工具也是一个非常好的可以快速浏览这个集群的工具。