kafka-消息中间件(one-day)【概论】

kafka特性:

  • 快速性:面对海量消息,具有快速存储和查询的实时性,虽然他是将消息存在磁盘,但是他是以顺序读写的方式访问磁盘,提高了性能
复制代码
磁盘总有满的一天,怎样解决这个问题?
日志清理,日志压缩
  • 批量性:支持批量读写消息,并会对消息进行压缩

  • 分区性:支持消息分区,分区内消息顺序传输,分区之间可以并发操作

  • 容灭性:服务端:每个topic可以分为多个分区,每个分区的消息是不同的,每个分区有多个副本,只有leader负责读写,其他人负责同步消息到分区就行了,要是leader出现故障,在follower中重新进行选举就行了;消费端:消费者通过pull从服务端拉取消息的时候都会保存自己的消费位置

  • 消费者,分区,topic,消费者组之间的关系

复制代码
一个分区可以分配给一个消费者,一个消费者可以同时处理多个分区,多个消费者可以构成消费者组,一个消费者组可以订阅多个topic,要是一个消费者组里面的消费者增加或者减少,要通过rebalance进行平衡处理
  • 异步通信性:例如:A和B系统要通过网络进行数据交换,A可以将数据放在kafka中,然后A去处理别的事情,当B从kafka中取消息并处理后返回给kafka后,A将消息取了应解析响应

kafka元素定义

  • 消息:由key和value[]byte数组组成,key是为了保证同一key都在同一个分区,value才是真实的数据

  • toipc&分区&log

复制代码
topic:一个消费集合;一个topic可以有多个分区,不同分区的消息是不同的,每个消息在被添加在分区的时候,会分配一个offset,因此可以保证分区内消息的有序性,但是一个topic不同分区之间是没有有序性的,同一个topic的不同分区可以分配给不同的broker,来增加kfaka的并行处理能力
分区和Log:一个分区对应着一个log,消息写入分区实际就是写入log对应磁盘文件夹下面的Segment,Segment是有大小限制的,超大小限制会创建新的Segment,因为kafka采取顺序IO,只会在新的Segmen添加消息,索引文件采用稀疏索引
  • 保留策略:产生原因:无论消息是否被消费,都会存在磁盘,但是这样磁盘就会占满,因此就出现了他,通过启动一个线程,定期进行检查,有两种需要删除,1,超过指定时间就可以删出。2,超过指定日志大小就会删出

  • 日志压缩:消息间的key-value的value是不断变化的,启动线程,定期将key保留最新value即可

  • broker:kafka server,他主要负责接收发来的消息,分配offset,将消息保存在磁盘;接收消费者或者其他broker的请求,根据请求做相应处理并返回响应,一般同一分区的多个副本会在不同的broker

  • isr集合:可用且消息量和leader差不多的集合,需满足两个条件:1,副本所在节点必须维持着与ZooKeeper的连接;副本最后一条消息的offset与Leader副本的最后一条消息的offset之间的差值不能超出指定的阈值,例如:要是有哪个副本因某种原因无法拉取leader的消息进行同步,超出某个阈值就会被踢出isr集合,要是他之后正常并且跟上了,就又加进来,总结就是要跟leader的数据差不多多

  • hw:一个offset,hw对于消费者来说是不可见的,但是消费者只能拉取hw之前的消息,他是由leader管理的,当所有的isr都保存消息到了hw这个offset时,leader就会递增hw的值,hw之前的证明leader和isr都有,被称为commit,简单来说,他就像是一个都得有的及格线

  • leo:所有副本都有的一个offset,指向追加到当前副本的最后一个消息的offset,当一个分区内添加了消息,那么他的offset就会增加

kafka为什么要有上面的设计?
  • 同步复制和异步复制都有一些问题,将其结合才是最好的答案

  • 同步复制:主要是看hw,但是这里看的不是isr和leader又就和可以递增hw,而是全部,要是一个follower副本宕机,那么hw就不能递增因为没有达到同意到达一个点,那么消费者一直只能拉取hw之前的

  • 异步复制:leader在收到消息就认为消息提交成功,但是可能其他的follower还没有同步到,那要是此时leader驾崩了,从follower中选取的新的leader就没有leader消息,出现了消息丢失的情况

  • 那么kafka就引入了isr,要是某个follower延迟过高,就提出isr,hw以就可以递增,要是leader宕机,就从isr中选拔,他们都有hw之前的信息,避免了消息的丢失

  • Cluster:多个broker可集成一个Cluster,Cluster会选择一个broker当作Controller,Controller时指挥中心,当他出现故障,就进行选拔新的Controller从broker中

  • 消费者:从topic拉取消息,自己维护消费分区内的offset,可以实现一定的灵活性,比如,可以跳过某些key,或者对某些key进行反复消费

  • 消费者组:消费者组订阅的topic的每个分区对应一个消费者,可以实现广播:多个消费者组订阅了一个topic,那就时的多个在不同消费者组里面的消费者对应一个分区;独播:将所有的消费者放在一个消费者族里面,也就是只有一个消费者组处理这个topic,他里面的分区也就只给一个消费者

消费者的水平扩展和故障转移

一个消费者可以消费多个分区,当他处理不过来的时候,就需要通过添加消费者进行reblance来实现水平扩展 当消费者出现故障时,他所负责的分区要转移给其他消费者

每天进步一点点!
疑问(欢迎评论区大佬们的发言-通俗易懂哈)
  • 稀疏索引是什么?

  • leo的作用是什么?

相关推荐
Python私教6 小时前
从“Hello World”到“高并发中间件”:Go 语言 2025 系统学习路线图
学习·中间件·golang
UrSpecial7 小时前
进程间通信:消息队列
中间件
EndingCoder3 天前
Next.js 中间件:自定义请求处理
开发语言·前端·javascript·react.js·中间件·全栈·next.js
十五年专注C++开发3 天前
通信中间件 Fast DDS(一) :编译、安装和测试
linux·c++·windows·中间件·cmake·vcpkg
在未来等你5 天前
RabbitMQ面试精讲 Day 17:消费者调优与并发消费
中间件·面试·消息队列·rabbitmq
茶茶只知道学习6 天前
Express中间件和路由及响应方法
中间件·express
汪随安6 天前
Dokcer创建中间件环境
中间件
在未来等你7 天前
RabbitMQ面试精讲 Day 16:生产者优化策略与实践
中间件·面试·消息队列·rabbitmq
vision_wei_7 天前
Redis中间件(四):主从同步与对象模型
网络·数据库·c++·redis·缓存·中间件
在未来等你7 天前
RabbitMQ面试精讲 Day 13:HAProxy与负载均衡配置
中间件·面试·消息队列·rabbitmq