Kafka

Kafka：可以接收最大消息默认为1MB****应用场景

消息队列定位就是一些特定场景下解决消息传输问题，比如：异步场景、服务间解耦场景、消息分发场景，以及压力过大时可以通过消息队列削峰。

在这里，是一个DMaaS告警服务，是一个事件监听器做订阅Kafka告警消息，来推送提醒给App。

深入了解一下消息队列，有以下几个问题：

什么情况下需要解耦？

比如发送短信场景，模块A发送消息给B，模块B发送短信给客户，A不需要得到回应，对于A而言只需要触达B流行了，这时候就可以引入消息队列，A将消息投递到了消息队列，B自己去处理，A不用再关心。这样就可以收获更强的稳定性以及接口性能。不用关心下游的返回结果，可维护性增加，可靠性增加，响应时间变快，模块测试更方便。

什么情况下需要削峰？

比如一个模块B一瞬间收到100个请求，如果B承压能力非常差，或者B有什么资源限制，那么这100个请求下来，B可能就挂了或者报错了，这时候就可以引入消息队列，前置服务先将消息打到消息队列，B再根据自己的消费能力逐步消化。一般秒杀场景下适用，用于突发流量而不是持续流量。

什么情况下需要分发消息？

比如信息更新场景，某个用户信息更新了，而B,C,D三个模块都需要缓存这个信息，那么用户信息更新之后就可以发一条信息到消息队列，BCD只要订阅了相关主题，就都可以获得这条信息并对应的缓存更新。

Kafka的优势是什么？

kafka的优点很多，最核心的就三点：高吞吐，高可靠，天然支持分片水平扩展，另外还有一个非常重要的考量就是kafka多年来被广泛使用，并且社区非常活跃。

Kafka的大概框架是怎么样的？

我们可以先把Kafka宏观看作三层：Producer（生产者）、Server（中转者）、Consumer（消费者），生产者发送消息，服务端负责存储消息，消费者负责拉取消息。其中服务端其实就是由多个Broker节点组成，而我们平常说的主题就是在Broker节点上，当然，Topic是个逻辑概念，实际物理存储形式是主题分片，也就是Partition。

有了Topic，为何还要Partition/Kafka为什么要把消息分区？

一般而言一个业务可以用一个主题，但是就算分了Topic，单个业务的信息还是可能会非常多，所以需要能进一步进行分治，也就是一个主题由多个Partition组成，这样相同的主题也具备了更高的并发度。

分片的好处：

1.提高了写入性能，分片使得数据分布在多个Broker中，允许并行处理更多的数据请求，从而提高整体系统的吞吐量。

2.提高消费并发度，因为又多了个分片，那么不同消费者就可以对不同分片进行拉取消费，消费者和分区的关系在后面会单独展开。

3.有了分片，显然后续更容易实现kafka的水平扩展能力。

4.一定程度提高了容错性，分片可以提高系统的容错能力。如果一个服务器上的分片发生故障，其他服务器上的分片可以继续处理数据请求，确保系统的高可用性。

消息存入哪个Partition的规则/Kafka中分区分配原则

一个主题的数据分散成了多个分片，我们就需要有一种方式来决定消息是写入哪个分片，规则如下：

1.如果指定了Partition，那么就是发送到特定的Partition，但是一般情况下，业务其实不需要感知Partition，除非有特殊的理由，否则不建议直接指定要发送到哪个Partition；

2.如果没有指定Partition，但是指定了一个key，那么就是根据key的Hash对Partition数目取模来决定是哪个Partition，也就是说只要发送时制定了相同的key，那么相关消息一定会发送到相同的Partition；

3.如果没有指定Partition，也没有指定key，那么就采取轮询调度算法，也就是每一次把来自用户的请求轮流分配给Partition。

Kafka的ACK的三种机制，ACK = ?

0：生产者在发送消息后不会等待来自服务器的确认，所以生产者实际是不知道消息是否成功，也就无从去重试，生产可靠性是最低的。不可靠，性能最高。

1：生产者会在消息发送后等待主节点的确认，但不会等待所有副本的确认。相对可靠，性能比较高。

all或-1：只有在多有副本都成功写入消息后，生产者才会收到确认，这确保了消息的可靠性，但延迟显然是最高的。可靠，性能低。