消息队列

为什么要用消息队列

异步处理一般都通过回调来进行通知

上面圈住的部分就是kafka持久化机制

kafka

队列模型了解吗？Kafka 的消息模型知道吗？

虽然是发布订阅模型，kafka有多分区机制（和消费者组一起实现负载均衡），组内的所有消费者协调在一起来消费订阅主题(subscribed topics)的所有分区(partition)。当然，每个分区只能由同一个消费组内的一个consumer来消费。

消费者组的三个重要特性：

划重点：Kafka 中的 Partition（分区）实际上可以对应成为消息队列中的队列。

kafka多副本选举机制

Kafka集群controller的选举

无所不能的controller ：https://blog.csdn.net/shenshouniu/article/details/84716671

Kafka的Leader Election方案在所有broker中选出一个controller，所有Partition的Leader选举都由controller决定。
controller会将Leader的改变直接通过RPC的方式(比ZooKeeper Queue的方式更高效)通知需为此作为响应的Broker。

每个Broker都会在Controller Path (/controller)上注册一个Watch。当前Controller失败时，对应的Controller Path会自动消失(因为它是ephemeralNode)，此时该Watch被fire，所有“活” 着的Broker都会去竞选成为新的Controller (创建新的Controller Path)，但是只会有一个竞选成功(这点由Zookeeper保证)。竞选成功者即为新的Leader，竞选失败者则重新在新的Controller Path上注册Watch。因为Zookeeper的Watch是一次性的，被fire一次之后即失效，所以需要重新注册。

Zookeeper 在 Kafka 中的作用知道吗？

ZooKeeper 主要为 Kafka 提供元数据的管理的功能。

Kafka 如何保证消息的消费顺序？

offset存储

早期版本：

kafka持久化

Kafka 为了得到更高的性能和吞吐量，将数据异步批量的存储在磁盘中。

Kafka 如何保证消息不丢失

生产者丢失消息的情况

生产者(Producer) 调用send方法发送消息之后，消息可能因为网络问题并没有发送过去。为了提升效率，减少 IO，Producer 在发送数据时可以将多个请求进行合并后发送。

消费者丢失消息的情况

Kafka 弄丢了消息

在 kafka 服务端设置min.insync.replicas参数：这个值必须大于 1，这个是要求一个 leader 至少感知到有至少一个 follower 还跟自己保持联系，没掉队，这样才能确保 leader 挂了还有一个 follower。

通过上面的几种方式并不能保证消息一定不会丢失。还需要一种机制来check消息是否丢失。解决思路是在消息生产端给每个发出的消息都指定一个全局唯一ID。或者附加一个连续递增的版本号，然后再消费段所对应的版本校验。

落地的话，可以使用拦截器机制。在生产者发送消息前用拦截器将消息版本号注入信息中。然后在消费者收到消息后，通过拦截器检测版本号的连续性或者消费状态，这样做的好处是代码不会入侵到业务代码中。可以通过单独的任务来定位丢失的消息做进一步的排查。

Kafka 如何保证消息不重复消费

auto.commit.interval.ms kafka设置自动提交间隔参数。默认是5000 即5S。

kafka消息积压问题排查以及解决思路

如何应对消息挤压？

1 如果是线上突发问题，要临时扩容增加消费端的数量。与此同时，降级一些非核心业务。通过扩容和降级承担流量。

2 其次，才是排查解决异常问题。比如通过监控和日志等手段分析是否消费端的业务逻辑代码出现了问题，优化消费端的业务处理逻辑。

3 如果确认是消费端的处理能力不足，可以通过水平扩容来提高消费端的并发处理能力。这里有一个考点需要注意，扩容消费者的实例数量的同时，必须同步扩容topic分区数量。确保分区数和消费者的实例数相等。（因为kafka约定一个分区只能被一个消费者消费，并且分区是单线程消费。因此，消费者实例大于分区数量是没有意义的。）