了解Kafka的基本理论

#了解Kafka的基本理论

同步处理：

生产者生产消息发送给消费者，消费者处理消息的量是有一定限度的，比如一次只能处理100条消息队列，当生产者与消费者之间对消息的处理速率不一样时，也就是生产者一次性生产1000条消息给消费者，但是消费者自身处理消息的量是有限度的，这就会造成消息无法及时处理而促成消息堆积，服务崩溃。

异步处理：

生产者生产消息发送给消费者，消息会经过MQ（消息队列）进行缓存，然后消费者就从MQ里处理数据，然后剩余的数据就继续放到MQ中，直到消费者处理完为止。这样就能防止消费者不能解决高并发消息量而造成服务崩溃的问题

##1.Kafka概述
//为什么需要消息队列(MQ)
主要原因是由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。比
如大量的请求并发访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触
发too many connection 错误，引发雪崩效应。
我们使用消息队列，通过异步处理请求，从而缓解系统的压力。消息队列常应用于
异步处理，流量削峰，应用解耦，消息通讯等场景。
当前比较常见的MQ中间件有ActiveMQ、 RabbitMQ、 RocketMQ、 Kafka 等。

##2.使用消息队列的好处
(1)解耦
允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

(2)可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度
，所以即使–个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被
处理。

(3)缓冲
有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不
致的情况。

(4)灵活性&峰值处理能力
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常
见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。
使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请
求而完全崩溃。

(5)异步通信
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许
用户把一一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少
，然后在需要的时候再去处理它们。

##3.消息队列的两种模式
(1)点对点模式(–对一，消费者主动拉取数据，消息收到后消息清除)
消息生产者生产消息发送到消息队列中，然后消息消费者从消息队列中取出并且消
费消息。消息被消费以后，消息队列中不再有存储，所以消息消费者不可能消费到
已经被消费的消息。消息队列支持存在多个消费者，但是对一个消息而言，只会有
-一个消费者可以消费。
(2)发布/订阅模式(–对多，又叫观察者模式，消费者消费数据之后不会清除消
息)
消息生产者(发布)将消息发布到topic
中，同时有多个消息消费者(订阅)消费该消息。和点对点方式不同，发布到
topic的消息会被所有订阅者消费。
发布/订阅模式是定义对象间一种一-对多的依赖关系，使得每当-一个对象( 目标对象
)的状态发生改变，则所有依赖于它的对象(观察者对象)都会得到通知并自动更
新。

##4.Kafka简介

Kafka是最初由Linkedin公司开发，是一一个分布式、支持分区的(partition) 、多副本的(replica) ，基于Zookeeper协调的分布式消息中间件系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景，比如基于hadoop的批处理系统、低延迟的实时系统、Spark/F1ink 流式处理引擎，nginx访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache 基金会并成为顶级开源项目。

5.Kafka特性

●高吞吐量、低延迟
Kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒。每个topic
可以分多个Partition, Consumer Group对Partition
进行消费操作，提高负载均衡能力和消费能力。
●可扩 展性
kafka集群支持热扩展
●持久性、可靠性
消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
●容错性
允许集群中节点失败(多副本情况下，若副本数量为n，则允许n-1个节点失败)
●高并发
支持数千个客户端同时读写

##6.Kafka系统架构

(1) Broker
一台kafka 服务器就是一个broker. 一一个集群由多个broker 组成。一.个
broker
可以容纳多个topic.
(2) Topic
可以理解为-一个队列，生产者和消费者面向的都是一一个topic.
类似于数据库的表名或者ES的index
物理.上不同topic 的消息分开存储
(3) Partition
为了实现扩展性，一一个非常大的topic可以分布到多个
broker (即服务器)上，一 一个topic 可以分割为一- 个或多个partition， 每个
partition是一个有序的队列。Kafka只保证partition
内的记录是有序的，而不保证topic 中不同partition 的顺序。
每个topic 至少有一一个
partition,当生产者产生数据的时候，会根据分配策略选择分区，然后将消息追加
到指定的分区的队列末尾。

##7.Partation 数据路由规则:
1.指定了patition,
则直接使用;
2.未指定patition但指定key (相当于消息中某个属性)，通过对key的
value 进行hash 取模，选出一一个patition;
3. patition 和key都未指定，使用轮询选出一一个patition。
每条消息都会有一一个自增的编号，用于标识消息的偏移量，标识顺序从0开始。
每个partition 中的数据使用多个segment 文件存储。
如果topic有多个
partition，消费数据时就不能保证数据的顺序。严格保证消息的消费顺序的场景下
(例如商品秒杀、抢红包) ，需要将partition数目设为1。
●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集群数据不均衡。

//分区的原因
●方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而-一个top
ic又可以有多个Partition组成， 因此整个集群就可以适应任意大小的数据了;
●可以提高并发，因为可以以Partition为单位读写了。

(4) Replica
副本，为保证集群中的某个节点发生故障时，该节点上的
partition
数据不丢失，且kafka仍然能够继续工作，Hafka 提供了副本机制，一个
topic 的每个分区都有若干个副本，一个leader 和若干个follower.
(5) Leader :
每个partition 有多个副本，其中有且仅有一一个作为Leader, Leader
是当前负责数据的读写的partition。

(6) Follower

Follower跟随Leader, 所有写请求都通过Leader
路由，数据变更会广播给所有Follower, Follower 与Leader
保持数据同步。Follower 只负责备份，不负责数据的读写。
如果Leader 故障，则从Follower 中选举出一一个新的Leader.
当Follower 挂掉、卡住或者同步太慢，Leader 会把这个Follower 从
ISR (Leader 维护的一一个和Leader 保持同步的Follower 集合)
列表中删除，重新创建一一个Follower.
(7)
生产者即数据的发布者，该角色将消息push发布到Kafka的topic中。
broker接收到生产者发送的消息后，broker
将该消息追加到当前用于追加数据的segment文件中。
生产者发送的消息，存储到一一个partition中，生产者也可以指定数据存储的
partition。
(8) Consumer
消费者可以从broker中pull拉取数据。消费者可以消费多个topic 中的数据。

(9) Consumer Group (CG )
消费者组，由多个consumer组成。
所有的消费者都属于某个消费者组，即消费者组是逻辑上的一一个订阅者。可为每个
消费者指定组名，若不指定组名则属于默认的组。将多个消费者集中到一起去处理某-一个Topic
的数据，可以更快的提高数据的消费能力。
消费者组内每个消费者负责消费不同分区的数据，一一个分区只能由一一个组内消费者
消费，防止数据被重复读取。消费者组之间互不影响。

(10) offset偏移量
可以唯一的标识一. 条消息。
偏移量决定读取数据的位置，不会有线程安全的问题，消费者通过偏移量来决定下
次读取的消息(即消费位置)
消息被消费之后，并不被马.上删除，这样多个业务就可以重复使用Kafka 的消息。
某一个业务也可以通过修改偏移量达到重新读取消息的目的，偏移量由用户控制。
消息最终还是会被删除的，默认生命周期为1周(7*24小时)。

(11 ) Zookeeper
Kafka通过Zookeeper 来存储集群的meta
信息。
由于consumer 在消费过程中可能会出现断电宕机等故障，consumer
恢复后，需要从故障前的位置的继续消费，所以consumer
需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。
Kafka 0.9版本之前，consumer 默认将offset 保存在Zookeeper 中:从0.9
版本开始，consumer 默认将offset 保存在Kafka - 一个内置的topic 中，该topic为_consumer_ offsets 。
也就是说，:
前的位置的继续消费，所以consumer
需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。
Kafka 0.9版本之前，consumer 默认将offset 保存在Zookeeper 中:从0.9
版本开始，consumer 默认将offset 保存在Kafka - 一个内置的topic 中，该topic为_consumer_ offsets 。
也就是说，:
zookeeper的作用就是，生产者push数据到kafka集群，就必须要找到kafka集群的节点在哪里，这些都是通过zookeeper去寻找的。消费者消费哪一条数据，也需要zookeeper的支持， 从zookeeper获得offset，offset记录 上一次消费的数据消费到哪里，这样就可以接着下一条 数据进行消 费。