kafka简单回顾

先说说遇到的坑回顾下kafka

topic：生产组：P0\P1----P14

一个消费组：c0 c1 c2

依据Consumer的负载均衡分配

消费顺序“c0:p0-p4 c1:p5-p9 c2:p10-p14

问题：突然发现读offset 堆积太多增加消费者也没用

原因： C2节点物理故障，会把数据分给C0和C1,然后C2恢复(生产上会用类似superviser从新启动挂掉的进程)，再重新分配数据，这样来来回回浪费了很多时间每次挪回都重新洗牌，新版本已经修复此问题，所以不应该随便恢复进程

解决：应该预分配节点，比正常的多一些，这样挂点一两个也没有太大影响

消息系统概念

消息系统负责将数据从一个应用程序传输到另一个应用程序

点对点消息系统和发布 - 订阅消息系统

kafka概念

Kafka专为分布式高吞吐量系统而设计。与其他消息传递系统相比，Kafka具有更好的吞吐量，内置分区，复制和固有的容错能力，这使得它非常适合大规模消息处理应用程序。

架构

Topics（主题）

数据存储在主题中。Topic相当于Queue。

主题被拆分成分区。每个这样的分区包含不可变有序序列的消息。分区被实现为具有相等大小的一组分段文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行“随机读写”。

Partition（分区）

一个Topic可以分成多个Partition，这是为了平行化处理。
每个Partition内部消息有序，其中每个消息都有一个offset序号。
一个Partition只对应一个Broker，一个Broker可以管理多个Partition。

Partition offset（分区偏移）

每个分区消息具有称为 offset 的唯一序列标识。

Replicas of partition（分区备份）

副本只是一个分区的备份。副本从不读取或写入数据。它们用于防止数据丢失。

Brokers（经纪人）

代理是负责维护发布数据的简单系统。每个代理可以每个主题具有零个或多个分区。

每一个kafka实例（或者说每台kafka服务器节点）就是一个broker，一个broker可以有多个topic

Kafka Cluster（Kafka集群）

Kafka有多个代理被称为Kafka集群。可以扩展Kafka集群，无需停机。这些集群用于管理消息数据的持久性和复制。

Producers（生产者）

每当生产者将消息发布给代理时，代理只需将消息附加到最后一个段文件。实际上，该消息将被附加到分区。生产者还可以向他们选择的分区发送消息。

Consumers（消费者）

Consumers从broker处读取数据。消费者订阅一个或多个主题，并通过从代理中提取数据来使用已发布的消息。

Consumer自己维护消费到哪个offet

offet的存放位子依据消费类型的不同，如果JAVA API 消费则是存放在zookeeper，如果是kafka默认自带的消费则是存放在kafka自带的topic【__consumer_offsets】

每个Consumer都有对应的group

group是==queue消费模型==：==各个Consumer消费不同的partition，因此一个消息在group内只消费一次==

group是==publish-subscribe消费模型==：各个group各自独立消费，互不影响，因此一个消息被每个group消费一次。

这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。

Kafka数据处理步骤

1、Producer产生消息，发送到Broker中
2、Leader状态的Broker接收消息，写入到相应topic中
3、Leader状态的Broker接收完毕以后，传给Follow状态的Broker作为副本备份
4、Consumer消费Broker中的消息

Consumer与topic关系

kafka只支持Topic

每个group中可以有多个consumer，每个consumer属于一个consumer group; 通常情况下，一个group中会包含多个consumer，这样不仅可以==提高topic中消息的并发消费能力，而且还能提高"故障容错"性==，如果group中的某个consumer失效那么其消费的partitions将会有其他consumer自动接管。

总结：

==一个group中的consumer只会消费一个topic的一条消息，每个consumer消费不同的partition。==

在kafka中,一个partition中的消息只会被group中的一个consumer消费(同一时刻)；

一个Topic中的每个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以同时消费多个partitions中的消息。

kafka的设计原理决定,对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。==但是在设计的时候个人觉得可以多些consumer 已解决前面遇到的坑。==

Kafka消息的分发

Producer客户端负责消息的分发

kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"、"partitions leader列表"等信息；

当producer获取到metadata信息之后, producer将会和Topic下所有partition leader保持socket连接；

消息由producer直接通过socket发送到broker，中间不会经过任何"路由层"。事实上，消息被路由到哪个partition上由producer客户端决定，比如可以采用"random""key-hash""轮询"等。

如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。

在producer端的配置文件中,开发者可以指定partition路由的方式。

Producer消息发送的应答机制

设置发送数据是否需要服务端的反馈,有三个值0,1,-1

0: producer不会等待broker发送ack

1: 当leader接收到消息之后发送ack

-1: 当所有的follower都同步消息成功后发送ack

request.required.acks=0

Consumer的负载均衡

当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提升topic的并发消费能力，步骤如下：

1、假如topic1,具有如下partitions: P0,P1,P2,P3
2、加入group A 中,有如下consumer: C0,C1
3、根据partition索引号排序: P0,P1,P2,P3
4、根据consumer.id排序: C0,C1
5、计算倍数: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)
6、然后依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)]

介绍完kafka的基本概念，简单提一下为什么要用kafka

解耦

在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。

冗余

有时在处理数据的时候处理过程会失败。除非数据被持久化，否则将永远丢失。对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否

扩展性

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的；只要另外增加处理过程即可。

灵活性 & 峰值处理能力

使用消息队列能够使关键组件顶住增长的访问压力，而不是因为超出负荷的请求而完全崩溃。

可恢复性

当体系的一部分组件失效，不会影响到整个系统。

获取一个消息只是”预定”了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，否则这个消息会被放回队列中去，在一段可配置的时间之后可再次被处理。

顺序保证

在许多情况下，数据处理的顺序都很重要。消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。

缓冲

在任何重要的系统中，都会有需要不同的处理时间的元素。

理解数据流异步性

。消息队列提供了异步处理机制，允许你把一个消息放入队列，但并不立即处理它。你想向队列中放入多少消息就放多少，然后在你乐意的时候再去处理它们。