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

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

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

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

一些观念的修正

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

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

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

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

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

消息系统是什么

典型场景

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

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

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

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

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

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

消息系统的作用

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