kafka
一、kafka
1.1 为什么需要消息队列(MQ)
因为在高并发环境下,同步请求来不及处理,请求往往发生阻塞。例如:大量请求访问数据库,最后还会导致线程过多,容易引发雪崩。
我们使用消息队列,通过异步处理请求缓解系统的压力。消息队列应用于异步处理,流量削峰,应用解耦,消息通讯等场景
比较常见的MQ中间件有ActiveMQ(基本淘汰)、HabbitMQ(主流)、RocketMQ(主流)、kafka等
1.2 使用消息队列有什么好处
- 解耦:独立扩展或修改两边的处理过程,前提是确保它们能够遵守相同的接口约束
- 可恢复性:系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理
- 缓冲:有利于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致
- 灵活性&峰值处理能力:使用消息队列可以使关键组件顶住突发的访问压力,而不会导致超负荷从而请求完全崩溃
- 异步通信:想向队列中放入多少消息就放入多少消息,然后需要的时候再进行处理
1.3 消息队列的模式
- 点对点模式(一对一,消费者主动拉取数据,消息收到后消息清除)
- 发布/订阅模式(一对多,消费者消费数据之后不会清除数据)
1.4 kafka的概念
kafka是一个分布式的基于发布/订阅模式的消息队列,主要应用于大数据实时处理领域,它支持分区的,多副本的,基于zookeeper协调的分布式消息中间系统。
1.5 kafka的特性
- 高吞吐量、低延迟:每秒可以处理几十万条信息,它的延迟只有几毫秒,它可以提高负载均衡和消费能力
- 可扩展性:kafka集群支持热扩展
- 持久性、可靠性:消息被持久化到本地磁盘,支持数据备份防止数据丢失
- 容错性:允许群集中节点失败
- 高并发:支持千万客户端同时进行读写操作
1.6 kafka的系统架构
- broker——服务器
一台kafka服务器就是一个broker,一个由多个broker组成,一个broker可以容纳多个topic
- topic——主题
类似于数据库中的表或者ES的index(索引),生产者消费者都面相一个topic,物理上不同topic的消息分开存储
- partition——分区
一个topic可以分割成多个partition,每个partition都是有序的,kafka只保证partition里的数据是有序,不保证partition的顺序
每个partition中的数据使用多个segment文件存储
1.6.1 分区的原因
-
方便在急群众扩展,每个partition调整来适应它的机器,一个topic可以由多个partition组成,因此集群可以适应任意大小的数据
-
可以调高并发
-
replica——副本
-
leader——只负责数据的读写
-
follower——只负责数据的备份
-
producer——数据的发布者
-
Consumer——消费者
-
Consumer Group(GC)——消费者组
-
offset偏移量:默认生命周期为1周(7*24小时)
-
zookeeper:kafka通过zookeeper来存储集群的meta信息。作用:生产者push数据到kafka集群,就必须要找到kafka集群的节点在哪,这些都是通过zookeeper寻找的。消费者消费哪一条数据也需要zookeeper的支持,zookeeper获取offset,offset记录上一次数据消费到哪,这样可以接着上一条数据进行消费
注意:同一组内不能消费同一组的partition
二、kafka拓展
2.1 Kafka工作流程及文件存储机制
Kafka 中消息是以 topic 进行分类的,生产者生产消息,消费者消费消息,且都是面向 topic 的
为了防止生产者不断生产消息追加到log中而导致数据定位效率低下。Kafka采取了分片和索引机制,将每个partition分为多个segment。每个segment对应两个文件:“.index” 文件和 “.log” 文件。这些文件位于一个文件夹下,该文件夹的命名规则为:topic名称+分区序号。
index 和 log 文件以当前 segment 的第一条消息的 offset 命名。
.index——文件存储大量的索引信息
.log——文件存储大量的数据
索引文件中的元数据——对应数据文件中message的物理偏移地址
2.2 数据可靠性
为保证producer发送的数据,能可靠的发送到指定的 topic,topic的每个partition收到 producer 发送的数据后, 都需要向producer发送 ack(acknowledgement 确认收到),如果producer收到 ack,就会进行下一轮的发送,否则重新发送数据
2.3 数据一致性
- LEO:指的是每个副本最大的offset
- HW:指的是消费者能见到的最大的offset,即所有副本中最小的LEO
2.3.1 follower故障
follower发生故障后会被临时踢出ISR(Leader 维护的一个和Leader保持同步的Follower集合),待该follower 恢复后,follower会读取本地磁盘记录的上次的HW,并将log文件高于HW的部分截取掉,从HW开始向 leader 进行同步。等该follower的LEO 大于等于该 Partition的HW,即follower追上leader之后,就可以重新加入ISR了
2.3.2 leader故障
leader发生故障之后,会从ISR中选出一个新的leader之后,为保证多个副本之间的数据一致性,其余的follower会先将各自的 log 文件高于HW的部分截掉,然后从新的leader同步数据
2.4 ack应答机制
producer向leader发送数据时,可以通过 request.required.acks 参数来设置数据可靠性的级别:
级别 | 功能 | 优点 | 缺点 | 注意事项 |
---|---|---|---|---|
0 | producer无需等待来自broker的确认而继续发送下一批消息 | 传输效率高 | 可靠性低 | borker故障时可能会造成数据丢失 |
1 | producer在ISR中的leader已成功收到的数据并得到确认后发送下一条message | 传输率较高 | 可靠性较低 | follower同步成功之前leader故障,那么将会丢失数据 |
-1 | producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成 | 传输效率低 | 可靠性高 | follower 同步完成后,broker 发送ack 之前,leader 发生故障,那么会造成数据重复 |
原文地址:https://blog.csdn.net/sea_bunch/article/details/137864052
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!