在单元测试中真实模拟 Ignite 节点“突然崩溃”（非优雅关闭），需避免 Ignite.close() 的有序终止，推荐采用进程隔离 + 容器化方式（如 Testcontainers）启动独立 Ignite 实例，并通过 stop() 触发无通知中断，从而准确复现网络分区、数据重平衡与分区丢失等分布式异常场景。
在单元测试中真实模拟 ignite 节点“突然崩溃”（非优雅关闭），需避免 `ignite.close()` 的有序终止，推荐采用进程隔离 + 容器化方式（如 testcontainers）启动独立 ignite 实例，并通过 `stop()` 触发无通知中断，从而准确复现网络分区、数据重平衡与分区丢失等分布式异常场景。
在 Apache Ignite 的可靠性验证中，模拟无序节点故障（disorderly node failure） 是检验集群容错能力的关键环节。与调用 Ignite.close() 所触发的协作式关闭不同，真实生产环境中的硬件故障、OOM Kill、SIGKILL 强制终止等场景会导致节点瞬间失联——此时心跳超时、拓扑变更、备份副本提升、分区再平衡等机制必须被完整触发，才能保障业务连续性。
❌ 不推荐：JVM 内线程级暴力终止
虽然技术上可通过 Thread.stop()（已废弃且不安全）或反射操作内部线程池强制中断，但存在严重缺陷：
- Ignite 线程命名无强约束，无法 100% 区分归属节点；
- 多节点共 JVM 时易引发线程交叉干扰（如共享 Netty EventLoopGroup）；
- 违反 JVM 安全模型，可能造成锁未释放、内存泄漏或 JVM 不稳定；
- 无法模拟网络层断连（如 TCP RST、防火墙丢包），仅停留在应用层“假死”。
✅ 推荐方案：容器化进程隔离（Testcontainers + Docker）
最贴近真实环境、可重复、可扩展的测试方式是将每个 Ignite 节点运行于独立进程（即独立 JVM）中，并通过容器生命周期控制其启停：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
1. 添加依赖（Maven）
<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>
2. 启动受控 Ignite 容器节点
@Testcontainers
class IgniteFailureTest {
@Container
static GenericContainer> igniteNode = new FixedHostPortGenericContainer("apacheignite/ignite:2.16.0")
.withFixedExposedPort(10800, 10800) // Thin Client 端口
.withEnv("IGNITE_CONFIG_URL", "file:///opt/ignite/config/default-config.xml")
.withClasspathResourceMapping(
"test-ignite-config.xml",
"/opt/ignite/config/default-config.xml",
BindMode.READ_ONLY
);
@Test
void whenNodeCrashes_thenClusterRecoversGracefully() throws Exception {
// 1. 初始化客户端连接
IgniteClient client = Ignition.startClient(
ClientConfiguration.builder()
.setAddresses("localhost:10800")
.build()
);
// 2. 写入测试数据（触发分区分配）
try (ClientCache<integer string> cache = client.getOrCreateCache("test-cache")) {
cache.put(1, "value-1");
assertThat(cache.get(1)).isEqualTo("value-1");
}
// 3. ? 模拟突发宕机：直接终止容器（等效于 kill -9）
igniteNode.stop(); // 非优雅终止，无 shutdown hook，无心跳响应
// 4. 验证集群自愈行为（如：剩余节点检测失联、触发 rebalance、可用性检查）
await().atMost(30, SECONDS).untilAsserted(() -> {
ClusterNode localNode = client.cluster().localNode();
long aliveNodes = client.cluster().nodes().size();
assertThat(aliveNodes).isEqualTo(0); // 若仅此一节点，则集群为空；多节点场景下应 >0
});
}
}</integer>
? 提示：igniteNode.stop() 底层调用 docker stop --time=0，强制发送 SIGKILL，完全跳过 JVM 关闭钩子（Runtime.addShutdownHook）和 Ignite 生命周期事件（如 AFTER_NODE_STOP），精准复现“黑屏宕机”。
3. 进阶：注入网络异常（Toxiproxy）
配合 Testcontainers 的 Toxiproxy 模块，可进一步模拟更复杂的故障：
@Container
static ToxiproxyContainer toxiproxy = new ToxiproxyContainer();
@Container
static GenericContainer> igniteWithProxy = new GenericContainer("apacheignite/ignite:2.16.0")
.withExposedPorts(10800)
.dependsOn(toxiproxy);
// 创建代理链路，然后触发 network partition
ToxiproxyContainer.ContainerProxy proxy = toxiproxy.getProxy(igniteWithProxy, 10800);
proxy.toxics().latency("slow-down", ToxicDirection.UPSTREAM, 5000); // 延迟 5s
proxy.toxics().add("kill-connection", ToxicDirection.UPSTREAM, "timeout", Map.of("timeout", "1000")); // 主动断连
⚠️ 注意事项与最佳实践
- 配置一致性：确保容器内 Ignite 配置（如 TcpDiscoverySpi、ipFinder）与测试目标集群拓扑匹配（例如静态 IP 列表需包含其他测试节点地址）；
- 持久化影响：若启用原生持久化（DataStorageConfiguration），建议在测试容器中挂载临时卷并自动清理，避免状态残留；
- 日志可观测性：通过 igniteNode.followOutput(new Slf4jLogConsumer(logger)) 捕获容器日志，便于分析 Failed to send message、Topology change detected 等关键事件；
- 资源回收：务必使用 @Testcontainers + @Container 静态声明，确保容器在测试类结束时自动销毁，防止端口占用；
- 替代方案对比：若无法使用 Docker，可退而采用 ProcessBuilder 启动 ignite.sh 并调用 process.destroyForcibly()，但需自行管理配置文件路径、JVM 参数及端口冲突，维护成本显著升高。
综上，以容器为边界、以进程为故障单元，是当前 Apache Ignite 单元测试中模拟节点异常宕机最可靠、最标准化的工程实践。它不仅规避了 JVM 内部实现耦合风险，更使测试具备跨环境一致性，为构建高可用分布式系统提供坚实的质量保障。
