在单元测试中，需真实模拟 Ignite 节点因硬件故障等导致的非正常中断（disorderly shutdown），而非 Ignite.close() 的优雅退出；推荐采用 Testcontainers 启动独立 Docker 容器运行 Ignite 节点，并通过 stop() 触发强制终止，兼顾隔离性、可控性与生产贴近度。
在单元测试中，需真实模拟 ignite 节点因硬件故障等导致的**非正常中断（disorderly shutdown）**，而非 `ignite.close()` 的优雅退出；推荐采用 testcontainers 启动独立 docker 容器运行 ignite 节点，并通过 `stop()` 触发强制终止，兼顾隔离性、可控性与生产贴近度。
在 Apache Ignite 的高可用性验证与容错逻辑测试中，仅靠单 JVM 内多实例（如 Ignition.start(config) 多次调用）无法准确复现真实故障场景——因为 Ignite.close() 会触发完整生命周期清理（如心跳注销、分区状态同步、缓存预写日志刷盘等），属于有序关闭（orderly shutdown），而生产环境中节点可能因进程被 kill -9、主机断电、OOM Killer 终止或网络隔离等原因瞬间失联，此时集群需依赖发现机制、心跳超时、副本重平衡等策略维持服务连续性。
直接操作线程（如尝试 Thread.stop()）不仅已被 Java 标记为 @Deprecated 且存在严重安全隐患（如死锁、资源泄漏、JVM 状态不一致），更无法可靠区分不同 Ignite 实例所创建的线程（Ignite 内部大量使用共享线程池与守护线程，启动后仍会动态派生任务线程）。同理，手动 Process.destroyForcibly() 虽可模拟强杀，但需自行管理 JVM 进程启停、端口分配、配置注入与日志捕获，测试脚本复杂度高、可移植性差，且难以集成进标准 Maven/Gradle 流程。
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
✅ 推荐方案：Testcontainers + 官方 Ignite 镜像
Testcontainers 是基于 Docker 的测试辅助框架，能以声明式方式拉取、启动、销毁容器化服务，天然满足“进程级隔离”与“真实崩溃模拟”两大核心诉求：
// Maven 依赖（pom.xml） <dependency><groupid>org.testcontainers</groupid><artifactid>testcontainers</artifactid><version>1.19.8</version><scope>test</scope></dependency><dependency><groupid>org.testcontainers</groupid><artifactid>ignite</artifactid><version>1.19.8</version><scope>test</scope></dependency>
@Test
public void testClusterSurvivesNodeFailure() throws Exception {
// 启动两个独立 Ignite 节点容器（模拟双机集群）
GenericContainer> node1 = new GenericContainer("apacheignite/ignite:2.16.0")
.withExposedPorts(10800) // Thin Client 端口
.withEnv("IGNITE_CONFIG_URL", "file:///opt/ignite/config/default-config.xml");
GenericContainer> node2 = new GenericContainer("apacheignite/ignite:2.16.0")
.withExposedPorts(10800)
.withEnv("IGNITE_CONFIG_URL", "file:///opt/ignite/config/default-config.xml");
node1.start();
node2.start();
// 使用 Thin Client 连接集群（避免嵌入式依赖冲突）
try (IgniteClient client = Ignition.startClient(
ClientConfiguration.builder()
.addAddress(node1.getHost() + ":" + node1.getMappedPort(10800))
.addAddress(node2.getHost() + ":" + node2.getMappedPort(10800))
.build())) {
// 执行业务操作：写入带备份的缓存
client.getOrCreateCache("myCache").put("key1", "value1");
// ⚠️ 关键步骤：模拟节点突然宕机（等效于 kill -9）
node1.stop(); // 容器进程被强制终止，无任何清理钩子
// 验证集群自愈能力：剩余节点应仍可读写，且副本自动接管
await().atMost(30, TimeUnit.SECONDS)
.untilAsserted(() ->
assertThat(client.cache("myCache").get("key1"))
.isEqualTo("value1"));
}
}
? 进阶增强：注入网络异常（Toxiproxy）
若需测试更严苛场景（如临时网络分区、高延迟、连接重置），可结合 Testcontainers 的 Toxiproxy 模块：
ToxiproxyContainer toxiproxy = new ToxiproxyContainer();
toxiproxy.start();
// 创建代理，指向 node1 的 10800 端口
Proxy proxy = toxiproxy.getProxy("ignite-node1", node1.getMappedPort(10800));
// 注入“连接拒绝”毒剂，模拟瞬时网络闪断
proxy.toxics().connectionDelay("delay", ToxicDirection.UPSTREAM, 5000);
⚠️ 注意事项与最佳实践
- 禁用组播，强制静态发现：容器内网络环境不支持 UDP 组播，务必在 default-config.xml 中配置 TcpDiscoveryVmIpFinder 或 TcpDiscoveryStaticIpFinder，显式列出所有节点 IP（Docker 网络下可用容器名）；
- 持久化配置外挂：通过 withClasspathResourceMapping() 将自定义 XML 配置挂载进容器，确保 clientMode=false、backups=1 等关键参数生效；
- 资源清理自动化：利用 JUnit 5 的 @AfterEach 或 @RegisterExtension 确保容器在测试后自动销毁，避免端口占用；
- 性能权衡：容器启动约需 2–5 秒，适合集成测试（IT）而非毫秒级单元测试（UT）；若追求极致速度，可考虑 IgniteTestUtils 中的轻量模拟器（但牺牲真实性）。
综上，脱离 JVM 进程边界、借助容器化手段实现节点级故障注入，是当前最可靠、可维护、与生产环境对齐的 Ignite 容错测试范式。它既规避了私有 API 和线程操作的风险，又提供了真实的系统行为可观测性，是构建高可信分布式应用的基石实践。
