关于java:Java面试问题汇总消息队列

9次阅读

共计 1828 个字符,预计需要花费 5 分钟才能阅读完成。

14. 音讯队列

《深刻了解 Kafka 外围设计与实际原理》

Kafka

说一下 Kafka

Kafka 是一款高性能的消息中间件,包含 Producer,Consumer,Broker,以及 Zookeeper,Zookeeper 用来负责集群元数据管理,控制器的选举等操作,Producer 将音讯发送到 Broker,由 Broker 负责将收到的音讯存储到磁盘中,Consumer 负责从 Broker 订阅并生产音讯。Kafka 中的音讯是以主题为单位,主题能够散布在不同的分区,分区能够散布于不同的 Broker,分区有 Leader 与正本 follower,follower 负责从 leader 同步数据,leader 负责读写申请

音讯的幂等性解决思路

次要是避免音讯反复生产,通过业务方去保障音讯的幂等性,每条音讯设置一个惟一 Id,数据库的话通过惟一索引。

音讯队列如何保障高可用

kafka 能够有多个 Borker,一个 topic 会将数据存储在不同的 partiton 上, 并且有多个副原本同步数据,但只会有一个 leader,数据以 Log 的模式存储在硬盘中,并且记录了生产的 offset。如果 leader 挂掉,会从 ISR 汇合中的正本选出一个做为 leader。

Kafka 新建的分区会在哪个目录下创立

在启动 Kafka 集群之前,咱们须要配置好 log.dirs 参数,其值是 kafka 数据的寄存目录,这个参数能够配置多个目录,目录之间应用逗号分隔,通常这些目录是散布在不同的磁盘上用于进步读写性能。

也能够配置 log.dir 参数,含意一样,只须要设置其中一个即可。如果 log.dirs 参数只配置了一个目录,那么调配到各个 Broker 上的分区必定只能在这个目录下创立文件夹用于存储数据。

然而如果 log.dirs 参数配置了多个目录,Kafka 会在含有分区目录起码的文件夹中创立新的分区目录,分区目录名为 Topic 名 + 分区 ID。 留神,是分区文件夹总数起码的目录,而不是磁盘使用量起码的目录

Kafka 的 ack 机制

ack 有三个值 0 1 -1

0 : 生产者不会期待 borker 返回,提早最低然而存储的保障最弱当 server 挂掉的时候就会丢数据

1 : 期待 leader 确认音讯返回,但如果 Leader 挂掉后不保障是否复制实现

-1: 期待所有的正本确认音讯返回

如何保障音讯可靠性

kafka 保障音讯可靠性,能够通过如下几个配置:

  1. 生产者配置 acks = all (-1) ISR 中的所有正本都写入胜利,才代表该音讯发送胜利
  2. min.insync.replicas 默认为 1,指定了 ISR 汇合中最小的正本数,不满足条件就会抛出 NotEnoughReplicasException 或 NotEnoughReplicasAfterAppendException, 也就是必须保障有一个正本同步数据跟得上 leader
  3. unclean.leader.election.enable 默认为 false, 当 leader 下线的时候能够从非 ISR 汇合中选举新的 leader,这样能进步可用性,但会丢数据
  4. 配置 log.flush.interval.messages 和 log.flush.interval.ms 同步刷盘策略
  5. 生产端手动提交位移,enable.auto.commit 设置为 false,主动提交会带来反复生产和音讯失落的问题,客户端如果音讯生产失败应该放入死信队列,以便前期排除故障
  6. 回溯生产性能,音讯貌似曾经胜利生产,但理论音讯失败了,不晓得是什么谬误造成的,就能够通过回溯生产弥补,或者复现“失落”,seek() 办法

音讯积压问题

如果音讯积压了太多,始终生产不了,须要查看是不是 consumer 有问题,或者服务端磁盘是否快满了。

  1. consumer 有问题就修复问题。但因为积压的数据太多,用原程序生产还是太慢。就须要扩容,新建长期 topic, 将分区改为原来的 10 倍,写程序将原来积压的音讯发送到新建的 topic 中,启动 10 倍的机器来生产这些数据
  2. 服务端磁盘满,就只能扩容服务端磁盘,再采纳第一种方法来修复问题

kafka 的分区策略

消费者客户端参数 partition.assignment.strategy 来配置生产分区策略

  1. RangeAssignor 默认调配策略 通过 分区数 / 消费者总数 来取得一个跨度进行调配
  2. RoundRobinAssignor 轮询调配策略
  3. StickyAssignor 可能使分区的调配尽可能与上一次保持一致,防止适度重调配
  4. 自定义调配,实现 PartitionAssignor 接口
正文完
 0