Kafka消息队列

什么是消息队列

普通版消息队列

说白了就是一个队列,生产者生产多少,放在消息队列中存储,而消费者想要多少拿多少,按序列号消费

**缓存信息 **

生产者与消费者解耦合

那么Kafka如何改进普通版的消息队列

高可用性

随着生产者和消费者都变多，我们会发现它们会同时争抢同一个消息队列，抢不到的一方就得等待，这不纯纯浪费时间吗！
有解决方案吗？有！
首先是对消息进行分类，每一类是一个 topic，然后根据 topic 新增队列的数量，生产者将数据按 topic 投递到不同的队列中，消费者则根据需要订阅不同的 topic。

这就大大降低了 topic 队列的压力。

但单个 topic 的消息还是可能过多，我们可以将单个队列，拆成好几段，

每段就是一个 partition 分区，每个消费者负责一个 partition。

这就大大降低了争抢，提升了消息队列的性能。

高扩展性

随着 partition 变多，如果 partition 都在同一台机器上的话，就会导致单机 cpu 和内存过高，影响整体系统性能。

于是我们可以申请更多的机器，将 partition 分散部署在多台机器上，这每一台机器，

就代表一个 broker。我们可以通过增加 broker 缓解机器 cpu 过高带来的性能问题。

高可用性

如果其中一个 partition 所在的 broker 挂了，那 broker 里所有 partition 的消息就都没了。
有解决方案吗？

我们可以给 partition 多加几个副本，也就是 replicas，将它们分为 Leader 和 Follower。Leader 负责应付生产者和消费者的读写请求，而 Follower 只管同步 Leader 的消息。

持久化和过期策略

刚刚提到的是几个 broker 挂掉的情况，那搞大点，假设所有 broker 都挂了，那岂不是数据全丢了？
为了解决这个问题，我们不能光把数据放内存里，还要持久化到磁盘中，这样哪怕全部 broker 都挂了，数据也不会全丢，重启服务后，也能从磁盘里读出数据，继续工作。

但问题又来了，磁盘总是有限的，这一直往里写数据迟早有一天得炸。
所以我们还可以给数据加上保留策略，也就是所谓的 **

retention policy

**，比如

对磁盘设置容量大小,数据设置过期时间

consumer group 分组消费

在上面我们说的消息队列,只能依靠 offset(序号) 顺序消费,那么我们相从中间的某一个开始消费呢?

给消息队列加入消费者组（consumer group）的概念:

B 和 C 服务各自是一个独立的消费者组，不同消费者组维护自己的消费进度，互不打搅。

ZooKeeper

如果组件太多了，而且每个组件都有自己的数据和状态，所以还需要有个组件去统一维护这些组件的状态信息，于是我们引入 ZooKeeper 组件。

它会定期和 broker 通信，获取 整个 kafka 集群的状态，以此判断 某些 broker 是不是挂了，某些消费组消费到哪了。

参考 -- 小白debug-消息队列 kafka 是什么