同程面试（部分）（未完全解析）

qq_23204557

已于 2023-07-29 07:42:35 修改

阅读量1.2k

点赞数

分类专栏：面试 # dubbo/grpc # MQ 文章标签： dubbo rpc 注册中心元数据中心 Kafka 幂等性 Kafka幂等性

于 2023-05-22 19:40:17 首次发布

本文链接：https://blog.csdn.net/qq_23204557/article/details/130795578

版权

面试同时被 3 个专栏收录

103 篇文章 0 订阅

订阅专栏

11 篇文章 0 订阅

订阅专栏

dubbo/grpc

6 篇文章 0 订阅

订阅专栏

一面

Java直接内存有了解吗？为什么Java NIO的效率更高？Netty用到很多NIO，来了一个请求后Netty是怎么分发的，它里面有哪些角色？粘包、拆包怎么解决？
为什么建立TCP连接是三次握手，而不是四次？seq的作用？
设计一个简单的RPC框架。
- Dubbo的新版本对注册中心这一块有什么变化？
  参考答案¹,²：Dubbo 之前的版本中，直接从注册中心里面获取 Provider 端的服务信息，获取到的信息已经是一个完整的可调用的服务信息。Dubbo3.0新支持应用维度的服务注册和发现。

本质上来说，应用维度注册信息 + 服务元数据 = 服务维度注册信息。或者说，应用维度注册，只是一种重新组织这些信息的方式。

需要知道调用的服务方法名，入参出参的详细信息。所以这部分信息也是需要存储下来的。但是这部分信息非常大，每个服务中可能有 10 多个方法，每个方法可能有三四个方法入参，入参和出参的完整数据结构往往非常复杂。这部分数据信息也叫做服务的元数据信息。

Provider 往注册中心写的时候，将整个数据的写入分成两部分：写入注册中心；写入元数据中心。
注册中心作为服务的注册和发现，更加关注数据的实时性和有效性(watch 机制)。。。所以注册中心中，只需要存储 IP 和端口。元数据中心中存储 URL 中除 IP和端口外的其他信息，加上服务测试需要的服务方法名，服务方法的出入参信息。元数据是一个 KEY-VALUES的持久化存储，是独立于注册中心的存储，它不需要有 watch 的机制，而只需要提供持久化存储。图中使用的的 KEY VALUE 存储是 Redis。。。可以自己实现 DB 存储，或者其他持久化存储的方式。

Consumer 端获取 Provider 列表信息的改造：

Dubbo 之前的版本中，直接从注册中心里面获取 Provider端的服务信息，获取到的信息已经是一个完整的可调用的服务信息。但是 Provider 端写入改造之后，原有 Consumer 端获取的Provider 服务信息的方式不可用了。除了从注册中心获取到的数据之外，还需要从元数据中心里拿到元数据信息，然后对这两部分数据做一个Merge 之后才能构建出完整的可调用的服务信息。

- 如果服务有节点宕机了，注册中心里它能及时下掉吗？注册中心怎么选型？参考答案³：

在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用。。。那么将无法处理该请求。所以说，Zookeeper不能保证服务可用性。

不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。。。Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性）

- - Eureka是如何保证最终一致性的？参考答案⁴：

Peer to Peer 模式，副本间不分主从，任何副本都可以接收写操作，然后每个副本间互相进行数据更新。

如果自己的信息变更是另一个Eureka Server同步过来的，这是再同步回去的话就出现数据同步死循环了。。。数据的新旧一般是通过版本号来定义的

- - Eureka集群规模非常大时会出问题吗，比如有几千个节点？
springboot注解的原理

二面

多租户系统下的聊天记录表，ShardingJDBC分库分表对租户ID采用哈希取模算法，如何解决因租户冷热不均造成数据倾斜？比如5个大租户的聊天记录很多，另外95个小租户的聊天记录比较少，希望这5个大租户各有一个表，另外95个小租户的记录全部路由到另外一个表，如何设计？
如果后来95个小租户中有一个小租户晋升为大租户，如何在用户基本无感知的情况下实现数据迁移？可以用流式处理来实现吗？
Kafka为什么高效⁵
kafka broker能做到收到消息精确一次吗？参考答案⁶：设置acks = all，可以保证 Producer 到 Server 之间不会丢失数据，即 At Least Once 语义。
0.11 版本的 Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指 Producer 不论向 Server 发送多少次重复数据，Server 端都只会持久化一条。幂等性结合 At Least Once 语义，就构成了 Kafka 的 Exactly Once 语义。即：At Least Once（ACK=-1） + 幂等性 = Exactly Once

要启用幂等性，只需要将 Producer 的参数中 enable.idompotence 设置为 true即可。Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的 Producer 在初始化的时候会被分配一个PID，发往同一 Partition 的消息会附带 Sequence Number。而Broker 端会对<PID, Partition, SeqNumber>做缓存，当具有相同主键的消息提交时，Broker 只会持久化一条。

至于消费者端的严格一次，参考下面官网的文章 Apache Kafka 4.6 Message Delivery Semantics：

So what about exactly once semantics …
When writing to an external system, the limitation is in the need to coordinate the consumer’s position with what is actually stored as output. The classic way of achieving this would be to introduce a two-phase commit between the storage of the consumer position and the storage of the consumers output. But this can be handled more simply and generally by letting the consumer store its offset in the same place as its output.

以及⁶，我总结为：方法1：数据处理完后再手动提交偏移量+幂等性去重处理；方法2：（数据处理+修改偏移量）组成事务。