最终 Kafka 将自己退化成了一个「存储系统」。因此，海量消息的存储问题就是 Kafka 架构设计中的最大技术难点。

2. Kafka 架构设计的任督二脉

下面我们再接着分析下：Kafka 究竟是如何解决存储问题的?

面对海量数据，单机的存储容量和读写性能肯定有限，大家很容易想到一种存储方案：对数据进行分片存储。这种方案在我们实际工作中也非常常见：

• 1、比如数据库设计中，当单表的数据量达到几千万或者上亿时，我们会将它拆分成多个库或者多张表。
• 2、比如缓存设计中，当单个 Redis 实例的数据量达到几十个 G 引发性能瓶颈时，我们会将单机架构改成分片集群架构。

类似的拆分思想在 HDFS、ElasticSearch 等中间件中都能看到。

Kafka 也不例外，它同样采用了这种水平拆分方案。在 Kafka 的术语中，拆分后的数据子集叫做 Partition(分区)，各个分区的数据合集即全量数据。

我们再来看下 Kafka 中的 Partition 具体是如何工作的?举一个很形象的例子，如果我们把「Kafka」类比成「高速公路」：

• 1、当大家听到京广高速的时候，知道这是一条从北京到广州的高速路，这是逻辑上的叫法，可以理解成 Kafka 中的 Topic(主题)。
• 2、一条高速路通常会有多个车道进行分流，每个车道上的车都是通往一个目的地的(属于同一个Topic)，这里所说的车道便是 Partition。

这样，一条消息的流转路径就如下图所示，先走主题路由，然后走分区路由，最终决定这条消息该发往哪个分区。