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

一面

• 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 + 幂等性 = Exactly 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 只会持久化一条。

• zookeeper可以用来做什么？介绍一下它的watch机制
• 处理过哪些线上故障
• 垃圾回收器中CMS与G1的区别

---

1. Dubbo-go应用维度注册模型 ↩︎

2. 阿里技术专家详解 Dubbo 实践，演进及未来规划 ↩︎

3. 微服务：注册中心ZooKeeper、Eureka、Consul 、Nacos对比 ↩︎

4. Eureka 集群是怎么保持数据一致的？ ↩︎

5. 《专题四 服务化改造》之《第三章 【补充资料】常见消息中间件应用详解》之《第十节 Kafka》 ↩︎

6. Kafka+SparkStreaming的精准一次性消费 中的《1、Kafka的精准一次性》 ↩︎