kafka使用场景

kafka基本介绍

kafka是使用scala语言和java语言编写的一套高可用的消息队列,广泛应用在后端开发里,是后端开发里的一个重要中间件。

kafka的使用场景

1、异步处理

下图为一个订单状态在后端各个模块之间的处理流程,后一个流程必须要等到前一个流程执行完后才能得到执行。当统计完成后,返回给客户端数据。

这样的设计方式,看似很合理,每个模块依照顺序执行,编写起来也相对简单。但是有一个非常大的缺陷,**同步的执行效率非常底下。**很多后端模块执行业务请求时其实是可以并行执行的。

在这里插入图片描述

如果使用kafka,后端的业务流程就可以变成这样。库存模块作为生产者,订单、短信、统计模块作为消费者。相较于同步的执行方式,引入kafka后,订单、短信、统计都可以直接从kafka中拉取库存信息,并行的执行。效率会得到大幅提升。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MSsjHknr-1670000133739)(C:\Users\张茂杰\AppData\Roaming\Typora\typora-user-images\1669982075097.png)]

2、流量削峰

在后端业务开发中,流量削峰是非常重要的。

如果不对客户端的流量进行控制,所有的流量全部打到后端服务中,一旦后端无法支撑流量请求,就很容易造成服务崩溃,大量客户端无法使用后端服务。

互联网app中有大量流量削峰的场景,例如打LOL时经常会排队,玩DNF时经常需要挤频道。。。这都是流量削峰的体现。。

在kafka中可以设定消息队列里消息的最大个数,以此来达到削峰的目的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vXmxtSB5-1670000133740)(C:\Users\张茂杰\AppData\Roaming\Typora\typora-user-images\1669982328273.png)]

3、服务解耦

高内聚,低耦合。是代码设计的重要思想,对于不同的服务之间也是如此。

如果两个服务直接关联,那么耦合度就太高了,类似于下图这样的交互方式。

耦合度太高带来的后果就不用多说了,牵一发而动全身,当一个服务出现问题,可能会导致大量的服务也跟着出现问题。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UVcxWmvX-1670000133740)(C:\Users\张茂杰\AppData\Roaming\Typora\typora-user-images\1669982518733.png)]

软件设计中,引入中间层实现解耦是很常见的方式,例如MVC设计方式就是典型的引入中间层从而实现模块之间的解耦。

kafka同样可以实现这样的功能。并且,kafka支持数据的持久化,如果一个服务在业务运行的过程中启动,也可以拉取到之前的数据。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9LC9bOyi-1670000133740)(C:\Users\张茂杰\AppData\Roaming\Typora\typora-user-images\1669982683799.png)]

4、发布订阅模式

多个消费者可以拉取同一条消息。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TSSm3quX-1670000133741)(C:\Users\张茂杰\AppData\Roaming\Typora\typora-user-images\1669983148378.png)]

5、高并发缓存

如果后端的流量非常庞大,业务服务每秒只能支持1W次请求。如果没有kafka做消息队列。

如果有一段时间每秒的请求数量达到了2W,此时直接打到业务服务上,业务服务器可能就挂了。

加入消息队列后,可以对流量进行一个缓存。业务服务可以按照自己的处理速度去拉取流量。

比如消费完1个再拉取一次流量,这样就能保证业务服务可以按照自己能处理的过来的速度去处理请求,避免因为处理不过来宕机的风险。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aw7S74Vb-1670000133741)(C:\Users\张茂杰\AppData\Roaming\Typora\typora-user-images\1669983272262.png)]

  • 0
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: RabbitMQ和Kafka都是消息队列系统,但它们的使用场景略有不同。 RabbitMQ适用于需要可靠消息传递的场景,例如金融交易、电子商务等。它支持多种消息传递模式,包括点对点、发布/订阅、工作队列等。RabbitMQ还提供了高级功能,如消息确认、持久化、优先级等,可以确保消息传递的可靠性和稳定性。 Kafka适用于需要高吞吐量的场景,例如日志收集、流处理等。它采用分布式架构,可以轻松地扩展到多个节点,支持高并发的消息传递。Kafka还提供了流处理功能,可以实时处理数据流,支持复杂的数据转换和分析。 总之,选择RabbitMQ还是Kafka,取决于具体的业务需求和场景。 ### 回答2: RabbitMQ和Kafka都是流行的消息代理系统,它们的使用场景有所不同。 RabbitMQ适合处理复杂、逻辑较强的消息传递场景,比如高可靠性、高并发、多样的消息传递方式。RabbitMQ支持多种消息传递模式,包括点对点、发布/订阅、消息队列和主题等,可以满足不同场景下的需求。RabbitMQ的广泛使用场景包括电子商务、金融交易、电信网络等。RabbitMQ的高可靠性、高吞吐量、大规模集群和灵活的体系结构,使得它能够应对各种复杂的消息传递需求。 而Kafka则专注于高吞吐量、高度可扩展的消息传递场景,以简单、高效、快速为目标。Kafka具有高度的可扩展性,容易与其他系统集成,适合处理流数据(例如日志、实时监控数据、事件数据等)。Kafka使用发布/订阅模式实现消息传递,其优势在于可以快速地处理大规模数据,而不必担心吞吐量或性能问题。由于Kafka的高效性和可扩展性,它被广泛用于分布式系统、大数据处理、日志收集和实时分析等领域。 综上所述,RabbitMQ和Kafka分别适用于不同的场景和需求。对于有复杂逻辑、多样的消息传递方式和高可靠性要求的应用场景,RabbitMQ是一个不错的选择。如果是需要快速、高效地处理大量数据,且需要高度的可扩展性和可靠性,那么Kafka则更加适合。当然,在实际应用中也有可能需要同时使用两个消息代理系统来实现不同的消息传递需求。 ### 回答3: RabbitMQ 和 Kafka 都是消息队列系统,不同之处在于其设计的重点不同,因此在使用场景上也有所不同。 RabbitMQ 适用于需要高度可靠性和灵活性的应用场景。它为开发人员提供了一些很好的特性,如事务、优先级队列、消息确认和持久化等。这些特性使得 RabbitMQ 能够确保消息不会丢失并且确保消息会按照正确的顺序被处理。RabbitMQ 通常用于企业级应用程序中,如金融、电信、电子商务等领域,因为这些行业对于数据的安全和可靠性要求较高。 Kafka 适用于需要处理大量数据的应用场景,例如日志处理、大数据分析等。 Kafka 的设计使其可以处理数TB的数据,能够扩展以处理需要处理的数据的增长,同时保证很高的吞吐量和低延迟。凭借其分布式、可伸缩性的架构,Kafka 被广泛应用于社交媒体、移动应用程序、在线广告等领域。 综上所述,RabbitMQ 和 Kafka 在不同的场景下各有其优势。RabbitMQ 适用于高可靠性、有高要求子业务时的应用,而 Kafka 更适合处理大数据流,能够扩展以处理需要处理的数据的增长,同时保证高吞吐量和低延迟。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值