《吃透 MQ 系列》之打通 Kafka 的任督二脉

大家好，我是武哥。这是《吃透 MQ 系列》的第三篇，有关 Kafka 的架构设计。

这篇文章将带着大家参透：到底什么是 Kafka 架构设计的任督二脉？

把握住了这个关键点，我相信你将能更好地理解 Kafka 的架构设计，进而顺藤摸瓜地掌握 Kafka 的核心技术方案。

废话不多说了，开始发车。

 1. Kafka 的技术难点究竟在哪？  

前一篇文章《扒开 Kafka 的神秘面纱》 交代了两个关键信息：

1、Kafka 为实时日志流而生，要处理的并发和数据量非常大。可见，Kafka 本身就是一个高并发系统，它必然会遇到高并发场景下典型的三高挑战：高性能、高可用和高扩展。

2、为了简化实现的复杂度，Kafka 最终采用了很巧妙的消息模型：它将所有消息进行了持久化存储，让消费者自己各取所需，想取哪个消息，想什么时候取都行，只需要传递一个消息的 offset 进行拉取即可。

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

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

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

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

1、比如数据库设计中，当单表的数据量达到几千万或者上亿时，我们会将它拆分成多个库或者多张表。

2、比如缓存设计中，当单个 Redis 实例的数据量达到几十个 G 引发性能瓶颈时，我们会将单机架构改成分片集群架构。

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

<