当前位置:   article > 正文

kafka topic数量上限_Kafka基础知识索引,面试必备

kafka topic数量上限
c5fd99baefbf97eb24baf6aebc67a841.gif

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

我们在《360度测试:KAFKA会丢数据么?其高可用是否满足需求?》

这篇文章中,详细说明了KAFKA是否适合用在业务系统中。但有些朋友,还不知道KAFKA为何物,以及它为何存在。这在工作和面试中是比较吃亏的,因为不知道什么时候起,KAFKA似乎成了一种工程师的必备技能。

一些观念的修正

从 0.9 版本开始,Kafka 的标语已经从“一个高吞吐量,分布式的消息系统”改为”一个分布式流平台“。

Kafka不仅仅是一个队列,而且是一个存储,有超强的堆积能力。

Kafka不仅用在吞吐量高的大数据场景,也可以用在有事务要求的业务系统上,但性能较低。

Kafka不是Topic越多越好,由于其设计原理,在数量达到阈值后,其性能和Topic数量成反比。

引入了消息队列,就等于引入了异步,不管你是出于什么目的。这通常意味着业务流程的改变,甚至产品体验的变更。

消息系统是什么

典型场景

e330b2901f08d654291e25f4f14db72e.png

上图是一些小系统的典型架构。考虑订单的业务场景,有大量的请求指向我们的业务系统,如果直接经过复杂的业务逻辑进入业务表,将会有大量请求超时失败。所以我们加入了一张中间缓冲表(或者Redis),用来承接用户的请求。然后,有一个定时任务,不断的从缓冲表中获取数据,进行真正的业务逻辑处理。

这种设计有以下几个问题:

  • 定时任务的轮询间隔不好控制。业务处理容易延迟。
  • 无法横向扩容处理能力,且会引入分布式锁、顺序性保证等问题。
  • 当其他业务也需要这些订单数据的时候,业务逻辑就必须要加入到定时任务里。

当访问量增加、业务逻辑复杂化的时候,消息队列就呼之欲出了。

bf50b0cabf80124655cf3f671cea9e25.png

请求会暂存在消息队列,然后实时通过推(或者拉)的方式进行处理。

在此场景下,消息队列充当了削峰和冗余的组件。

消息系统的作用

削峰 用于承接超出业务系统处理能力的请求,使业务平稳运行。这能够大量节约成本,比如某些秒杀活动&#x

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/寸_铁/article/detail/1009719
推荐阅读
相关标签
  

闽ICP备14008679号