消息系统-kafka之一 系统简介

  • 作者: 凯哥Java(公众号:凯哥Java)
  • kafka
  • 时间:2020-11-15 16:45
  • 4885人已阅读
简介 最近在研究消息中间件kafka,下面简单介绍一下kafka消息系统,首先,为什么使用消息中间件,有哪些消息中间件,为什么选择kafka为什么使用消息系统?1.首先就是消息系统的高性能,即使是非常普通的硬件可以支撑一秒几十万的消息2.消息队列对应用之间进行了解耦,应用之间不存在强依赖3.消息队列可以对消息数据进行持久化,这样即使处理消息的进程全部挂掉,也不会丢失已经加入消息队列的数据,对很多关键的业

🔔🔔好消息!好消息!🔔🔔

 如果您需要注册ChatGPT,想要升级ChatGPT4。凯哥可以代注册ChatGPT账号代升级ChatGPT4

有需要的朋友👉:微信号 kaigejava2022

最近在研究消息中间件kafka,下面简单介绍一下kafka消息系统,首先,为什么使用消息中间件,有哪些消息中间件,为什么选择kafka

为什么使用消息系统?

1.首先就是消息系统的高性能,即使是非常普通的硬件可以支撑一秒几十万的消息

2.消息队列对应用之间进行了解耦,应用之间不存在强依赖

3.消息队列可以对消息数据进行持久化,这样即使处理消息的进程全部挂掉,也不会丢失已经加入消息队列的数据,对很多关键的业务来说,规避数据丢失的风险是至关重要的

4.由于消息队列对应用之间进行了解耦,这也大大的增加了系统的可扩展性,从消息的产出和消息的消费

5.应对突发高并发流量,在访问量剧增的情况下,使用消息队列把请求进行缓冲和筛选,防止突发流量冲击后端接口,导致应用超时或是直接拒绝服务

6.使用消息队列可以在一定程度上保证数据的顺序性

那么有哪些消息中间件呢?

现在比较流行的MQ有:ActiveMQ,kafka,RabbitMQ,Redis,jafka,ZeroMQ

值得一提的是Redis作为基于key-value的NoSQL数据库,也可以作消息队列,并且完全可以作为一个轻量级的队列服务器来使用;除此之外,AMQ,RabbitMQ,ZeroMQ都是相对比较重量级的消息系统,尤其是ZeroMQ,虽然称作是最快的消息队列系统,但是复杂的配置和技术框架让很多开发者望而却步;然而kafka和jafka,作为一个高性能跨语言分布式发布/订阅消息队列系统,在具有以上消息系统的所有优点之外,在量级上相对于AMQ之类来说也是非常轻量级的。

为什么选择kafka?

kafka的优势如下:

1.可靠性,kafka的partition机制和replication机制,容错机制使消息的传递有着很高的可靠性

2.kafka支持集群规模的热扩展

3.kafka的高性能,在数据的发布和订阅过程中,都能够保证数据的高吞吐量,即使在TB的数据存储情况下,仍然表现出很好的稳定性

4.kafka的消息状态由consumer处理,可以根据重设offset实现消息的重复消费(这个也是我在做任务调度的时候,选择kafka的原因)

kafka架构简介

kafka可以实现两种类型的消息传递:点对点(单播),和订阅/发布(广播)

点对点:看字面意思,就是消息由一个点传递到另一个点,也确实是这样子的,消息生产者生产消息并且发送到queue中,然后消费者从队列中取出消息进行消费,但是需要注意的是,queue虽然有可能存在多个消费者,但是对于一个消息,只能被一个消费者消费到。

订阅/发布:这个更好理解了,就像散布消息那样,消息生产者把消息发布到topic,如果同时有多个消费者订阅了该消息,那么发布到topic的消息会被所有的订阅的消费者消费

首先先来看下kafka的系统架构,然后再来解释一下kafka是如何实现这两种消息传递模式的。

095f090125ddc946d1ea1a18bf756fcc.png

从上图看到,一个典型的kafka集群中包含若干个producer(可以是前端的pageview ,或者是是服务器日志,系统CPU,memory等),若干的broker(kafka支持水平扩展,一般broker数量越多,集群吞吐量越高),若干的consumer group,以及一个zookeeper集群。kafka通过zookeeper管理集群配置,选举leader,以及在consumer group发生改变时进行rebalance,producer使用push模式将消息发布到broker,consumer使用pull 模式从broker订阅并消费消息

下面介绍个系统中的各个角色:

producer:消息的生产者,就是向kafka broker push消息的客户端

 

consumer: 消息的消费者,从 kafka broker pull 消息的客户端

broker:就是 kafka服务器,一台kafka服务器就是一个broker,一个集群由多个broker组成,一个broker可以容纳多个 topic

topic & partition:topic在逻辑上可以认为是一个queue,每条消费都必须指定它的topic,可以简单理解必须指明把这条消息放到哪个queue里面,为了使得kafka的吞吐量可以得到线性的提升,物理机把topic分为了一个或则是多个partition

在这里有必要说一下 consumer group,根据consumer group的不同实现,可以实现消息传递的单播还是广播。

 

topic 可以有多个 consumer group,topic的消息会在概念上复制给所有的consumer group,但不是真正的复制 , 如果 topic 中的消息只发送给一个consumer group 那么就是 点对点 单播模式, 如果topic中的消息发送给多个consumer group,那么就是 发布/订阅 广播模式。

由于一个 consumer group 只会把消息发给consumer group中的一台 consumer (leader),所以,如果实现广播的话可以实现 一个topic 对应多个consumer group,但是一个consumer group下面只有一台 consumer; 如果要实现 单播的话,那么就是 一个topic 对应一个consumergroup ,一个consumer group下面多个consumer;

 

 

kafka消息系统里面还有两个名词,一个是partition 还有一个是offset。

partition是对kafka一个很好的扩展,提高了kafka的扩展性,如果一个topic特别大的话,可以拆分成多个partition,然后分布到不同的broker上,这样就相当于是,把一个消息队列拆分成几部分,然后这样的话,broker被push这个topic的消息的时候,就会存储在分散在几个broker的partition上,如果consumer去pull消息的话 也会从这几个分散的broker的partition去拉取。这种设计极大的提高kafka的吞吐量,试想如果是一个特别大的topic的话,系统的I/O必将成为其瓶颈,使用partition对其进行拆分,提高了系统的性能。

同时还需要了解到 partition是一个有序的队列,partition的每条消息都会被分配一个有序的id,也就是下面说的offset,kafka 只能够保证按照一个partition中的消息的顺序去发送消息给consumer,不能保证整个的topic ,也就是多个partition之间的顺序。

offset,kafka的存储文件都是以offset.kafka来命名的,如果您想要查找位于2019位置,就只要找到2018.kafka就可以了,还有就是第一个offset 就是00000000000.kafka。 这个offset是由consumer控制的,正常情况下consumer会在消费完一条消息之后递增该offset,当然consumer也可以将offset设定为一个较小的值,这样话可以进行重新消费消息。因为offset是由consumer控制的,所以kafka broker是无状态的,他不需要标记那些消息消费国,也不需要通过broker去保证同一个consumer group只有一个consumer能消息某一条消息,因此就不需要锁机制,这也为kafka的高吞吐率提供了保证。

https://blog.csdn.net/kaizi_1992/article/details/109705908

TopTop