当前位置：首页 > news >正文

Apache Ignite 的对等类加载（Peer Class Loading, P2P Class Loading）机制

news 2025/7/31 19:18:29

这段内容是关于 Apache Ignite 的“对等类加载”（Peer Class Loading, P2P Class Loading）机制的详细说明。这是 Ignite 为了简化开发而设计的一个非常强大的功能，但同时也存在一些安全和性能上的考量。

下面我将用通俗易懂的语言 + 结构化解释 + 实际场景类比，帮你彻底理解这个机制的工作原理、配置方式、部署模式以及生产建议。

🎯 一、一句话理解：什么是 Peer Class Loading？

当某个节点（比如客户端）提交了一个任务（如计算、查询处理器），而其他节点（如服务端）没有这个类时，Ignite 会自动从“源头节点”把缺失的类传过去，让任务能正常执行。

✅ 类似于：“我写了个新功能，不用提前部署到所有服务器上，只要我在我的电脑上运行它，系统就会自动帮我把代码发到需要执行的服务器上。”

🔁 二、工作流程详解（以任务提交为例）

假设你有一个 客户端节点 A，向一个 服务端集群 B/C/D 提交了一个自定义任务 MyTask：

IgniteCompute compute = ignite.compute();
compute.run(new MyTask()); // MyTask 只在 A 上定义

如果没有 Peer Class Loading：

B/C/D 节点找不到 MyTask 类 → 抛出 ClassNotFoundException

有 Peer Class Loading 且启用后：

B/C/D 发现本地没有 MyTask 类；
向“源头节点 A”请求该类的字节码；
A 把 MyTask.class 发送给 B/C/D；
B/C/D 动态加载这个类并执行任务；
下次再用 MyTask，就不用再传了（已缓存）。

📌 关键点：

不用手动把 jar 包复制到每个节点；
修改代码后重启客户端即可，集群自动感知更新；
开发调试极其方便！

🧩 三、哪些类可以通过 P2P 加载？

Ignite 支持通过 P2P 加载以下用户自定义类：

类型	示例用途
✅ Compute Tasks / Jobs	自定义计算任务
✅ Query Transformers / Filters	自定义查询转换逻辑
✅ Stream Transformers / Receivers	数据流处理函数
✅ Entry Processors	原子性缓存操作（如 CAS）

⚠️ 注意：不支持 P2P 加载的类

缓存中的 Key 和 Value 类（必须提前部署或序列化）
第三方库（如 Jackson、Guava）——应预装

⚠️ 四、使用建议：避免非静态内部类和 Lambda

public class Outer {private int x = 10;// ❌ 错误：非静态内部类会引用外部类实例public void submit() {ignite.compute().run(() -> System.out.println(x)); // 捕获了 x}// ✅ 正确：静态类或独立类static class MyTask implements IgniteRunnable {@Override public void run() { ... }}
}

原因：

非静态内部类隐式持有外部类引用；
如果外部类不可序列化（如包含 Socket、Thread 等），传输时会失败；
Lambda 表达式在 Java 中也可能捕获上下文变量，导致序列化问题。

👉 最佳实践：使用 static class 或单独 .java 文件定义任务。

🔐 五、安全性警告：谁都能上传代码？！

Peer Class Loading 允许“任何能连接集群的客户端”上传任意代码到服务端执行！

这相当于：

“你给了一个访客一把螺丝刀，结果他可以随意拆装你的发动机。”

🚨 生产环境风险：

恶意用户上传病毒代码；
错误代码导致 OOM 或死循环；
版本混乱、资源冲突。

✅ 生产建议：

❌ 禁用 Peer Class Loading（peerClassLoadingEnabled=false）
✅ 改用 UriDeploymentSpi 预部署代码
或严格限制只有可信客户端可以接入集群（网络隔离、认证授权）

⚙️ 六、核心配置参数

<bean class="org.apache.ignite.configuration.IgniteConfiguration"><property name="peerClassLoadingEnabled" value="true"/><property name="deploymentMode" value="CONTINUOUS"/>
</bean>

参数	说明	默认值
`peerClassLoadingEnabled`	是否启用 P2P 类加载	`false`
`deploymentMode`	部署模式（见下节）	`SHARED`
`peerClassLoadingExecutorService`	用于类加载的线程池	默认线程池
`peerClassLoadingLocalClassPathExclude`	强制从 peer 加载的包名列表	null
`peerClassLoadingMissedResourcesCacheSize`	缓存“找不到的类”记录数量	100

🔄 七、三种部署模式（Deployment Mode）对比

模式	特点	适用场景
PRIVATE / ISOLATED	每个 master 节点有自己的类加载器；不同节点的同名类互不干扰	❌ 已废弃，仅兼容旧版本
SHARED（默认）	所有 master 节点共享类加载器（相同 user version 下）；类在最后一个 master 离开时卸载	一般生产环境
CONTINUOUS	类永不因 master 离开而卸载；仅当 user version 变化时才重新加载	高可用、常驻资源（如连接池）

📌 CONTINUOUS 模式的优势举例：

你想在服务端节点上维护一个数据库连接池：

@IgniteInstanceResource
private Ignite ignite;private static DataSource ds; // 希望只初始化一次@OnClassLoaded
public void init() {if (ds == null) {ds = createDataSource(); // 只创建一次}
}

使用 CONTINUOUS 模式：即使所有客户端断开，连接池依然存在；
使用 SHARED 模式：最后一个客户端退出 → 类卸载 → 连接池关闭 → 下次又要重建。

👉 所以 CONTINUOUS 更适合生产中长期运行的服务。

🧾 八、User Version（用户版本）与类卸载

问题：

如何强制让集群重新加载某个类？比如你改了代码，但不想重启整个集群。

解决方案：修改 User Version

Ignite 使用 userVersion 来判断是否需要重新部署类。

方法一：修改配置文件

在 META-INF/ignite.xml 中添加：

<bean id="userVersion" class="java.lang.String"><constructor-arg value="1"/> <!-- 改成 2 表示升级 -->
</bean>

方法二：修改启动脚本目录

默认脚本（ignite.sh）会读取 $IGNITE_HOME/config/userversion/userversion 文件中的内容作为版本号。

echo "2" > $IGNITE_HOME/config/userversion/userversion

📌 当 userVersion 改变时：

所有旧类被卸载；
新类被重新加载；
相关资源（如连接池）可被重新初始化。

🧱 九、第三方库处理建议

⚠️ 问题：
如果你的任务依赖 guava-30.jar，每次提交任务都会通过 P2P 传输几 MB 的库文件 → 效率极低！

✅ 正确做法：

将所有第三方库放入每个节点的 $IGNITE_HOME/libs/ 目录；
或加入 CLASSPATH；
这样 P2P 只传你自己写的少量代码，不传大 jar。

类比：不要每次送快递都把整座工厂搬过去，只送“新产品样品”。

✅ 十、总结：Peer Class Loading 的定位

维度	说明
✅ 优点	开发调试极其方便，无需手动部署代码
❌ 缺点	安全性低、性能开销大、不适合生产
🛠️ 推荐用途	本地开发、测试环境
🔒 生产建议	关闭 P2P 加载，改用 `UriDeploymentSpi` 或容器化预部署

🧩 类比理解（生活例子）

比喻	技术对应
律师远程开庭，临时把证据材料发给法官	客户端发送任务类给服务端
法官收到材料后当庭审理	服务端加载类并执行任务
下次同一案件开庭，不用再发材料	类已加载，无需重复传输
但如果材料造假 → 被驳回甚至追责	恶意代码被拦截或导致系统崩溃
正规流程应提前提交案卷归档	预先部署 jar 包到所有节点