主流数据库对比

数据类型

::: info 扩展阅读

• Elasticsearch 数据类型
• MongoDB 数据类型

:::

CRUD

::: info 扩展阅读

• MongoDB 官方文档之 CRUD 操作
• Elasticsearch 官方文档之快速入门
• Elasticsearch 从入门到实践之文档的基础操作

:::

聚合

::: info 扩展阅读

• Elasticsearch 官方文档之聚合
• Elasticsearch 从入门到实践之聚合

:::

综合对比

Elasticsearch 提供了极其丰富的聚合能力。

MongoDB 提供了丰富的聚合能力。

Elasticsearch 聚合

在 ES 中，不仅仅是普通搜索，相关性计算（评分）和聚合计算也是先在每个 shard 的本地进行计算，再由 coordinate node 进行汇总。由于分片的本地计算是独立的，只能基于数据子集来进行计算，所以难免出现数据偏差。

要解决聚合准确性问题，有两个解决方案：

• 解决方案 1：当数据量不大的情况下，设置主分片数为 1，这意味着在数据全集上进行聚合。但这种方案不太现实。
• 解决方案 2：设置 shard_size 参数，将计算数据范围变大，牺牲整体性能，提高精准度。shard_size 的默认值是 size * 1.5 + 10。

Elasticsearch 将聚合分为三类：

• Metric（指标聚合）：根据字段值进行统计计算
  • max、min、avg、sum、stats
  • rate
  • cardinality
  • …
• Bucket（桶聚合）：根据字段值、范围或其他条件进行分组
  • filter、filters
  • terms、multi_terms、range
  • composite
  • nested
  • …
• Pipeline（管道聚合）：对其他聚合输出的结果进行再次聚合
  • max_bucket、min_bucket、avg_bucket、sum_bucket、stats_bucket
  • bucket_correlation、bucket_sort
  • normalize

MongoDB 聚合

MongoDB 使用 db.collection.aggregate() 方法分 阶段 进行聚合计算。

存储

逻辑存储

物理存储

MongoDB：MongoDB 的物理存储机制和 MySQL 较为相近。

• 文件级存储： 一个 MongoDB 实例可以包含多个数据库，每个数据库对应一组 .wt 文件，集合和索引分散在这些文件中。
  • collection-*.wt： 存储集合数据的文件。
  • index-*.wt： 存储索引数据的文件。
  • WiredTiger.wt： 一个元数据文件，跟踪所有其他文件。
  • WiredTiger.lock： 锁文件，标识该数据目录正在被使用。
  • journal/： 预写事务日志目录。
• 内存优先： 几乎所有操作都在解压后的缓存中进行，延迟写入磁盘。
  • 工作方式： 它缓存的是解压后的数据和索引的页（Page）。查询首先在缓存中查找，如果找不到（cache miss），才会从磁盘读取对应的页，解压后加载到缓存中。
  • 页面淘汰： 使用 LRU (Least Recently Used) 算法淘汰最久未使用的页。
• 磁盘管理
  • **记录 (Record)**： 对应一个 BSON 文档及其头部信息。
  • **页 (Page)**： 磁盘 IO 的基本单位。一个页包含多个记录（文档）或索引项。
  • **区域 (Extent)**： 一组连续的页，分配给特定的集合或索引。
    • 当集合需要更多空间时，WiredTiger 会分配一个新的 Extent 给它。
    • 这种预分配策略有助于减少碎片和提高写入性能。
• 持久化
  • oplog：服务层的逻辑日志，类似 MySQL 服务层的 binlog，用于主从同步，恢复数据。
  • Journal：WiredTiger 存储引擎的物理日志，类似 InnoDB 的 Redo Log，都是预写日志（Write-Ahead Log, WAL）的实现。
  • Checkpoint：MySQL 和 MongoDB 都会定期将内存中的修改批量、一致地写入磁盘文件，减少随机 IO。需要故障恢复时，也都是基于最后一个 Checkpoint，逐一重放操作，以恢复数据。

索引

事务

复制

架构对比

相同点

1. 核心目标一致：三者都为实现高可用（HA） 和灾难恢复（DR） 而设计，防止单点故障导致服务中断。
2. 数据冗余：都是通过将数据复制到多个节点来实现数据冗余。
3. 读写分离：都支持将读请求分发到副本节点，从而提升系统的整体读吞吐量。
4. 异步复制为基：默认的复制方式都是异步的，以优先保证主节点的写入性能。
5. 日志驱动：依赖于一种预写日志（WAL） 的变体来驱动复制：
   • MySQL → Binlog 和 Redo Log（InnoDB 引擎）
   • Elasticsearch → Translog
   • MongoDB → Oplog 和 Journal（WiredTiger 引擎）
6. 提供一致性配置： 三者都提供了配置参数，允许用户在性能和一致性之间进行权衡。

不同点

小结

如何选择：

• 如果应用核心是「交易」和「强一致性」：选择 MySQL。它的复制机制为数据安全性和一致性提供了最坚实的基础。
• 如果应用核心是「搜索」和「大数据分析」：选择 Elasticsearch。它的分布式对等架构为海量数据的查询和分析提供了无与伦比的性能和扩展性。
• 如果应用需要「灵活的数据模型」、「快速迭代」和「水平扩展」，同时需要一定的一致性控制：选择 MongoDB。它在扩展性、一致性和易用性之间取得了最佳平衡。

分区

核心概念对比

相同点

1. 核心目标一致： 三者都为了突破单机硬件（CPU、内存、磁盘）的限制，通过将数据分散到多个节点来实现水平扩展。
2. 基于键值分区： 都要求选择一个或多个字段的值作为依据（分片键/分区键/路由键），通过这个值的哈希或范围来决定数据的具体位置。
3. 面临类似挑战： 都需要解决跨分片查询、数据分布均衡性、事务支持（难度高）和集群管理的复杂性。

不同点

小结

如何选择：

1. 如果主要需求是「搜索」和「分析」：选择 Elasticsearch。它的分区和分布式查询是业界的黄金标准，完全无需你操心数据如何分布和查询如何执行。
2. 如果需要一个「可水平扩展的通用数据库」，用于现代应用：选择 MongoDB。它的分片集群是内置的，提供了良好的扩展性和灵活性，同时还能支持跨分片事务，适合各种 Web 和移动应用。
3. 如果数据量很大但主要是「单机操作」，或需要「严格的单机事务」：选择 MySQL。可以使用其分区功能来管理大表，但不要指望它原生能提供分布式数据库的能力。真正的分片需要引入复杂的中间件，这通常是最后的选择。

故障恢复

核心机制对比

相同点

1. 基于心跳检测： 都依赖于节点间定期发送心跳包来检测对方是否存活。
2. 自动选主： 在主节点故障时，都具备自动选举新主节点的能力，无需人工干预。
3. 多数派原则： 都遵循“多数派”（Quorum）原则来避免脑裂（Split-Brain）。即集群必须拥有超过半数的投票节点在线才能正常进行主节点选举和数据写入，否则整个集群会进入只读或不可用状态以保护数据。

不同点

小结

如何选择：

1. 如果业务要求是「数据绝对不能错」，宁可停止服务也要保证一致性：选择 MySQL。它的强一致性模型和基于共识的故障恢复机制为此而生。
2. 如果业务要求是「服务绝对不能停」，可以接受秒级的数据延迟：选择 Elasticsearch。它的分布式设计和快速恢复能力能最大程度保证服务的可用性和连续性。非常适合可观测性场景。
3. 如果需要一个「兼顾可用性与一致性」的通用数据库，希望故障恢复快速且对业务透明：选择 MongoDB。它在两者之间取得了最佳实践，故障转移速度快，并且通过读写关注给了开发者灵活选择的权利，适合大多数互联网应用。

Dubbo 面试之应用

简介

【简单】Dubbo 是什么？为什么使用 Dubbo？

Dubbo 是一款高性能、轻量级的开源 Java RPC 框架。

Dubbo 提供了三大核心能力：

• 面向接口的远程过程调用（RPC）：提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
• 智能容错和负载均衡：内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。
• 服务自动注册和发现：支持多种注册中心服务，服务实例上下线实时感知。

【简单】Dubbo3 有什么新特性？

Dubbo3 的核心新特性：

• 新通信协议 - Triple - Triple 协议是 Dubbo3 设计的基于 HTTP 的 RPC 通信协议规范。它完全兼容 gRPC 协议，支持 Request-Response、Streaming 流式等通信模型，可同时运行在 HTTP/1 和 HTTP/2 之上。
• 应用级服务发现
  • 接口级服务发现，以接口为粒度将信息注册到注册中心。举例来说，如果有 10 个 RPC Provider，部署在 100 台机器实例上，就要注册 10 * 100 条数据。
  • 应用级服务发现，以应用为粒度将信息注册到注册中心。将信息进行了拆分：接口元数据信息、接口和应用的映射关系维护在元数据中心；应用信息维护在注册中心。这样的好处是，存储的数据量大大减少，则传输数据的 I/O 开销也随之显著减少。
• Dubbo Mesh - 让 Dubbo 应用能够无缝接入 Istio 等业界主流服务网格产品。

扩展：技术创想 66 | Dubbo3.0 应用级服务注册原理

【简单】Dubbo 的配置方式有哪些？

Dubbo 支持多种配置方式，适用于不同开发场景：

XML 配置

• 适用场景：传统 Spring 项目，配置直观但较冗长。

• 示例：

  1 2 3 4

  <dubbo:application name="demo-provider"/> <dubbo:registry address="zookeeper://127.0.0.1:2181"/> <dubbo:protocol name="dubbo" port="20880"/> <dubbo:service interface="com.example.DemoService" ref="demoService"/>

Properties 配置

• 适用场景：简单项目，配置项较少时使用。

• 示例（application.properties）：

  1 2 3 4

  dubbo.application.name=demo-provider dubbo.registry.address=zookeeper://127.0.0.1:2181 dubbo.protocol.name=dubbo dubbo.protocol.port=20880

Spring 注解配置

• 适用场景：Spring Boot/Cloud 项目，简化 XML 配置。

• 核心注解：

  • @Service（暴露服务）
  • @Reference（引用服务）

• 示例：

  1 2 3 4 5

  @Service // Dubbo 服务提供者 public class DemoServiceImpl implements DemoService { ... } @Reference // Dubbo 服务消费者 private DemoService demoService;

API 编程配置

• 适用场景：动态配置、框架集成等需要灵活控制的场景。

• 示例：

  1 2 3 4 5 6 7 8

  ApplicationConfig app = new ApplicationConfig("demo-provider"); RegistryConfig registry = new RegistryConfig("zookeeper://127.0.0.1:2181"); ProtocolConfig protocol = new ProtocolConfig("dubbo", 20880); ServiceConfig<DemoService> service = new ServiceConfig<>(); service.setInterface(DemoService.class); service.setRef(new DemoServiceImpl()); service.export(); // 暴露服务

应用

【中等】Dubbo 中如何实现服务端与客户端的版本兼容？

版本和分组

Dubbo 服务中，接口并不能唯一确定一个服务，只有 接口+分组+版本号 的三元组才能唯一确定一个服务。

• 当同一个接口针对不同的业务场景、不同的使用需求或者不同的功能模块等场景，可使用服务分组来区分不同的实现方式。同时，这些不同实现所提供的服务是可并存的，也支持互相调用。
• 当接口实现需要升级又要保留原有实现的情况下，即出现不兼容升级时，我们可以使用不同版本号进行区分。

下面以官方示例来解释一下如何指定版本。

假设，接口定义如下：

1
2
3

public interface DevelopService {
    String invoke(String param);
}

版本 1 实现：

1
2
3
4
5
6
7
8
9

@DubboService(group = "group1", version = "1.0")
public class DevelopProviderServiceV1 implements DevelopService{
    @Override
    public String invoke(String param) {
        StringBuilder s = new StringBuilder();
        s.append("ServiceV1 param:").append(param);
        return s.toString();
    }
}

版本 2 实现：

1
2
3
4
5
6
7
8
9

@DubboService(group = "group2", version = "2.0")
public class DevelopProviderServiceV2 implements DevelopService{
    @Override
    public String invoke(String param) {
        StringBuilder s = new StringBuilder();
        s.append("ServiceV2 param:").append(param);
        return s.toString();
    }
}

跨版本升级

可以按照以下的步骤进行版本迁移：

1. 在低压力时间段，先部署部分 Provider 新版本
2. 再将所有 Consumer 升级为新版本
3. 然后将剩下的一半提供者升级为新版本

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

参考用例 https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-version

服务提供者

老版本服务提供者配置：

1

<dubbo:service interface="com.foo.BarService" version="1.0.0" />

新版本服务提供者配置：

1

<dubbo:service interface="com.foo.BarService" version="2.0.0" />

服务消费者

老版本服务消费者配置：

1

<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />

新版本服务消费者配置：

1

<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />

不区分版本

如果不需要区分版本，可以按照以下的方式配置：

1

<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

通过以上描述，可以看到，通过版本号来进行 Dubbo 接口升级实际上较为麻烦。如果接口提供方和消费方分属不同的业务团队，同步发版就更加麻烦了。因此，在实际应用中，更常见的操作是应该尽量充分考虑接口的后向兼容性，确保不会影响旧版本的调用。需要考虑的点如下：

• 如果方法签名无任何变化，不会影响旧版本的调用。服务提供方可以直接先全量上线。
• 如果入参、出参上新增属性，不会影响旧版本的调用（当然，对于新增属性的逻辑处理要充分考虑兼容性）。服务提供方可以直接先全量上线，消费方根据需要选择是否后续安排对接。
• 如果入参、出参上删除或修改属性，会影响旧版本调用，可以新增接口。

扩展阅读：Dubbo 官方文档之版本与分组

【中等】Dubbo 中的分组（Group）是如何使用的？

核心作用

Dubbo 分组通过轻量级的逻辑隔离，在不增加物理部署成本的情况下实现服务治理能力。

• 服务隔离：逻辑划分不同服务实例
• 流量控制：实现定向路由和灰度发布

基础配置

1
2
3
4
5

<!-- 服务提供方 -->
<dubbo:service interface="com.example.DemoService" group="group1"/>

<!-- 服务消费方 -->
<dubbo:reference interface="com.example.DemoService" group="group1"/>

典型应用场景

高级配置方式

• 全局默认分组

  1 2	<dubbo:provider group="default-group"/> <dubbo:consumer group="default-group"/>

• 动态分组（通过 RPC 上下文）

  1	RpcContext.getContext().setAttachment("group", "dynamic-group");

最佳实践

• 分组命名采用「业务_环境_版本」规范（如：payment_prod_v2）
• 配合标签路由实现更精细的流量控制
• 生产环境建议开启分组校验：

  1	dubbo.provider.group-validation=true

【中等】Dubbo 中如何配置多协议、多注册中心？

有时服务会面对不同用户，支持多协议可以提高服务的兼容性和灵活性。

1
2
3
4
5
6
7

<!-- 声明两种协议 -->
<dubbo:protocol name="dubbo" port="20880"/>
<dubbo:protocol name="rest" port="8080"/>

<!-- 为不同服务指定协议 -->
<dubbo:service interface="com.example.UserService" protocol="dubbo"/>
<dubbo:service interface="com.example.ApiService" protocol="rest"/>

【中等】Dubbo 中如何配置多注册中心？

多注册中心可以提高服务的可用性以及容灾能力，任一中心宕机不影响服务注册和发现。

1
2
3
4
5
6

<!-- 声明两个注册中心 -->
<dubbo:registry id="zookeeper1" address="zookeeper://192.168.1.1:2181"/>
<dubbo:registry id="zookeeper2" address="zookeeper://192.168.1.2:2181"/>

<!-- 服务同时注册到两个中心 -->
<dubbo:service interface="com.example.OrderService" registry="zookeeper1,zookeeper2"/>

要点：

• 注册中心 ID 需唯一，用逗号分隔可指定多个
• 消费端无需特殊配置，自动发现所有注册中心的服务

故障排查

【中等】Dubbo 的超时问题如何排查与调优？

核心排查步骤

1. 明确超时位置

   • 区分是消费端超时（TimeoutException）还是服务端处理超时
   • 检查报错日志中的side标识（consumer/provider）

2. 关键配置检查

   1 2 3 4 5 6 7

   # 服务端配置 dubbo.provider.timeout=3000 # 默认服务超时时间 dubbo.provider.executes=200 # 最大并发执行数 # 消费端配置 dubbo.consumer.timeout=1000 # 调用超时时间（优先级更高） dubbo.reference.timeout=2000 # 方法级超时配置

3. 监控指标分析

   • 观察RT（响应时间）分布：P90/P99 是否接近超时阈值
   • 检查TPS与线程池活跃度：是否达到executes限制

常见问题场景

调优方案

1. 分层超时设置

   1 2 3 4

   <!-- 基础服务设置长超时 --> <dubbo:reference interface="BaseService" timeout="5000"/> <!-- 聚合服务设置短超时 --> <dubbo:reference interface="AggregateService" timeout="1000"/>

2. 动态调整策略

   1 2	// 通过 RpcContext 动态设置 RpcContext.getContext().set("timeout", 2000);

3. 线程池优化

   1 2 3 4 5

   dubbo: provider: threads: 200 # IO 线程数 threadpool: cached # 弹性线程池 queues: 0 # 不堆积请求

1
2
3
4
5
6
7
8

4. **熔断降级配合**

   ```xml
   <!-- 结合 Sentinel 实现自动熔断 -->
   <dubbo:reference>
     <dubbo:method name="query" sentinel="true"/>
   </dubbo:reference>

高级排查工具

（1）Arthas 诊断

1
2

# 监控方法执行时间
watch com.example.ServiceImpl * '{params,returnObj}' -x 3 -n 5 -b

（2）全链路追踪

1
2
3
4
5
6
7
8

// 在 Filter 中记录关键节点耗时
long start = System.currentTimeMillis();
try {
    return invoker.invoke(inv);
} finally {
    log.info("Method {} cost {}ms", inv.getMethodName(),
            System.currentTimeMillis() - start);
}

最佳实践建议

1. 超时公式参考

   1	理想超时时间 = 平均 RT × 3 + 安全余量 (200~500ms)

2. 配置优先级原则

   1 2	方法级 > 接口级 > 全局配置 消费端配置 > 服务端配置

3. 生产环境推荐

   • 所有服务显式声明超时时间
   • 核心服务设置timeout="3000" retries="0"
   • 非核心服务设置timeout="1000" retries="1"

注：超时时间不是越长越好，需要平衡用户体验和系统资源占用。建议通过压测确定合理阈值。

【中等】如何在 Dubbo 中优化网络通信性能？

核心优化措施

1. 序列化优化

   • 优先选用Kryo（高性能）或Protobuf（跨语言）
   • 避免使用 Java 原生序列化

   1	<dubbo:protocol serialization="kryo"/>

2. 连接管理

   • 强制启用长连接复用

   1 2 3 4 5

   dubbo: protocol: keepalive: true consumer: connections: 10 # 每个服务维持的连接数

3. 网络参数调优

   1 2 3 4

   # Netty 参数优化 io.netty.allocator.type=pooled io.netty.noPreferDirect=true dubbo.protocol.payload=8388608 # 8MB 最大包

进阶优化手段

关键配置示例

1. 服务提供方配置

   1 2 3 4 5 6 7 8

   @Bean public ProtocolConfig protocolConfig() { ProtocolConfig config = new ProtocolConfig(); config.setThreads(200); // IO 线程数 config.setBufferSize(16384); // 16KB 缓冲区 config.setAccepts(1000); // 最大连接数 return config; }

1
2
3
4
5
6

2. **消费方超时控制**
   ```xml
   <dubbo:reference timeout="1000">
     <dubbo:method name="query" timeout="500"/>
   </dubbo:reference>

性能验证指标

1. 关键监控点

   • 网络吞吐量：netstat -s | grep segments
   • 线程池状态：DubboPREFIX.thread.pool.active.count
   • 序列化耗时：DubboPREFIX.serialize.time

2. 压测建议

   1 2	# 模拟不同数据包大小 (1K/10K/1M) jmeter -n -t dubbo_perf.jmx -l result.csv

最佳实践：建议先进行基准测试（1K/10K/100K 数据包），逐步调整参数。典型优化效果：

• 小包场景：TPS 提升 30%-50%
• 大包场景：吞吐量提升 2-3 倍
• 延迟敏感场景：P99 降低 20%-40%

【中等】如何调试 Dubbo 的服务调用失败问题？

快速定位步骤

1. 错误类型识别

   • TimeoutException：调用超时（网络/服务端阻塞）
   • RpcException：RPC 协议错误（序列化/版本不匹配）
   • NoProviderException：服务未注册/下线

2. 关键日志检查

   1 2	# 查看 Dubbo 错误日志（通常包含错误根源） grep -E "Exception|ERROR" dubbo.log

常见问题诊断表

深度排查工具

（1）Arthas 诊断

1
2
3
4
5

# 检查服务提供者状态
watch com.xxx.ServiceImpl * '{params,returnObj,throwExp}' -x 3

# 跟踪调用链路
trace com.alibaba.dubbo.rpc.filter.ExceptionFilter

（2）网络分析

1
2
3
4
5

# 检查网络连通性
tcpping providerIP 20880

# 抓包分析（需 sudo 权限）
tcpdump -i eth0 port 20880 -w dubbo.pcap

（3）注册中心检查

1
2

# Zookeeper 服务列表查询
ls /dubbo/com.xxx.Service/providers

典型解决方案

（1）服务不可用场景

1
2

<!-- 增加重试机制 -->
<dubbo:reference retries="2" cluster="failfast"/>

（2）性能瓶颈场景

1
2
3
4
5
6

dubbo:
  provider:
    threads: 500 # 扩大线程池
    accepts: 1000 # 增加连接数
  protocol:
    payload: 52428800 # 增大传输包限制 (50MB)

（3）版本冲突场景

1
2

<!-- 明确指定版本 -->
<dubbo:reference version="1.2.0"/>

预防建议

（1）监控配置

1
2
3

# 开启 Dubbo QoS 在线诊断
dubbo.application.qos.enable=true
dubbo.application.qos.port=22222

（2）日志增强

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@Activate
public class ErrorLogFilter implements Filter {
    @Override
    public Result invoke(Invoker<?> invoker, Invocation inv) {
        try {
            return invoker.invoke(inv);
        } catch (Exception e) {
            log.error("RPC 失败：{}.{}, 参数：{}",
                invoker.getInterface(),
                inv.getMethodName(),
                Arrays.toString(inv.getArguments()));
            throw e;
        }
    }
}

注：建议结合 APM 工具（SkyWalking/Pinpoint）建立全链路监控，80%的调用失败问题可通过监控指标提前预警。

【中等】Dubbo 的序列化异常如何解决？

核心解决步骤

1. 依赖检查：确保序列化库（如 Kryo/FastJson）版本一致，排除冲突。

2. 序列化合规性：

   • 所有传输类需实现Serializable接口

• 非序列化字段用transient标记

3. 版本与配置统一：服务端/客户端使用相同序列化协议（如 Hessian2）

   1	<dubbo:protocol serialization="kryo"/>

4. 日志分析：通过错误日志定位具体异常类（如NotSerializableException）

高阶优化方案

• 自定义序列化器：实现ObjectInput/ObjectOutput接口处理特殊对象

• 性能选型

  协议	性能	稳定性	适用场景
  Kryo	★★★	★★	高性能内部调用
  Hessian2	★★	★★★	跨语言兼容场景

• 调试技巧

  • 显式定义serialVersionUID防版本冲突
  • 抓包对比序列化前后数据一致性

典型报错处理

1
2
3
4
5

// 示例：字段缺失 Serializable 导致的异常
public class User implements Serializable {
    private transient Address addr; // 避免序列化
    private static final long serialVersionUID = 1L; // 显式声明 UID
}

注：生产环境推荐 Hessian2 作为默认协议平衡稳定性与性能，关键服务建议压测验证序列化性能。

【中等】Dubbo 的服务无法发现，可能的原因有哪些？

按注册中心→提供者→消费者→网络→版本顺序排查，结合日志与工具快速定位问题。多数情况由配置不一致或网络隔离导致。

核心排查方向

高频问题解决方案

• 注册中心连接失败

  1 2	<!-- 检查配置示例 --> <dubbo:registry address="zookeeper://192.168.1.100:2181" timeout="3000"/>

  确保：

  • 地址协议前缀正确（如zookeeper://或nacos://）
  • 超时时间足够（默认 1000ms 可能太短）

• 服务未注册成功

  1 2	@Service(version = "1.0.0", group = "order") // 提供者注解 @Reference(version = "1.0.0", group = "order") // 消费者注解

  确保：

  • 版本号（version）和分组（group）完全匹配
  • 接口包路径一致（避免 IDE 自动导入错误包）

• 消费者缓存脏数据

  1 2 3

  # 清理 Dubbo 本地缓存 rm -rf ~/.dubbo/ # Linux/Mac del /s /q %USERPROFILE%\.dubbo # Windows

进阶诊断工具

• 开启 Dubbo 调试日志

  1 2	# application.properties logging.level.org.apache.dubbo=DEBUG

  • 观察服务注册/订阅日志
  • 检查Invoker转换异常

• 使用 Telnet 直连调试

  1 2 3

  telnet 服务提供者 IP 20880 > ls -l # 列出所有服务 > invoke 接口名。方法名（参数） # 手动测试调用

• 注册中心控制台

  • Zookeeper：zkCli.sh查看/dubbo/接口名/providers节点
  • Nacos：控制台检查服务列表是否可见

预防建议

• 标准化配置：使用 Maven 属性管理版本号，避免手动配置不一致

  1 2 3

  <properties> <dubbo.version>2.7.15</dubbo.version> </properties>

• 健康检查：集成 Spring Boot Actuator 监控 Dubbo 服务状态
• 灰度发布：通过group区分环境（如group="prod"/group="test"）

【中等】Dubbo 的服务上线后无法调用，可能的原因有哪些？

网络问题

检查方法：

• ping 测试网络连通性。
• telnet/nc 检查端口是否开放（如 Dubbo 默认端口 20880）。
• traceroute 分析网络路径是否异常。

服务注册失败

排查步骤：

• 确认注册中心（如 Zookeeper）是否正常运行，使用 zkCli.sh 查看节点。
• 检查 <dubbo:registry address="..."> 配置是否正确。
• 查看服务提供者日志，确认是否报注册失败错误。

服务依赖问题

关键点：

• 确保 Maven 依赖无冲突（特别是 Dubbo 版本）。
• 关注日志中的 ClassNotFoundException 或 NoClassDefFoundError。

消费者配置错误

常见错误：

• 版本号不一致：<dubbo:reference version="..."> 需与提供者匹配。
• 分组不一致：检查 group 配置是否一致。

防火墙拦截

解决方案：

• 开放 Dubbo 服务端口（如 20880）。
• 检查云服务器安全组或本地防火墙规则（如 iptables）。

代码/配置错误

重点检查：

• XML 配置：<dubbo:service>、<dubbo:reference> 等标签参数是否正确。
• 注解配置：@Service、@Reference 是否被 Spring 扫描到。

扩展工具与技巧

• 注册中心调试：通过 Zookeeper 命令（ls /dubbo/服务名）查看注册情况。
• Dubbo Admin：使用控制台查看服务状态和调用关系。
• 日志分析：开启 Dubbo 调试日志（logger.org.apache.dubbo=DEBUG）定位问题。

参考资料

• Dubbo Github
• Dubbo 官方文档
• Dubbo 框架设计
• 如何基于 Dubbo 进行服务治理、服务降级、失败重试以及超时重试？

Dubbo 面试之服务治理

服务注册和发现

【中等】什么是服务注册与发现？Dubbo 如何实现？

::: info 什么是服务注册与发现？
:::

服务注册与发现是微服务的核心基础设施，通过解耦服务地址硬编码，实现动态扩缩容和故障自动恢复。

• 服务注册（Registration）：服务提供者（Provider）启动时，将自己的 IP、端口、接口名 等信息上报到注册中心（如 Zookeeper/Nacos）。举例：订单服务启动后，向注册中心注册："order-service: 192.168.1.100:8080"。
• 服务发现（Discovery）：服务消费者（Consumer）从注册中心 拉取可用服务列表，并基于负载均衡策略选择目标实例。举例：支付服务需要调用订单服务时，从注册中心获取所有可用的order-service节点列表。

注册阶段

1
2

graph LR
Provider-->|1. 注册地址|Registry(Zookeeper/Nacos)

发现阶段

1
2
3

graph LR
Consumer-->|2. 拉取服务列表|Registry
Consumer-->|3. 调用目标 Provider|Provider

::: info 有哪些常见的注册中心？
:::

主流注册中心对比

Dubbo 中可以通过 registry 配置来指定注册中心。

1
2
3
4
5

<!-- 服务提供者注册 -->
<dubbo:service interface="com.example.OrderService" ref="orderService" registry="zookeeper://127.0.0.1:2181"/>

<!-- 服务消费者发现 -->
<dubbo:reference id="orderService" interface="com.example.OrderService" registry="zookeeper://127.0.0.1:2181"/>

【简单】Dubbo 支持哪些注册中心？

不同于传统的 Dubbo2，Dubbo3 中定义了三种中心：注册中心、配置中心、元数据中心。配置中心、元数据中心是实现 Dubbo 高阶服务治理能力会依赖的组件，如流量管控规则等，相比于注册中心通常这两个组件的配置是可选的。

配置方式如下：

1
2
3
4
5
6
7

dubbo
 registry
  address: nacos://localhost:8848
 config-center
  address: nacos://localhost:8848
 metadata-report
  address: nacos://localhost:8848

需要注意的是，对于部分注册中心类型（如 Zookeeper、Nacos 等），Dubbo 会默认同时将其用作元数据中心和配置中心（建议保持默认开启状态）。

Dubbo 目前支持的主流注册中心实现包括：

• Zookeeper
• Nacos
• Redis
• Consul
• Etcd
• 更多实现

同时也支持 Kubernetes、Mesh 体系的服务发现，具体请参考 使用教程 - kubernetes 部署

【简单】注册中心挂了可以继续通信吗？

可以。Dubbo 消费者在应用启动时会从注册中心拉取已注册的生产者的地址接口，并缓存在本地。每次调用时，按照本地存储的地址进行调用。

【中等】注册中心是选择 CP 还是 AP？

::: info 什么是 CAP？
:::

在分布式系统领域，有一个著名的 CAP 理论。CAP 定理提出：分布式系统有三个指标，这三个指标不能同时做到：

• 一致性（Consistency） - 在任何给定时间，网络中的所有节点都具有完全相同（最近）的值。
• 可用性（Availability） - 对网络的每个请求都会返回响应，但不能保证返回的数据是最新的。
• 分区容错性（Partition Tolerance） - 即使任意数量的节点出现故障，网络仍会继续运行。

CAP 就是取 Consistency、Availability、Partition Tolerance 的首字母而命名。

在分布式系统中，分区容错性是一个既定的事实：因为分布式系统总会出现各种各样的问题，如由于网络原因而导致节点失联；发生机器故障；机器重启或升级等等。因此，CAP 定理实际上是要在可用性（A）和一致性（C）之间做权衡。

::: info 注册中心选 AP 还是 CP？
:::

注册中心作为服务提供者和服务消费者之间沟通的桥梁，它的重要性不言而喻。所以注册中心一般都是采用集群部署来保证高可用性，并通过分布式一致性协议来确保集群中不同节点之间的数据保持一致。

根据 CAP 理论，三种特性无法同时达成，必须在可用性和一致性之间做取舍。于是，根据不同侧重点，注册中心可以分为 CP 和 AP 两个阵营：

• CP 型注册中心 - 牺牲可用性来换取数据强一致性，最典型的例子就是 ZooKeeper，etcd，Consul 了。ZooKeeper 集群内只有一个 Leader，而且在 Leader 无法使用的时候通过算法选举出一个新的 Leader。这个 Leader 的目的就是保证写信息的时候只向这个 Leader 写入，Leader 会同步信息到 Followers，这个过程就可以保证数据的强一致性。但如果多个 ZooKeeper 之间网络出现问题，造成出现多个 Leader，发生脑裂的话，注册中心就不可用了。而 etcd 和 Consul 集群内都是通过 Raft 协议来保证强一致性，如果出现脑裂的话， 注册中心也不可用。
• AP 型注册中心 - 牺牲一致性（只保证最终一致性）来换取可用性，最典型的例子就是 Eureka 了。Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。
• CP & AP 都支持型注册中心 - Nacos 的内在设计偏向于 CP，即在发生网络分区的情况下优先保证数据的一致性和分区容错性，牺牲一定的可用性。虽然 Nacos 的内在设计偏向于 CP，但通过合理的配置与实践，可以在一定程度上优化其可用性。例如：调整副本数、配置同步策略。更多详情可以参考：Nacos CAP

选择 CP 还是 AP，根据实际需要来定：如果业务场景要求强一致，优先选择 CP 型注册中心；如果业务场景强调可用性，优先选择 AP 型注册中心。

::: info 注册中心选型对比

:::

【中等】Dubbo 的服务自动上线与下线机制是怎样的？

::: info 服务自动上线流程

:::

• 启动注册：
• 服务提供者启动时，解析配置文件（如 dubbo:service 或注解 @Service），获取服务接口、方法、版本、分组等信息。
  • 将服务元数据（如 IP、端口、接口名）注册到注册中心（如 Zookeeper/Nacos）。
  • 注册中心存储服务信息，形成服务目录（如 Zookeeper 的 /dubbo/{service}/providers 节点）。
• 消费者发现：
  • 消费者启动时，从注册中心拉取服务提供者列表，并建立长连接。
  • 注册中心推送变更通知（如新服务上线），消费者动态更新本地服务列表。

::: info 服务自动下线流程

:::

• 主动下线：
• 服务提供者正常关闭时，触发 Shutdown Hook，向注册中心发送注销请求。
  • 注册中心删除对应节点，消费者通过事件监听感知服务下线。
• 被动下线：
  • 心跳检测：若提供者宕机，注册中心未收到心跳（如 Zookeeper 的 Session 超时），自动剔除故障节点。
  • 消费者容错：已连接的消费者通过故障处理机制（如 Failover）切换至其他可用节点。

::: info 关键保障机制

:::

• 心跳保活：默认心跳间隔 60 秒（可调），超时时间建议 3 倍心跳间隔。
• 重试容错：消费者支持 retries 配置（如 Failover 策略），避免单点故障。
• 优雅停机：通过 ProtocolConfig.destroy() 确保注销完成后再终止 JVM。

::: info 高级治理能力

:::

• 版本灰度：通过 version 字段实现多版本共存，逐步下线旧版本。
• 权重调整：动态修改服务权重（如 Nacos 控制台），实现平滑流量迁移。
• 无损下线：结合 QOS 命令（offline）或 PreStop Hook，确保流量完全迁移后再下线。

::: info 常见问题排查

:::

• 服务未注册：

  • 检查注册中心地址、网络连通性。
  • 查看提供者日志是否有 RegistryFailedException。

• 僵尸节点：

  • 手动清理注册中心残留节点（如 Zookeeper 的 delete /dubbo/{service}/providers/xxx）。
  • 调整心跳超时时间，避免因网络抖动误判。

• 消费者未感知下线：

  • 确认注册中心支持事件推送（如 Nacos 的 notify 机制）。
  • 检查消费者是否配置了 check=false（禁用启动时强依赖检查）。

::: info 最佳实践

:::

• 生产环境建议：
  • 使用 Nacos 作为注册中心，兼顾可用性和动态配置能力。
  • 开启 Dubbo Admin 监控，实时查看服务状态。
• 停机操作：先通过 telnet 127.0.0.1 20880 执行 invoke offline() 命令，再重启服务。
• 版本迭代：采用 version="1.0.0" 和 group="canary" 分批次上线，降低风险。

【困难】Dubbo3 的应用级服务发现的工作原理是什么？

【应用级服务发现】是 Dubbo3 引入的新特性，旨在解决大规模微服务架构下 注册中心压力大 和 服务治理效率低 的问题。其核心思想是 以应用为维度注册实例，而非传统接口级注册。

应用级注册通过 注册与元数据分离，将注册中心的数据量降低至常数级，显著提升了大规模微服务架构的可扩展性。其核心创新在于：

• 注册中心只存应用实例，元数据独立存储；
• 消费者按需加载接口信息，减少网络开销；
• 完美兼容旧模式，支持渐进式迁移。

与传统接口级注册的对比

::: info 接口级服务发现工作原理

:::

Dubbo3 以前的版本采用的是接口级服务发现。

Provider 部署的应用中通常会有多个 Service，每个 service 都可能会有其独有的配置。Service 服务发布的过程，其实就是基于这个服务配置生成地址 URL 的过程，生成的地址数据如图所示。

注册中心的地址数据存储结构，以 Service 服务名为数据划分依据，将一个服务下的所有地址数据都作为子节点进行聚合，子节点的内容就是实际可访问的 ip 地址，也就是我们 Dubbo 中 URL，格式就是刚才 Provider 实例生成的。

这里把 URL 地址数据划分成了几份：

• 实例可访问地址：主要信息包含 ip 和 port，消费端将基于这条数据生成 tcp 网络链接，作为后续 RPC 数据的传输载体。
• RPC 元数据：元数据用于定义和描述一次 RPC 请求。它可以分为两类：
  • 具体的 RPC 服务信息：如版本号、分组以及方法相关信息；
  • RPC 配置数据：控制 RPC 调用的行为，同步 Provider 进程实例的状态（如超时时间、数据编码的序列化方式等）。
• 自定义元数据：用户可任意扩展并添加自定义元数据。

综上，有以下结论：

1. 服务发现聚合的 key 就是 RPC 粒度的服务
2. 注册中心同步的数据不止包含地址，还包含了各种元数据以及配置
3. 得益于 1 与 2，Dubbo 实现了支持应用、RPC 服务、方法粒度的服务治理能力

这就是一直以来 Dubbo2 在易用性、服务治理功能性、可扩展性上强于很多服务框架的真正原因。

接口级注册的易用性是有代价的，它限制了整体架构的扩展性，在大规模 Dubbo 集群中尤为凸显。其突出问题如下：

• 注册中心集群容量会成为瓶颈：由于所有的 URL 地址数据都被发送到注册中心，注册中心的存储容量达到上限，推送效率也随之下降。
• 消费端资源消耗较大：在消费端，Dubbo2 框架常驻内存已超 40%，每次地址推送带来的 cpu 等资源消耗率也非常高，影响正常的业务调用。

为什么会出现这个问题？举例来说，假设有一个普通的 Dubbo Provider 应用，该应用内部定义有 10 个 RPC Service，应用被部署在 100 个机器实例上。这个应用在集群中产生的数据量将会是 Service 数 * 机器实例数，也就是 10 * 100 = 1000 条数据。数据会从两个维度放大：

• 从地址角度。100 条唯一的实例地址，被放大 10 倍
• 从服务角度。10 条唯一的服务元数据，被放大 100 倍

::: info 应用级服务发现工作原理

:::

提供者服务注册

• 启动时，应用（如 user-service-app）将所有服务接口的 元数据（方法列表、协议等）上报至 元数据中心（如 Nacos）。
• 仅将 应用名+实例 IP+端口 注册到 注册中心（如 ZooKeeper），不包含接口信息。

消费者服务发现

• 订阅目标应用：
  • 消费者（如 order-service-app）从注册中心获取目标应用（如 user-service-app）的 实例列表（IP+端口）。
  • 不直接获取接口信息，避免注册中心数据膨胀。
• 按需拉取元数据：
  • 消费者首次调用前，从 元数据中心 拉取目标应用的接口元数据（如 UserService 的方法签名）。
  • 本地缓存元数据，后续调用直接使用。

调用过程

• 消费者通过 应用名+接口名 定位实例，发起 RPC 调用（协议兼容 Dubbo2）。
• 负载均衡在应用实例级别进行（如随机选择 user-service-app 的一个实例）。

关键设计优势

• 注册中心轻量化：实例数从 O（接口数×实例数） 降至 O（实例数），适合万级节点集群。
• 动态扩容高效：新增接口无需重复注册，只需更新元数据中心。
• 兼容性保障：支持与 Dubbo2 的接口级注册共存，平滑升级。

扩展：Dubbo3 应用级服务发现设计

负载均衡

【中等】Dubbo 支持哪些负载均衡方式？各有什么利弊？

Dubbo 提供了多种均衡策略，缺省为 weighted random 基于权重的随机负载均衡策略。

具体实现上，Dubbo 提供的是客户端负载均衡，即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。

目前 Dubbo 内置了如下负载均衡算法，可通过调整配置项启用。

Dubbo 的负载均衡配置可以细粒度到服务、方法级别，且 dubbo:service 和 dubbo:reference 均可配置。

1
2
3
4
5
6
7
8
9
10
11
12

<!-- 服务端服务级别 -->
<dubbo:service interface="..." loadbalance="roundrobin" />
<!-- 客户端服务级别 -->
<dubbo:reference interface="..." loadbalance="roundrobin" />
<!-- 服务端方法级别 -->
<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>
<!-- 客户端方法级别 -->
<dubbo:reference interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>

::: info Random（随机）

:::

• 加权随机，按权重设置随机概率。
• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
• 缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

::: info RoundRobin（轮询）

:::

• 加权轮询，按公约后的权重设置轮询比率，循环调用节点
• 缺点：同样存在慢的提供者累积请求的问题。

::: info LeastActive（最少活跃优先）

:::

• 加权最少活跃调用优先，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数 - 响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。
• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。

::: info ShortestResponse（最短响应优先）
:::

• 加权最短响应优先，在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。
• 使得响应时间越快的提供者，处理更多的请求。
• 缺点：可能会造成流量过于集中于高性能节点的问题。

这里的响应时间 = 某个提供者在窗口时间内的平均响应时间，窗口时间默认是 30s。

::: info ConsistentHash（一致性 Hash）
:::

• 一致性 Hash，相同参数的请求总是发到同一提供者。
• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
• 算法参见：Consistent Hashing | WIKIPEDIA
• 缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

::: info P2C
:::

Power of Two Choice 算法简单但是经典，主要思路如下：

1. 对于每次调用，从可用的 provider 列表中做两次随机选择，选出两个节点 providerA 和 providerB。
2. 比较 providerA 和 providerB 两个节点，选择其“当前正在处理的连接数”较小的那个节点。

以下是 Dubbo P2C 算法实现提案

::: info Adaptive（自适应）
:::

Adaptive 即自适应负载均衡，是一种能根据后端实例负载自动调整流量分布的算法实现，它总是尝试将请求转发到负载最小的节点。

以下是 Dubbo Adaptive 算法实现提案

扩展：

• Dubbo 官方文档之负载均衡
• 负载均衡

服务路由

【中等】Dubbo 如何进行服务路由控制？

路由规则

配置方案

条件路由强化

1
2
3
4

# 多条件组合路由（支持&&,||,! 运算符）
conditions:
  - 'method=createOrder && userLevel=VIP => 192.168.1.100'
  - 'headers.appVersion=3.2.* => region=hangzhou'

动态生效技巧：通过force:false实现软路由，当目标节点不可用时自动降级

标签路由进阶

1
2

// 编程式打标（配合配置中心）
RpcContext.getContext().setAttachment("traffic-tag", "experimental");

最佳实践：建立标签命名规范（如env=prod、version=2.0）

架构图

1
2
3
4
5

graph TB
    Admin[管理控制台] -->|推送规则| ConfigCenter[配置中心]
    ConfigCenter -->|实时同步| Provider[服务节点]
    Consumer -->|路由决策| RouterChain[路由链]
    RouterChain -->|过滤| LB[负载均衡]

动态管控

• 规则存储：建议使用 Nacos/Apollo 替代 Zookeeper，支持规则版本回溯
• 实时生效：消费者节点秒级感知（长连接推送）
• 兜底策略：本地缓存最后有效规则，避免配置中心不可用

生产级解决方案

场景：跨机房流量调度

1
2
3
4
5
6
7
8
9

# 基于地域标签的路由
tags:
  - name: 'region=shanghai'
    addresses: ['10.1.1.1-10.1.1.20']
  - name: 'region=beijing'
    addresses: ['10.2.1.1-10.2.1.20']
rules:
  - '=> region=shanghai' # 默认路由
  - 'headers.forceZone=beijing => region=beijing'

性能优化：

• 路由缓存：本地缓存路由决策结果（TTL 5s）
• 预计算：在服务目录更新时提前生成路由快照

异常处理机制

1
2
3
4
5
6
7
8

// 自定义路由失败处理器
public class CustomRouterFailover implements RouterListener {
    @Override
    public void onRouteFail(Invoker<?> invoker) {
        Metrics.counter("route_fail").increment();
        // 自动切换备用集群。..
    }
}

监控指标设计

与治理功能联动

• 负载均衡：路由结果作为 LB 的优先权重依据
• 限流：按路由维度设置独立限流规则
• 熔断：路由异常节点自动加入熔断黑名单

实施建议：

• 先通过<dubbo:parameter key="router" value="tag" />启用基础路由
• 使用 Arthas 的watch命令实时观察路由决策过程
• 在预发布环境进行规则压测（模拟 1000 次/秒规则变更）

【中等】Dubbo 路由是怎样工作的？

以下是 Dubbo 单个路由器的工作过程，路由器接收一个服务的实例地址集合作为输入，基于请求上下文 (Request Context) 和 (Router Rule) 实际的路由规则定义对输入地址进行匹配，所有匹配成功的实例组成一个地址子集，最终地址子集作为输出结果继续交给下一个路由器或者负载均衡组件处理。

通常，在 Dubbo 中，多个路由器组成一条路由链共同协作，前一个路由器的输出作为另一个路由器的输入，经过层层路由规则筛选后，最终生成有效的地址集合。

• Dubbo 中的每个服务都有一条完全独立的路由链，每个服务的路由链组成可能不通，处理的规则各异，各个服务间互不影响。
• 对单条路由链而言，即使每次输入的地址集合相同，根据每次请求上下文的不同，生成的地址子集结果也可能不同。

【中等】Dubbo 支持哪些路由方式？分别适用于什么场景？

Dubbo 的路由规则可以基于应用、服务、方法、参数等粒度精准的控制请求分发，根据请求的目标服务、方法以及请求体中的其他附加参数进行匹配，符合匹配条件的请求会进一步的按照特定规则转发到一个地址子集。

Dubbo 支持以下路由规则：

• 标签路由规则
• 条件路由规则
• 脚本路由规则
• 动态配置规则

::: info 标签路由规则

:::

标签路由通过将某一个服务的实例划分到不同的分组，约束具有特定标签的流量只能在指定分组中流转，不同分组为不同的流量场景服务，从而实现流量隔离的目的。标签路由可以作为蓝绿发布、灰度发布等场景能力的基础。

标签路由规则是一个非此即彼的流量隔离方案，也就是匹配标签的请求会 100% 转发到有相同标签的实例，没有匹配标签的请求会 100% 转发到其余未匹配的实例。如果您需要按比例的流量调度方案，请参考示例 基于权重的按比例流量路由。

标签主要是指对 Provider 端应用实例的分组，目前有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标。动态规则打标可以在运行时动态的圈住一组机器实例，而静态规则打标则需要实例重启后才能生效，其中，动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

::: info 条件路由规则

:::

条件路由与标签路由的工作模式非常相似，也是首先对请求中的参数进行匹配，符合匹配条件的请求将被转发到包含特定实例地址列表的子集。相比于标签路由，条件路由的匹配方式更灵活：

• 在标签路由中，一旦给某一台或几台机器实例打了标签，则这部分实例就会被立马从通用流量集合中移除，不同标签之间不会再有交集。有点类似下图，地址集合在输入阶段就已经划分明确。

• 而从条件路由的视角，所有的实例都是一致的，路由过程中不存在分组隔离的问题，每次路由过滤都是基于全量地址中执行

条件路由规则的主体 conditions 主要包含两部分内容：

• => 之前的为请求参数匹配条件，指定的匹配条件指定的参数将与消费者的请求上下文 (URL)、甚至方法参数进行对比，当消费者满足匹配条件时，对该消费者执行后面的地址子集过滤规则。
• => 之后的为地址子集过滤条件，指定的过滤条件指定的参数将与**提供者实例地址 (URL) **进行对比，消费者最终只能拿到符合过滤条件的实例列表，从而确保流量只会发送到符合条件的地址子集。
  • 如果匹配条件为空，表示对所有请求生效，如：=> status != staging
  • 如果过滤条件为空，表示禁止来自相应请求的访问，如：application = product =>

::: info 脚本路由规则

:::

脚本路由是最直观的路由方式，同时它也是当前最灵活的路由规则，因为你可以在脚本中定义任意的地址筛选规则。如果我们为某个服务定义一条脚本规则，则后续所有请求都会先执行一遍这个脚本，脚本过滤出来的地址即为请求允许发送到的、有效的地址集合。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

configVersion: v3.0
key: demo-provider
type: javascript
enabled: true
script: |
  (function route(invokers,invocation,context) {
      var result = new java.util.ArrayList(invokers.size());
      for (i = 0; i < invokers.size(); i ++) {
          if ("10.20.3.3".equals(invokers.get(i).getUrl().getHost())) {
              result.add(invokers.get(i));
          }
      }
      return result;
  } (invokers, invocation, context)); // 表示立即执行方法

::: info 动态配置规则

:::

通过 Dubbo 提供的动态配置规则，可以动态的修改 Dubbo 服务进程的运行时行为，整个过程不需要重启，配置参数实时生效。基于这个强大的功能，基本上所有运行期参数都可以动态调整，比如超时时间、临时开启 Access Log、修改 Tracing 采样率、调整限流降级参数、负载均衡、线程池配置、日志等级、给机器实例动态打标签等。与上文讲到的流量管控规则类似，动态配置规则支持应用、服务两个粒度，也就是说一次可以选择只调整应用中的某一个或几个服务的参数配置。

当然，出于系统稳定性、安全性的考量，有些特定的参数是不允许动态修改的，但除此之外，基本上所有参数都允许动态修改，很多强大的运行态能力都可以通过这个规则实现。通常 URL 地址中的参数均可以修改，这在每个语言实现的参考手册里也记录了一些更详细的说明。

【中等】如何在 Dubbo 中使用直连提供者？

核心配置方式

• XML 配置

1
2
3
4

<dubbo:reference
    id="myService"
    interface="com.example.MyService"
    url="dubbo://192.168.1.100:20880/com.example.MyService"/>

• 注解配置

1
2

@Reference(url = "dubbo://192.168.1.100:20880/com.example.MyService")
private MyService myService;

关键特性

适用场景

• 开发调试：快速连接本地/测试环境服务
• 问题排查：临时绕过注册中心验证服务可用性
• 单元测试：固定服务端点保证测试稳定性

注意事项

• 生产环境风险

  • 丧失服务发现能力（无法自动感知节点上下线）
  • 缺少负载均衡和熔断机制
  • 配置维护成本高（需手动管理所有节点地址）

• 安全建议

  • 限制直连 IP 白名单
  • 避免在配置文件中硬编码地址（建议使用环境变量）

  1	<dubbo:reference url="dubbo://${PROVIDER_IP}:20880/com.example.MyService"/>

调试技巧

• 动态切换：通过 JVM 参数临时启用直连

1

-Dcom.example.MyService.url=dubbo://127.0.0.1:20880

• 组合使用：保留注册中心配置，通过url属性覆盖特定服务

1
2

<dubbo:registry address="nacos://localhost:8848"/>
<dubbo:reference url="dubbo://192.168.1.100:20880" interface="com.example.MyService"/>

最佳实践：建议仅在非生产环境使用直连模式，生产环境应通过注册中心实现服务发现和治理。

流量控制

【中等】Dubbo 中的流量控制策略有哪些？

流量控制策略主要包括：限流、熔断、降级

Dubbo 中，可以通过集成 Hystrix 或 Sentinel 来实现限流、熔断、降级。

【中等】什么是 Dubbo 的 Mock 机制？如何使用？

Dubbo 的 Mock 机制是一种用于服务降级的功能。当远程调用失败或不稳定时，通过 Mock 机制可以返回预先定义的结果，从而保证服务的可用性。

除了 Dubbo，很多分布式框架和微服务架构都会提供类似的服务降级功能。比如 Spring Cloud 里面的 Hystrix，可以通过配置降级策略，在服务异常时返回降级数据。

配置方式

高级配置

• 强制 Mock：mock="force:return empty"（直接返回 Mock 结果）
• 失败 Mock：mock="fail:return null"（仅调用失败时生效）
• 方法级 Mock：mock="return {methodName}"（指定方法 Mock）

典型应用场景

• 容灾场景：网络故障/服务不可用时的兜底方案
• 开发测试：解耦依赖服务，提升开发效率
• 性能保障：非核心服务降级，保障核心链路

注意事项

• 生产环境建议：
  • 配合超时配置使用：<dubbo:reference timeout="3000" mock="true"/>
  • 避免写操作接口使用 Mock
• 性能影响：
  • Mock 类应保持简单逻辑
  • 复杂 Mock 可能成为性能瓶颈

与其他方案对比

故障处理

【中等】如何在 Dubbo 中使用健康检查？

Dubbo 通过 多级健康检查机制 保障服务可用性，开发者可根据业务需求选择默认配置或扩展自定义检查逻辑。

健康检查方式

关键配置参数

1
2
3
4
5
6
7
8
9
10
11
12

<!-- 服务端配置示例 -->
<dubbo:provider
    heartbeat="3000"                 <!-- 心跳间隔（毫秒） -->
    heartbeat-timeout="60000"        <!-- 超时剔除时间 -->
    checks="true"                    <!-- 开启消费者检查（默认 true） -->
/>

<!-- 客户端配置示例 -->
<dubbo:consumer
    check="false"                    <!-- 启动时不强制检查提供者（默认为 true 阻塞启动） -->
    stale-check="true"               <!-- 启用陈旧节点检查 -->
/>

自定义健康检查（高级）

步骤：

1. 实现HealthChecker接口：

   1 2 3 4 5 6

   public class DbHealthChecker implements HealthChecker { @Override public boolean isHealthy() { return checkDatabaseConnection(); // 自定义检查逻辑 } }

2. SPI 注册（在META-INF/dubbo/org.apache.dubbo.health.HealthChecker文件添加）：

   1	dbHealth=com.example.DbHealthChecker

监控与运维建议

• 日志监控：关注HeartbeatFailedEvent告警日志
• 组合策略：
  • 生产环境建议同时启用 心跳检测 + 注册中心剔除
  • 关键服务补充 接口级检查（如数据库/缓存连接）
• 压测注意：高频心跳可能增加注册中心负载，需调整heartbeat参数平衡敏感度与性能

【中等】Dubbo 有哪些集群容错策略？

在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。

图中节点关系说明：

• 这里的 Invoker 是 Provider 的一个可调用 Service 的抽象，Invoker 封装了 Provider 地址及 Service 接口信息
• Directory 代表多个 Invoker，可以把它看成 List<Invoker> ，但与 List 不同的是，它的值可能是动态变化的，比如注册中心推送变更
• Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个
• Router 负责从多个 Invoker 中按路由规则选出子集，比如读写分离，应用隔离等
• LoadBalance 负责从多个 Invoker 中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选

Dubbo 支持的容错策略：

• Failover - 失败自动切换。当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数（不含第一次）。
• Failfast - 快速失败。只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
• Failsafe - 失败安全。出现异常时，直接忽略。通常用于写入审计日志等操作。
• Failback - 失败自动恢复。后台记录失败请求，定时重发。通常用于消息通知操作。
• Forking - 并行调用多个服务器。只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
• Broadcast - 广播调用所有提供者。逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

集群容错配置示例：

1
2

<dubbo:service cluster="failsafe" />
<dubbo:reference cluster="failsafe" />

可观测

【中等】Dubbo 提供了哪些监控能力？

Dubbo 内部维护了多个纬度的可观测指标，并且支持多种方式的可视化监测。可观测性指标从总体上来说分为三个度量纬度：

• Admin - Admin 控制台可视化展示了集群中的应用、服务、实例及依赖关系，支持流量治理规则下发，同时还提供如服务测试、mock、文档管理等提升研发测试效率的工具。
• Metrics - Dubbo 统计了一系列的流量指标如 QPS、RT、成功请求数、失败请求数等，还包括一系列的内部组件状态如线程池数、服务健康状态等。
• Tracing - Dubbo 与业界主流的链路追踪工作做了适配，包括 Skywalking、Zipkin、Jaeger 都支持 Dubbo 服务的链路追踪。
• Logging - Dubbo 支持多种日志框架适配。以 Java 体系为例，支持包括 Slf4j、Log4j2、Log4j、Logback、Jcl 等，用户可以基于业务需要选择合适的框架；同时 Dubbo 还支持 Access Log 记录请求踪迹。

【中等】Dubbo 的 Monitor 是如何工作的？

Dubbo Monitor 在设计上兼顾低侵入性、高性能、实时性。

核心职责

• 数据采集：通过MonitorFilter拦截每次服务调用，记录：调用次数、调用时间、耗时、成功数、失败数、异常等信息。
• 数据上报：采用非阻塞方式上报统计信息到监控中心，避免影响业务性能。
• 存储和分析：监控中心可以是第三方监控系统，如：Zabbix、Prometheus 或 Dubbo 内置的轻量级实现，持久化存储数据。
• 可视化：可视化可以选择 Dubbo 提供的轻量级实现 Dubbo Admin，也可以集成第三方可视化 Dashboard。

关键组件

• MonitorFilter
  • 调用前：记录开始时间。
  • 调用后：计算耗时，封装监控数据（成功/失败状态）。
  • 上报：通过MonitorProtocol异步发送数据。
• MonitorProtocol：专为监控设计的轻量协议，支持批量上报，降低网络开销。

高可用与扩展

• 多实例部署：监控中心集群化，避免单点故障。
• 弹性扩展：采用分布式存储（如 ES、时序数据库）应对高流量。

监控数据流

1

服务调用 → MonitorFilter 拦截 → 记录指标 → 异步上报 → Monitor 中心 → 存储 → 可视化

【困难】如何在 Dubbo 中处理服务调用链路追踪？

核心实现步骤

1. 集成追踪框架

   • 选择 SkyWalking/Zipkin/Jaeger 等工具

• 添加对应依赖（如skywalking-agent.jar）

2. 配置 Dubbo 过滤器

   1 2 3

   <!-- 全局启用追踪过滤器 --> <dubbo:provider filter="tracingFilter"/> <dubbo:consumer filter="tracingFilter"/>

3. 实现追踪过滤器

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

   @Activate(group = {PROVIDER, CONSUMER}) public class TracingFilter implements Filter { @Override public Result invoke(Invoker<?> invoker, Invocation inv) throws RpcException { // 1. 从 invocation 获取/生成 TraceID String traceId = getOrCreateTraceId(inv); // 2. 记录开始时间（RPC 上下文/ThreadLocal） long start = System.currentTimeMillis(); try { // 3. 传递追踪上下文（通过 RpcContext） RpcContext.getContext().setAttachment("traceId", traceId); // 4. 执行实际调用 return invoker.invoke(inv); } finally { // 5. 上报追踪数据 report(traceId, inv, start); } } }

关键设计要点

1. 上下文传播

   • 通过RpcContext传递TraceID和SpanID
   • 跨服务时自动携带 HTTP Headers/Dubbo Attachments

2. 异步上报

   1 2 3 4

   // 示例：使用异步线程池上报 executor.submit(() -> { tracer.report(new Span(traceId, duration)); });

3. 采样控制

   1 2	# 在配置文件中控制采样率 dubbo.tracing.sample-rate=0.1

主流方案对比

生产建议

1. 性能优化

   • 采用异步批量上报（如 Jaeger 的 gRPC reporter）
   • 对高频服务启用采样（1%~10%）

2. 异常处理

   1 2 3 4 5 6 7

   try { return invoker.invoke(inv); } catch (Exception e) { // 标记错误 span span.tag("error", e.getMessage()); throw e; }

3. 扩展功能

   1 2 3 4

   // 添加自定义标签 span.tag("region", "north-1"); // 记录业务指标 span.log("order_amount", 100);

注：新版 Dubbo 已内置 Tracing 支持，可通过dubbo-spring-boot-starter快速集成，推荐优先使用官方方案。

参考资料

• Dubbo Github
• Dubbo 官方文档
• Dubbo 框架设计
• 如何基于 Dubbo 进行服务治理、服务降级、失败重试以及超时重试？

Java 虚拟机面试二

垃圾收集

【困难】如何判断 Java 对象是否可以被回收？

判断 Java 对象是否可以被回收有两种方法：

• 引用计数法
• 可达性分析法

引用计数法

引用计数算法（Reference Counting）的原理是：在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。

引用计数算法简单高效，但是存在循环引用问题——两个对象出现循环引用的情况下，此时引用计数器永远不为 0，导致无法对它们进行回收。

1
2
3
4
5
6
7
8
9
10

public class ReferenceCountingGC {
    public Object instance = null;

    public static void main(String[] args) {
        ReferenceCountingGC objectA = new ReferenceCountingGC();
        ReferenceCountingGC objectB = new ReferenceCountingGC();
        objectA.instance = objectB;
        objectB.instance = objectA;
    }
}

因为循环引用的存在，所以 Java 虚拟机不适用引用计数算法。

可达性分析法

通过 GC Roots 作为起始点进行搜索，JVM 将能够到达到的对象视为存活，不可达的对象视为死亡。

可作为 GC Roots 的对象包括下面几种：

• 虚拟机栈（栈帧中的局部变量表）中引用的对象（如当前方法局部变量）。
• 本地方法栈（JNI）中引用的 Native 对象。
• 方法区中静态属性（static字段）引用的对象。
• 方法区中常量（final常量）引用的对象。

方法区的回收条件

主要回收废弃常量和不再使用的类。

不再使用的类定义如下：

• Java 堆中不存在该类的任何实例。
• 加载该类的 ClassLoader 已被回收。
• 该类对应的 Class 对象无任何地方引用（如反射）。

以上为类卸载必要条件，且全部满足也不一定被卸载。

常见内存泄漏场景

内存泄漏的本质是对象无法回收，常见的有以下情况：

• 静态容器（如 static HashMap）持有对象。
• 未关闭的资源（如数据库连接、流）。
• 监听器未注销。
• 不合理使用 finalize() 导致对象复活。

【中等】为什么不建议使用 finalize()？

finalize() 类似 C++ 的析构函数，用来做关闭外部资源等工作。finalize() 方法是 Java 提供的对象被垃圾回收前最后的自救机会（在 GC 时被调用一次）。

• 调用时机：对象被标记为垃圾后、实际回收前，由 JVM 的垃圾回收线程触发（不保证立即执行）。
• 自救机制：在 finalize() 中重新让对象被引用（如赋值给静态变量），可避免本次回收。
• 风险：
  • 执行时机不确定，可能永远不调用。
  • 性能差（延迟回收），易导致内存泄漏。

**不要使用 finalize()**！在 Java 9 后，finalize() 直接被标记为 @Deprecated。推荐用 try-with-resources 或显式调用 close() 管理资源。

【中等】Java 对象有哪些引用类型？

在 Java 中，对象的引用类型决定了它们如何被垃圾回收（GC）处理，主要分为 4 种引用类型，按强度从高到低排列如下：

（1）强引用（Strong Reference）

被强引用关联的对象不会被垃圾收集器回收。

强引用：使用 new 一个新对象的方式来创建强引用。

1

Object obj = new Object(); // 强引用

回收条件：当 obj = null 或超出作用域时，对象变为可回收状态。

（2）软引用（Soft Reference）

被软引用关联的对象，只有在内存不够的情况下才会被回收。

软引用：使用 SoftReference 类来创建软引用。

1
2

SoftReference<Object> softRef = new SoftReference<>(new Object());
Object obj = softRef.get(); // 可能返回 null（如果被回收）

用途：适合实现缓存（如图片缓存）。

（3）弱引用（Weak Reference）

被弱引用关联的对象一定会被垃圾收集器回收，也就是说它只能存活到下一次垃圾收集发生之前。

使用 WeakReference 类来实现弱引用

1
2
3

WeakReference<Object> weakRef = new WeakReference<>(new Object());
System.gc();
Object obj = weakRef.get(); // 通常返回 null

用途：适合临时缓存（如 WeakHashMap 的键）、避免内存泄漏。

（4）虚引用（Phantom Reference）

虚引用又称为幽灵引用或者幻影引用。

无法通过虚引用获取对象（get() 始终返回 null）：一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用取得一个对象实例。

为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

使用 PhantomReference 来实现虚引用。

1
2
3
4

ReferenceQueue<Object> queue = new ReferenceQueue<>();
PhantomReference<Object> phantomRef = new PhantomReference<>(new Object(), queue);
System.gc();
Reference<?> ref = queue.poll(); // 不为 null 说明对象被回收

用途：管理堆外内存（如 NIO 的 DirectByteBuffer）。

对比：

1. 强引用是默认方式，其他引用需显式使用 java.lang.ref 包下的类。
2. 软引用 vs 弱引用：
   • 软引用适合保留缓存直到内存紧张；
   • 弱引用立即释放，避免内存泄漏。
3. 虚引用的唯一用途是关联 ReferenceQueue，用于对象回收后的通知。

通过合理选择引用类型，可以优化内存管理并避免内存泄漏问题。

【中等】Java 中有哪些垃圾回收算法？

Java 中的垃圾回收（GC）算法主要分为以下几类，每种算法针对不同的场景和内存区域（如年轻代、老年代）进行优化。

垃圾收集的性能指标主要有两点：

• 停顿时间 - 停顿时间是因为 GC 而导致程序不能工作的时间长度。
• 吞吐量 - 吞吐量关注在特定的时间周期内一个应用的工作量的最大值。对关注吞吐量的应用来说长暂停时间是可以接受的。由于高吞吐量的应用关注的基准在更长周期时间上，所以快速响应时间不在考虑之内。

以下是核心算法及其特点的概括：

标记-清除算法（Mark-Sweep）

• 原理：
  1. 标记：从 GC Roots 出发，标记所有可达对象。
  2. 清除：遍历堆内存，回收未被标记的对象。
• 缺点：
  • 产生内存碎片（不连续空间），可能导致大对象分配失败。
  • 效率较低（需遍历全堆）。
• 适用场景：老年代（如 CMS 回收器的初始阶段）。

标记-整理算法（Mark-Compact）

• 原理：
  1. 标记：与标记-清除相同，标记可达对象。
  2. 整理：将存活对象向内存一端移动，清理边界外空间。
• 优点：避免内存碎片。
• 缺点：移动对象开销大（需更新引用地址）。
• 适用场景：适合老年代，对象存活率高（如 Serial Old、Parallel Old 回收器）。

复制算法（Copying）

• 原理：
  • 将内存分为两块（From 和 To 空间），每次只使用一块。
  • GC 时将存活对象从 From 复制到 To 空间，并清空 From。
• 优点：
  • 无内存碎片。
  • 高效（仅复制存活对象）。
• 缺点：内存利用率仅 50%（需预留一半空间）。
• 适用场景：年轻代（如 Serial、ParNew 等回收器），因年轻代对象存活率低。
• 优化：实际 JVM 将年轻代分为 Eden 和 Survivor（From/To） 区（比例通常为 8:1:1），通过多次复制到 Survivor 区避免浪费。

分代收集算法（Generational Collection）

分代收集是 JVM 在吞吐量、延迟和内存占用之间找到的经典平衡点，而新一代 GC 则通过更复杂的并发机制尝试突破其限制。

跨代引用处理：使用记忆集（Remembered Set）记录老年代对年轻代的引用，避免全堆扫描。

根据对象存活周期将堆分为年轻代和老年代，对不同区域采用不同算法：

• 年轻代：复制算法（因对象朝生夕死，存活率低）。
• 老年代：标记-清除或标记-整理（因对象存活率高）。
• 永久代：这部分就是早期 Hotspot JVM 的方法区实现方式了，储存 Java 类元数据、常量池、Intern 字符串缓存。在 JDK 8 之后就不存在永久代这块儿了。

分区算法（Region-Based）

• 原理：将堆划分为多个独立区域（如 G1 的 Region），优先回收垃圾最多的区域。
• 优点：
  • 控制每次回收的区域数量，减少停顿时间（STW）。
  • 适合大内存应用（如 G1、ZGC、Shenandoah）。

增量算法（Incremental）

• 目标：减少单次 GC 停顿时间，通过分阶段执行 GC 与用户线程交替运行。
• 缺点：
  • 线程切换开销大，整体吞吐量可能下降。
• 现代实现：如 CMS 的并发标记阶段。

常见垃圾回收器与算法对应

现代 JVM 趋向于使用分代+分区+并发的复合算法（如 G1），在吞吐量和延迟之间取得平衡。

【中等】Java 中常见的垃圾收集器有哪些？

以下是 Java 主要垃圾收集器的详细对比表格，涵盖算法、特点、适用场景和关键参数：

关键对比维度

• 吞吐量：Parallel GC（Parallel Scavenge + Parallel Old）最优。
• 延迟：ZGC/Shenandoah < G1 < CMS < Parallel GC。
• 堆大小：
  • 小堆（<4GB）：Serial GC / Parallel GC。
  • 大堆（4GB~数十 GB）：G1。
  • 超大堆（TB 级）：ZGC/Shenandoah。
• 版本兼容性：
  • JDK 8：默认 Parallel GC，可选 G1/CMS（CMS 已废弃）。
  • JDK 11+：默认 G1，可选 ZGC/Shenandoah。

选择建议

• 常规服务端应用：JDK 8 用 G1，JDK 11+ 用 ZGC（若需超低延迟）。
• 批处理任务：Parallel GC（高吞吐优先）。
• 资源受限环境：Serial GC（如嵌入式设备）。
• 兼容性测试：JDK 11+ 可试用 Shenandoah（非 Oracle 官方构建需注意）。

通过此表格可快速定位适合业务需求的 GC 组合。

【困难】为什么 Java 8 移除了永久代（PermGen）并引入了元空间（Metaspace）？

Java 8 用元空间替代永久代，解决了 PermGen 固定大小易导致内存溢出和垃圾回收效率低的问题。元空间使用本地内存，具备更灵活的内存分配能力，提升了垃圾收集和内存管理的效率。

永久代（PermGen）的主要问题

• 固定大小限制：永久代大小通过 -XX:MaxPermSize 设定，默认较小（64MB~128MB），易触发 OutOfMemoryError: PermGen space，尤其是动态加载类过多时（如频繁部署的 Web 应用）。
• 垃圾回收效率低：永久代与老年代共用垃圾回收机制（Full GC 时才会回收），类卸载条件苛刻（需类加载器被回收）。
• 内存管理不灵活：永久代在 JVM 堆内分配，与对象堆共享内存空间，易导致堆内存碎片化。

元空间（Metaspace）的优势

• 使用本地内存（Native Memory）：元空间直接分配在操作系统的本地内存中，默认无上限（仅受系统物理内存限制），避免 PermGen 大小硬限制问题。可通过 -XX:MaxMetaspaceSize 设置上限（如不设置则动态扩展）。
• 自动调整大小：元空间可以根据需要自动扩展大小，从而降低了 OOM 的风险。
• 性能优化：元空间由于在堆外，因此减少了 Full GC 触发频率。避免了频繁回收 PermGen 时的停顿。

永久代 vs. 元空间

【困难】Java 中的 Young GC、Old GC、Full GC 和 Mixed GC 的区别是什么？

Young GC

Young GC 又称为 YGC 或 Minor GC，即年轻代垃圾回收。

• 目标：高效回收短期对象，减少全局停顿时间，避免频繁扫描老年代。
• 作用范围：仅回收 年轻代（Eden + Survivor 区，即 S0/S1）。
• 触发条件：当年轻代内存（尤其是 Eden 区）被填满时触发。
  • Eden 区空间不足：新对象优先分配在 Eden 区，Eden 满时触发 YGC。
  • Eden + Survivor 区空间不足：若 Eden + Survivor 区无法容纳存活对象，触发 YGC，部分对象可能直接晋升老年代。
  • Full GC 前置操作：如 Parallel Scavenge，默认在 Full GC 前先执行 YGC（可通过 -XX:+ScavengeBeforeFullGC 控制）。
• 关键机制
  • 对象分配：新对象优先分配在 Eden 区。
  • 对象晋升：
    • 年龄阈值：-XX:MaxTenuringThreshold（默认 15）。
    • 提前晋升：若 Survivor 区空间不足，存活对象直接进入老年代。
  • 复制算法：存活对象在 Eden 和 Survivor 区间拷贝，清空原区域。
• 特点
  • 回收速度快（通常毫秒级），但会触发 STW。
  • 高效回收：针对短期对象，减少老年代扫描。
• 要点
  • Survivor 区溢出：存活对象过多时，直接晋升老年代，可能引发老年代积压。
  • 与 Full GC 的关系：Minor GC 前会检查老年代剩余空间，若不足可能触发 Full GC（取决于 GC 策略）。
• 参数
  • -XX:MaxTenuringThreshold=15：晋升老年代的年龄阈值。
  • -XX:SurvivorRatio=8：Eden 区与单个 Survivor 区的比例（默认 8:1:1）。

Old GC

Old GC (Major GC 或 OGC) ，老年代垃圾回收

• 作用范围：只针对老年代。
• 触发条件：当老年代空间不足时触发，通常是当从年轻代晋升到老年代的对象过多，或者老年代的存活对象数量达到一定阈值时。
• 执行方式：只回收老年代的对象，年轻代不受影响。
• 特点：执行时间比 Young GC 长，因为老年代中的对象存活时间更长，且数量较多。

Full GC

Full GC，全堆垃圾回收

• 作用范围：对整个堆内存（包括年轻代和老年代）进行回收。
• 触发条件：当老年代空间不足且无法通过老年代垃圾回收释放足够空间，或其他情况导致系统内存压力较大时触发（如 System.gc () 调用）。
• 执行方式：回收所有代（年轻代、老年代）中的垃圾，并且可能会伴随着元空间的回收。
• 特点：回收时间最长，会触发整个 JVM 的停顿（Stop - The - World），对性能有较大影响，通常不希望频繁发生。

Full GC 是对整个 Java 堆（年轻代 + 老年代） 和 方法区（元空间/Metaspace） 进行垃圾回收，部分收集器还会回收直接内存（如 ZGC）。

Full GC 特点：

• Stop-The-World（STW） 时间较长（秒级），对性能影响显著。
• 回收算法因 GC 类型而异（如 Serial Old 使用标记-整理，CMS 使用并发标记-清除）。

Full GC 触发条件

减少 Full GC 的优化策略

常见表现与影响

• 应用卡顿：STW 导致所有业务线程暂停（如接口超时、TPS 骤降）。
• 频繁 Full GC：可能由内存泄漏、不合理对象分配或 JVM 参数配置不当引起（如 -Xmx 过小）。

优化建议

• 避免内存泄漏：检查长生命周期对象（如缓存）是否无限制增长。
• 调整 JVM 参数：
  • 增大老年代空间（-Xmx 和 -Xms 设为一致，避免动态扩容触发 GC）。
  • 优化晋升阈值（-XX:MaxTenuringThreshold）。
  • 使用更高效的 GC 器（如 G1/ZGC 替代 CMS）。
• 禁用显式 GC：添加 -XX:+DisableExplicitGC。

关键参数

总结：Full GC 是 JVM 内存回收的最后手段，触发条件复杂，需结合日志和监控定位根本原因，针对性优化堆大小、GC 策略或代码逻辑。

Mixed GC

Mixed GC （仅适用于 G1 GC 的混合垃圾回收）

• 作用范围：同时回收年轻代和部分老年代区域。
• 触发条件：当 G1 垃圾回收器发现老年代区域的垃圾过多时触发。
• 执行方式：混合回收年轻代和部分老年代区域，主要目的是减少老年代中的垃圾积压。
• 特点：结合了 YGC 的快速回收和 OGC 的深度回收，尽量减少停顿时间，适用于大内存应用。

【困难】Java 的 CMS 垃圾回收流程是怎样的？

CMS 是一种以低延迟为目标的垃圾回收器，主要用于老年代回收，其核心流程分为四个阶段，其中两个阶段会触发 STW（Stop-The-World），其余阶段与用户线程并发执行。

CMS 收集器运行步骤如下：

1. 初始标记：仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，需要停顿。
2. 并发标记：进行 GC Roots Tracing 的过程，它在整个回收过程中耗时最长，不需要停顿。
3. 重新标记：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿。
4. 并发清除：回收在标记阶段被鉴定为不可达的对象。不需要停顿。

在整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，不需要进行停顿。

CMS 的缺陷与应对措施

• 内存碎片：长期运行后可能触发 Full GC（压缩内存），通过 -XX:CMSFullGCsBeforeCompaction 设置压缩频率。
• 并发模式失败（Concurrent Mode Failure）：
  • 老年代空间不足时，退化为 Serial Old 收集器（STW 时间更长）。
  • 优化：调整 -XX:CMSInitiatingOccupancyFraction（默认 68%，建议 70-80%）。
• 浮动垃圾：需预留空间（通过 -XX:+UseCMSInitiatingOccupancyOnly 避免动态调整阈值）。

【困难】Java 的 G1 垃圾回收流程是怎样的？

G1 通过分区和增量回收实现低延迟，兼顾吞吐量与内存碎片控制，是 JDK 9 后的默认垃圾回收器。

核心设计思想

• 分区（Region）模型：将堆划分为多个大小相等的 Region（默认约 2048 个），动态分代（逻辑区分 Eden/Survivor/Old/Humongous 区）。
• 停顿预测模型：根据用户设定的 -XX:MaxGCPauseMillis（默认 200ms），优先回收垃圾最多（Garbage-First）的 Region。
• 并发标记：减少 STW 时间，但最终标记和拷贝阶段仍需停顿。
• 混合回收：兼顾年轻代和老年代，避免 Full GC。
• 适用场景：大堆内存（4GB+）、需平衡吞吐与延迟的应用（如 JDK9+默认 GC）。

G1 的垃圾回收分为两大阶段：

1. 并发标记阶段（Concurrent Marking，基于 SATB 算法）
2. 对象拷贝阶段（Evacuation，STW）

G1 并发标记阶段（SATB-Based）

1. 初始标记（Initial Marking，STW）：标记从 GC Roots 直接可达的对象。
   • 短暂 STW（Stop-The-World）。
   • 使用**外部 Bitmap **记录存活对象（而非对象头）。
   • 通常与年轻代回收（Young GC）同步触发。
2. 并发标记（Concurrent Marking）：递归标记所有可达对象。
   • 与用户线程并发执行。
   • 使用** SATB（Snapshot-At-The-Beginning）**算法记录标记过程中的引用变化（通过写屏障维护）。
3. 最终标记（Final Marking，STW）：处理 SATB 队列中的引用变更，完成最终标记。
   • 短暂 STW。
   • 修正并发标记期间漏标的对象。
4. 清理阶段（Cleanup，STW）
   • 统计每个 Region 的存活对象比例。
   • 回收完全无存活对象的 Region（直接整区回收）。
   • 生成回收集合（CSet）供后续拷贝阶段使用。

对象拷贝阶段（Evacuation，STW）

• 作用：将回收集合（CSet）中的存活对象拷贝到空闲 Region。
• 流程：
  1. 根据标记结果，选择垃圾比例高的 Region 组成 CSet。
  2. 并行将 CSet 中的存活对象复制到新 Region（类似复制算法）。
  3. 清空原 Region，加入空闲列表。
• 特点：
  • 完全 STW，是 G1 的主要停顿来源。
  • 支持混合回收（Mixed GC）：同时回收年轻代和老年代 Region。

G1 Mixed GC（混合回收）

• 触发条件：老年代占用超过阈值（-XX:InitiatingHeapOccupancyPercent，默认 45%）。
• 行为：
  1. 在年轻代回收时，**额外选择部分老年代 Region **加入 CSet。
  2. 通过-XX:G1MixedGCLiveThresholdPercent控制老年代 Region 的回收阈值（存活对象比例低于该值才回收）。

关键机制

• Remembered Set（RSet）：每个 Region 维护一个 RSet，记录其他 Region 对它的引用，避免全堆扫描。
• Humongous 区：存放大对象（超过 Region 50%），直接分配在 Old 区，避免反复拷贝。

参数配置

优缺点

• 优势：
  • 可控停顿时间，适合大堆（数十 GB）应用。
  • 内存整理减少碎片（复制算法）。
• 劣势：
  • 内存占用较高（RSet 和并发标记开销）。
  • 复杂场景下可能退化为 Serial Old（如分配失败）。

适用场景

• 替代 CMS，适用于 JDK 8+ 的中大堆应用（如 6GB~100GB）。
• 对延迟敏感且需平衡吞吐量的场景（如微服务、实时系统）。

【困难】Java 的 ZGC 垃圾回收流程是怎样的？

【困难】JVM 垃圾回收时产生的 concurrent mode failure 的原因是什么？

Concurrent Mode Failure 是 CMS（Concurrent Mark-Sweep） 垃圾回收器在并发清理阶段失败，被迫触发 Full GC（Serial Old） 的现象，导致长时间 STW（Stop-The-World），影响应用响应速度。

CMS 工作流程：

1. 初始标记（Initial Mark）：标记根对象直接关联的对象（短暂停顿）。
2. 并发标记（Concurrent Mark）：与应用线程并发，标记老年代存活对象。
3. 重新标记（Remark）：修正并发标记期间变动的对象（短暂停顿）。
4. 并发清理（Concurrent Sweep）：清除垃圾对象（并发执行）。

优化措施

• 增加老年代内存：调整 -Xmx 和 -XX:CMSInitiatingOccupancyFraction，降低 CMS 触发频率。
• 调低 CMS 触发阈值：通过 -XX:CMSInitiatingOccupancyFraction=<N> 提前触发回收（如设为 70%）。
• 碎片整理：配置 -XX:+UseCMSCompactAtFullCollection，在 Full GC 后整理碎片。
• 增加年轻代内存：减少对象晋升老年代的频率，降低老年代压力。

典型 CMS 参数配置示例

1
2
3
4

java -XX:+UseConcMarkSweepGC \
     -XX:CMSInitiatingOccupancyFraction=70 \
     -XX:+UseCMSCompactAtFullCollection \
     -Xmx4g -Xms4g YourApplication

MyBatis 面试

【简单】MyBatis 中 #{} 和 ${} 的区别是什么？

MyBatis 中 #{} 和 ${} 的区别对比

关键结论

• **优先用 #{}**：处理用户输入或条件值，确保安全。
• **谨慎用 ${}**：仅用于非用户输入的动态 SQL 部分（如动态表名），需手动过滤参数。
• 常见错误：
  • 错误：ORDER BY #{column}（预编译后引号包裹列名，语法错误）。
  • 正确：ORDER BY ${column} LIMIT #{limit}（混合使用）。

底层机制对比

#{} 的执行流程（安全）

1
2
3
4
5

-- 生成的 SQL（预编译）
SELECT * FROM user WHERE id = ?;

-- 参数值通过 PreparedStatement 安全传递
pstmt.setInt(1, 5);

${} 的执行流程（风险）

1
2

-- 生成的 SQL（直接拼接）
SELECT * FROM user WHERE name = 'Alice' OR '1'='1';  -- 注入攻击示例

何时必须使用 ${}？

1. 动态表名/列名：

   1	SELECT * FROM ${tableName} WHERE ${column} = #{value}

2. SQL 函数或关键字：

   1	ORDER BY ${sortField} ${sortOrder}

安全建议

• 使用 ${} 时，用 @Param 注解白名单校验：

  1	List<User> selectByTable(@Param("tableName") String tableName);

  1 2 3 4 5 6

  <!-- 手动校验表名合法性 --> SELECT * FROM ${tableName} WHERE 1=1 <if test="tableName in {'user', 'order'}"> AND status = #{status} </if>

【简单】MyBatis 如何实现一对一、一对多的关联查询 ？

【简单】使用 MyBatis 的 mapper 接口调用时有哪些要求？

【简单】MyBatis 自带的连接池有了解过吗？

【简单】MyBatis 和 Hibernate 有哪些差异？

总结选择建议

• 选择 MyBatis：

  • 需要精细控制 SQL，追求极致性能。
  • 项目涉及多表复杂查询或数据库特性优化。

• 选择 Hibernate：

  • 快速开发，业务以简单 CRUD 为主。
  • 团队熟悉 ORM，希望减少 SQL 编写。

混合使用：部分项目用 MyBatis 处理复杂查询，Hibernate 处理简单模块。

【中等】说说 MyBatis 的缓存机制？

【中等】MyBatis 写个 Xml 映射文件，再写个 DAO 接口就能执行，这个原理是什么？

【中等】MyBatis 动态 sql 有什么用？执行原理？有哪些动态 sql？

【中等】MyBatis 是否支持延迟加载？如果支持，它的实现原理是什么？

【中等】简述 MyBatis 的插件运行原理，以及如何编写一个插件？

【中等】JDBC 编程有哪些不足之处，MyBatis 是如何解决的？

【中等】MyBatis 都有哪些 Executor 执行器？它们之间的区别是什么？

【中等】MyBatis 如何实现数据库类型和 Java 类型的转换的？

【中等】MyBatis 有哪些核心组件？

MyBatis 有以下核心组件：

• **SqlSessionFactoryBuilder**：负责创建 SqlSessionFactory 实例。用完即弃。
• **SqlSessionFactory**：负责创建 SqlSession 实例。全局单例，配置中心。
• **SqlSession**：通过方法签名和 Mapper 相互映射。请求级核心，需及时关闭。
• **Mapper**：映射器是一些由用户创建的、绑定 SQL 语句的接口。轻量级对象，随用随建。

下面是它们之间的关系：

1
2

SqlSessionFactoryBuilder → SqlSessionFactory → SqlSession → Mapper Proxy
       (方法级)               (应用级)           (请求级)        (方法级)

SqlSessionFactoryBuilder

• 生命周期：方法级（最短）
• 作用：用于构建 SqlSessionFactory，解析 XML 配置（如 mybatis-config.xml）。
• 特点：
  • 构建完成后即可销毁，无状态，不占用资源。
  • 通常作为局部变量使用。

1

SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(inputStream);

SqlSessionFactory

• 生命周期：应用级（最长）
• 作用：创建 SqlSession，全局唯一，线程安全。
• 特点：
  • 通常作为单例存在于整个应用运行期间。
  • 维护数据库连接池和全局配置（如缓存、别名）。

1
2
3
4
5
6
7
8
9
10

// 推荐通过单例管理
public class MyBatisUtil {
    private static final SqlSessionFactory factory;
    static {
        factory = new SqlSessionFactoryBuilder().build(inputStream);
    }
    public static SqlSessionFactory getFactory() {
        return factory;
    }
}

SqlSession

• 生命周期：请求/事务级
• 作用：执行 SQL、获取 Mapper 接口实例、管理事务。
• 特点：
  • 非线程安全，每次请求需创建新实例，用完后必须关闭（避免连接泄漏）。
  • 默认不自动提交事务，需手动 commit() 或 rollback()。

1
2
3
4
5

try (SqlSession session = factory.openSession()) {  // 自动关闭
    UserMapper mapper = session.getMapper(UserMapper.class);
    User user = mapper.selectById(1);
    session.commit();  // 提交事务
}

Mapper

• 生命周期：方法级（与 SqlSession 绑定）
• 作用：通过动态代理将接口方法调用转换为 SQL 执行。
• 特点：
  • 由 SqlSession 创建，生命周期跟随 SqlSession。
  • 无需手动实现，MyBatis 自动生成代理类。

1
2

// 代理对象随 SqlSession 销毁而失效
UserMapper mapper = session.getMapper(UserMapper.class);

【中等】能详细说说 MyBatis 的执行流程吗？

【困难】MyBatis 的架构是如何设计的？

MyBatis 的架构设计通过 分层解耦 和 动态代理 实现了 SQL 与 Java 代码的分离，其核心在于：

• 配置驱动：集中管理 SQL 和映射规则。
• 组件化：各层职责单一，易于扩展（如插件）。
• 平衡灵活与易用：既保留 JDBC 的掌控力，又简化了重复操作。

这种设计使其在需要高性能和灵活 SQL 的场景中表现优异，尤其适合中大型复杂业务系统。

MyBatis 的架构设计以 SQL 与 Java 对象的灵活映射 为核心，采用分层模块化设计，平衡了灵活性与易用性。

分层架构设计

MyBatis 的架构分为四层，各层职责明确，通过接口解耦：

基础支撑层

功能：为上层提供通用能力支持

• **类型处理器 (TypeHandler)**：处理 Java 类型与 JDBC 类型转换（如 String ↔ VARCHAR）。支持自定义扩展（如枚举类型转换）。
• 连接管理：集成连接池（如 HikariCP、Druid），管理数据库连接。
• 事务管理：提供 JDBC 和 Managed 两种事务模式（可集成 Spring 事务）。
• 缓存管理：一级缓存（SqlSession 级别）、二级缓存（Mapper 级别）。支持 Redis、Ehcache 等第三方缓存集成。

核心处理层

功能：执行 SQL 并处理结果映射

• **配置解析 (Configuration)**：加载 mybatis-config.xml 和 Mapper.xml，存储所有配置信息（如别名、插件）。
• **SQL 解析 (SqlSource & BoundSql)**：解析动态 SQL（<if>、<foreach>），生成可执行的 SQL 字符串和参数映射。
• 执行器 (Executor)
  • 类型：
    • SimpleExecutor：默认执行器，每次执行新开 PreparedStatement。
    • ReuseExecutor：复用 Statement 对象。
    • BatchExecutor：批量操作优化。
  • 职责：调用 JDBC 执行 SQL，触发插件拦截链。
• **结果集处理 (ResultSetHandler)**：将 ResultSet 转换为 Java 对象（根据 ResultMap 或自动映射）。

MySQL 面试之事务和锁篇

MySQL 事务

扩展阅读：

• MySQL 官方文档之 InnoDB 锁和事务模型

【简单】什么是事务，什么是 ACID？

事务指的是满足 ACID 特性的一组操作。事务内的 SQL 语句，要么全执行成功，要么全执行失败。可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。通俗来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。

ACID 是数据库事务正确执行的四个基本要素。

• 原子性（Atomicity）
  • 事务被视为不可分割的最小单元，事务中的所有操作要么全部提交成功，要么全部失败回滚。
  • 回滚可以用日志来实现，日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。
• 一致性（Consistency）
  • 数据库在事务执行前后都保持一致性状态。
  • 在一致性状态下，所有事务对一个数据的读取结果都是相同的。
• 隔离性（Isolation）
  • 一个事务所做的修改在最终提交以前，对其它事务是不可见的。
• 持久性（Durability）
  • 一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。
  • 可以通过数据库备份和恢复来实现，在系统发生奔溃时，使用备份的数据库进行数据恢复。

一个支持事务（Transaction）中的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性。

【中等】事务存在哪些并发一致性问题？

事务中存在的并发一致性问题有：

• 丢失修改
• 脏读
• 不可重复读
• 幻读

“丢失修改”是指一个事务的更新操作被另外一个事务的更新操作替换。

如下图所示，T₁ 和 T₂ 两个事务对同一个数据进行修改，T₁ 先修改，T₂ 随后修改，T₂ 的修改覆盖了 T₁ 的修改。

“脏读（dirty read）”是指当前事务可以读取其他事务未提交的数据。

如下图所示，T₁ 修改一个数据，T₂ 随后读取这个数据。如果 T₁ 撤销了这次修改，那么 T₂ 读取的数据是脏数据。

“不可重复读（non-repeatable read）”是指一个事务内多次读取同一数据，过程中，该数据被其他事务所修改，导致当前事务多次读取的数据可能不一致。

如下图所示，T₂ 读取一个数据，T₁ 对该数据做了修改。如果 T₂ 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

“幻读（phantom read）”是指一个事务内多次读取同一范围的数据，过程中，其他事务在该数据范围新增了数据，导致当前事务未发现新增数据。

事务 T₁ 读取某个范围内的记录时，事务 T₂ 在该范围内插入了新的记录，T₁ 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。

【中等】长事务可能会导致哪些问题？

长事务可能会导致以下问题：

• 锁竞争与资源阻塞
  • 长事务长时间持有锁，导致其他事务阻塞，增加系统等待时间，降低并发性能。
  • 业务线程因数据库请求等待而阻塞，可能引发连锁反应（如服务雪崩），造成严重线上事故。
• 死锁风险增加 - 多个长事务互相等待对方释放锁，容易形成死锁，导致系统无法正常执行。
• 主从延迟问题 - 主库执行时间长，从库同步及重放耗时增加，导致主从数据长时间不一致。
• 回滚效率低下 - 长事务执行中途失败时，回滚操作会浪费已执行的资源与时间，影响系统效率。

【困难】事务的二阶段提交是什么？

事务的二阶段提交确保 redo log（重做日志） 和 binlog（二进制日志） 的一致性，防止崩溃恢复时出现数据丢失或不一致。

两阶段流程

• Prepare 阶段（准备阶段） - InnoDB 写入 redo log，并标记为 prepare 状态（事务预提交，但未最终提交）。
• Commit 阶段（提交阶段） - MySQL Server 写入 binlog（记录 DML 操作）。binlog 写入成功后，InnoDB 将 redo log 状态改为 commit，完成事务提交。

binlog 和 redo log 的区别

为什么需要二阶段提交？

无论是单独先写 redo log 或先写 binlog，都可能导致数据不一致：

1. 先写 redo log，后写 binlog（宕机时 binlog 未写入） - redo log 恢复数据，但 binlog 缺失该事务 → 主从数据不一致。
2. 先写 binlog，后写 redo log（宕机时 redo log 未写入） - binlog 有记录，但 redo log 未提交 → 数据库实际数据丢失，与 binlog 不一致。

为了解决以上问题，所以需要事务二阶段提交（repare → commit），以确保写入两日志的原子性。

二阶段提交如何保证一致性？

MySQL 崩溃恢复时，检查两日志状态：

• redo log prepare，binlog 未写入 - 直接回滚（两日志均无有效记录）。
• redo log prepare，binlog 已写入 - 对比两日志数据：
  • 一致：提交事务（redo log commit）。
  • 不一致：回滚事务（保证数据一致）。

【中等】有哪些事务隔离级别，分别解决了什么问题？

为了解决以上提到的并发一致性问题，SQL 标准提出了四种“事务隔离级别”来应对这些问题。事务隔离级别等级越高，越能保证数据的一致性和完整性，但是执行效率也越低。因此，设置数据库的事务隔离级别时需要做一下权衡。

事务隔离级别从低到高分别是：

• 读未提交（read uncommitted） - 是指，事务中的修改，即使没有提交，对其它事务也是可见的。
• 读已提交（read committed） - 是指，事务提交后，其他事务才能看到它的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。
  • 读已提交解决了脏读的问题。
  • 读已提交是大多数数据库的默认事务隔离级别，如 Oracle。
• 可重复读（repeatable read） - 是指：保证在同一个事务中多次读取同样数据的结果是一样的。
  • 可重复读解决了不可重复读问题。
  • 可重复读是 InnoDB 存储引擎的默认事务隔离级别。
• 串行化（serializable ） - 是指，强制事务串行执行，对于同一行记录，加读写锁，一旦出现锁冲突，必须等前面的事务释放锁。
  • 串行化解决了幻读问题。由于强制事务串行执行，自然避免了所有的并发问题。
  • 串行化策略会在读取的每一行数据上都加锁，这可能导致大量的超时和锁竞争。这对于高并发应用基本上是不可接受的，所以一般不会采用这个级别。

事务隔离级别对并发一致性问题的解决情况：