Java面试题总结（rpc，kafka）

看到一个rpc的图画的很好

rpc进行网络通信一般用的netty

rpc的泛化调用：

在微服务架构下，我们针对某个 RPC 接口，我们一般有两个角色。

• 服务消费者 (Dubbo Consumer)，发起业务调用或 RPC 通信的 Dubbo 进程

• 服务提供者 (Dubbo Provider)，接收业务调用或 RPC 通信的 Dubbo 进程

服务消费者想要调提供者的接口，那么一般需要引提供者的jar包，然后像调用本地方法一样调用提供者的方法即可，而如果我不想引jar包，还想调提供者的接口，这里就需要泛化调用了，主要的使用场景主要有如下两个：

1、网关服务，因为网关服务需要作为所有rpc服务的调用者，但是又不可能引所有rpc服务的jar包（这样一旦有新的服务发布，就需要修改网关的代码）

2、测试平台

使用：使用GenericService的invoke方法，传入服务提供类的路径，接口名以及入参即可

原理：通过消费端和服务端的filter，来实现泛化调用的传递，在服务端再通过反射构造成对应的方法调用

• org.apache.dubbo.rpc.filter.GenericFilter

• org.apache.dubbo.rpc.filter.GenericImplFilter

来源：我试图通过这篇文章告诉你，什么是神奇的泛化调用。

Kafka使用场景：调用链路太长，对实时性要求不高的请求就可以用队列异步处理，异步带来的不一致问题，可以用job重试保证调用成功

削峰填谷，增加系统的抗压能力。系统解耦，可以拆分成多个微服务

kafka原理介绍（数据存储形式，数据流程，特点，何如保证数据的高可用）

Kafka基于发布订阅模式，通过消费组的形式实现了消费者的横向扩展，通过分区将消费区分，提高了吞吐量，一般分区数最好和消费者数保持一致

数据存储形式：存储到磁盘中，并且时间复杂度是O（1），因为是线性读写，

kafka 如何保证高可用

首先了解一下Kafka存放数据的方式：Kafka集群由多个broker节点组成，一个topic可以划分为多个partition，每个partition存放在不同的broker上，即每个partition只存放部分数据，因此Kafka是一个分布式消息队列

kafka0.8以前，是没有HA机制的，如果任何一个broker宕机了，那么这个节点上面的partition就丢失了，没发写也没法读

0.8以后，提供了HA机制，即replica副本机制，每个partition的数据都会同步到其他机器上，形成自己的多个replica副本，然后所有的replica会选出一个leader，生产和消费都和leader交互，其他replica都是follower，

写的时候leader会将数据同步到所有的follower上去，读就直接读leader，当leader所在的broker宕机，则其他replica会重新选举出一个新的leader，

kafka 能否保证顺序消费

Topic相当于数据库的表的概念，一个Topic下面有多个Partition（分区），分区是真正保存数据的地方，每个分区是一个有序的队列，消息在被追加到分区的时候会分配一个特定的偏移量offset，通过偏移量来保证消息在分区内的顺序性，因此想保证消息的顺序性可以指定key/Partition，或者一个Topic只对应一个Partition

Kafka如何保证消息不丢失：

生产者丢失消息：

producer.send(Object msg) ; 这个发送消息的方式是异步的；fire and forget,发送而不管结果如何；

失败的原因可能有很多，比如网络抖动，发送消息超出大小限制；

怎么破呢？永远使用带有返回值值的消息发送方式，即 producer.send(msg,callback)

通过callback可以准确的告诉你消息是否发送成功了，发送失败了你也可以有处置方法；

网络抖动： 重发

发送消息超出大小：调整消息大小进行发送

这种情况并不是broker丢失消息了，是producer的消息没有提交成功。

如果是broker丢失消息（mq收到消息后在内存中，此时宕机，还没有同步给从节点，并且Kafka是异步刷盘）这种情况可以修改kafka的同步策略：

调整参数 acks = all，即所有partition副本都收到消息了才返回提交消息成功

消费者丢失消息：

消费者如果先更新位移，再提交消息，如果此时出故障，则丢失了消息，因此可以改为先消费消息，再更新位移，关闭自动提交位移改为手动提交

enable.auto.commit=false

可能会带来重复提交的问题，因此消费端最好做一下幂等处理

broker 参数配置如下

Kafka 中的 ISR、AR 是什么

ISR就是动态维护的一个同步状态的副本的集合，ISR在zookeeper中维护

kafka消费 分区的分配策略

提供了两种策略，range和roundrobin

当以下事件发生时，Kafka 将会进行一次分区分配：

• 同一个 Consumer Group 内新增消费者
• 消费者离开当前所属的Consumer Group，包括shuts down 或 crashes
• 订阅的主题新增分区

将分区的所有权从一个消费者移到另一个消费者称为重新平衡（rebalance），如何rebalance就涉及到本文提到的分区分配策略

range 策略：分区和消费者线程均按序号排序，然后分区数除以消费者线程个数，来计算每个消费者线程分配几个分区，如果除不尽，前几个消费者线程将会多消费一个分区

因此可能会产生分配不均的情况

roundrobin策略：使用RoundRobin策略有两个前提条件必须满足：

• 同一个Consumer Group里面的所有消费者的num.streams必须相等；
• 每个消费者订阅的主题必须相同

RoundRobin策略的工作原理：将所有主题的分区组成 TopicAndPartition 列表，然后对 TopicAndPartition 列表按照 hashCode 进行排序

最后按照round-robin风格将分区分别分配给不同的消费者线程。

Rebalance 的触发条件有3个。

• 消费者组成员个数发生变化。例如有新的 consumer 实例加入该消费组或者离开组。
• 订阅的 Topic 个数发生变化。
• 订阅 Topic 的分区数发生变化.

Rebalance 发生时，Group 下所有 consumer 实例都会协调在一起共同参与，kafka 能够保证尽量达到最公平的分配。但是 Rebalance 过程对 consumer group 会造成比较严重的影响。在 Rebalance 的过程中 consumer group 下的所有消费者实例都会停止工作，等待 Rebalance 过程完成。

rebalance过程分为两步，join和sync

1. Join 顾名思义就是加入组。这一步中，所有成员都向coordinator发送JoinGroup请求，请求加入消费组。一旦所有成员都发送了JoinGroup请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader——注意leader和coordinator不是一个概念。leader负责消费分配方案的制定。

1. Sync，这一步leader开始分配消费方案，即哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案封装进SyncGroup请求中发给coordinator，非leader也会发SyncGroup请求，只是内容为空。coordinator接收到分配方案之后会把方案塞进SyncGroup的response中发给各个consumer。这样组内的所有成员就都知道自己应该消费哪些分区了。

后两个我们大可以人为的避免，发生rebalance最常见的原因是消费组成员的变化。

消费者成员正常的添加和停掉导致rebalance，这种情况无法避免，但是时在某些情况下，Consumer 实例会被 Coordinator 错误地认为 “已停止” 从而被“踢出”Group。从而导致rebalance。

当 Consumer Group 完成 Rebalance 之后，每个 Consumer 实例都会定期地向 Coordinator 发送心跳请求，表明它还存活着。如果某个 Consumer 实例不能及时地发送这些心跳请求，Coordinator 就会认为该 Consumer 已经 “死” 了，从而将其从 Group 中移除，然后开启新一轮 Rebalance。这时可能产生重复消费的问题，即如果程序还存活，但是消费者消费的分区已经被回收了，那么提交偏移量的时候就会报错，提交不上去，导致重复消费。这个时间可以通过Consumer 端的参数 session.timeout.ms进行配置。默认值是 10 秒。

kafka的Rebalance问题分析(续)_kafka rebalance引起的问题-CSDN博客

除了这个参数，Consumer 还提供了一个控制发送心跳请求频率的参数，就是 heartbeat.interval.ms。这个值设置得越小，Consumer 实例发送心跳请求的频率就越高。频繁地发送心跳请求会额外消耗带宽资源，但好处是能够更加快速地知晓当前是否开启 Rebalance，因为，目前 Coordinator 通知各个 Consumer 实例开启 Rebalance 的方法，就是将 REBALANCE_NEEDED 标志封装进心跳请求的响应体中。

除了以上两个参数，Consumer 端还有一个参数，用于控制 Consumer 实际消费能力对 Rebalance 的影响，即 max.poll.interval.ms 参数。它限定了 Consumer 端应用程序两次调用 poll 方法的最大时间间隔。它的默认值是 5 分钟，表示你的 Consumer 程序如果在 5 分钟之内无法消费完 poll 方法返回的消息，那么 Consumer 会主动发起 “离开组” 的请求，Coordinator 也会开启新一轮 Rebalance。

通过上面的分析，我们可以看一下那些rebalance是可以避免的：

第一类非必要 Rebalance 是因为未能及时发送心跳，导致 Consumer 被 “踢出”Group 而引发的。这种情况下我们可以设置 session.timeout.ms 和 heartbeat.interval.ms 的值，来尽量避免rebalance的出现。（以下的配置是在网上找到的最佳实践，暂时还没测试过）

• 设置 session.timeout.ms = 6s。
• 设置 heartbeat.interval.ms = 2s。
• 要保证 Consumer 实例在被判定为 “dead” 之前，能够发送至少 3 轮的心跳请求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。

将 session.timeout.ms 设置成 6s 主要是为了让 Coordinator 能够更快地定位已经挂掉的 Consumer，早日把它们踢出 Group。

第二类非必要 Rebalance 是 Consumer 消费时间过长导致的。此时，max.poll.interval.ms 参数值的设置显得尤为关键。如果要避免非预期的 Rebalance，你最好将该参数值设置得大一点，比你的下游最大处理时间稍长一点。

总之，要为业务处理逻辑留下充足的时间。这样，Consumer 就不会因为处理这些消息的时间太长而引发 Rebalance 。

关于Kafka的控制器和协调器：

Kafka核心组件之控制器和协调器 - 简书