Ignite 内部系统级缓存（Utility System Cache）

java 复制代码

/**
 * Creates utility system cache configuration.
 *
 * @return Utility system cache configuration.
 */
private static CacheConfiguration utilitySystemCache() {
    CacheConfiguration cache = new CacheConfiguration();

    cache.setName(CU.UTILITY_CACHE_NAME);
    cache.setCacheMode(REPLICATED);
    cache.setAtomicityMode(TRANSACTIONAL);
    cache.setRebalanceMode(SYNC);
    cache.setWriteSynchronizationMode(FULL_SYNC);
    cache.setAffinity(new RendezvousAffinityFunction(false, 100));
    cache.setNodeFilter(CacheConfiguration.ALL_NODES);
    cache.setRebalanceOrder(-2); //Prior to user caches.
    cache.setCopyOnRead(false);

    return cache;
}

这是一个用于创建 Ignite 内部系统级缓存（Utility System Cache） 的配置方法，通常用于集群协调、元数据存储、分布式锁、任务调度等内部功能。我们来逐行解析其含义和设计意图。

🧩 方法概览

java 复制代码

private static CacheConfiguration utilitySystemCache() {
    // 创建并返回一个专用于系统内部功能的缓存配置
}

这个缓存不是给用户业务数据用的，而是 Ignite 内核自己使用的"系统工具缓存"。

🔧 逐行详解

java 复制代码

CacheConfiguration cache = new CacheConfiguration();

创建一个空的缓存配置对象。

java 复制代码

cache.setName(CU.UTILITY_CACHE_NAME);

设置缓存名称 ：使用常量 CU.UTILITY_CACHE_NAME（通常是 "ignite-sys-cache" 或类似名称）。
这个名字是固定的，让 Ignite 内部组件知道这是"系统工具缓存"。

📌 CU 是 GridCacheUtils 的缩写，一个内部工具类。

java 复制代码

cache.setCacheMode(REPLICATED);

缓存模式：REPLICATED（复制模式）
✅ 每个节点都保存完整的数据副本。
⚠️ 适合小数据量、高频访问、强一致性的场景（如集群配置、锁信息）。
❌ 不适合大数据量（会浪费内存）。

✅ 为什么用 REPLICATED？

系统元数据需要快速本地访问，不能每次都跨网络查询。
高可用：任意节点都能独立读取元数据。

java 复制代码

cache.setAtomicityMode(TRANSACTIONAL);

原子性模式：事务型（TRANSACTIONAL）
支持 ACID 事务 （put, remove 等操作可参与事务）。
保证多个键的更新具有原子性。

✅ 为什么需要事务？

系统操作可能涉及多个元数据项的更新（如：分配任务 + 更新状态），必须要么全部成功，要么全部回滚。

java 复制代码

cache.setRebalanceMode(SYNC);

再平衡模式：同步（SYNC）
当节点加入/离开时，缓存数据重新分布（rebalance）期间，写操作会被阻塞，直到再平衡完成。
保证在整个过程中数据一致性最强。

✅ 为什么用 SYNC？

系统缓存的数据非常关键（如锁、协调状态），不能容忍短暂的不一致。
宁可暂停写入，也不能出错。

⚠️ 对比：

ASYNC：异步再平衡，性能好但短暂不一致。
NONE：不 rebalance（仅适用于 REPLICATED 缓存，但这里显式指定 SYNC 更安全）。

java 复制代码

cache.setWriteSynchronizationMode(FULL_SYNC);

写同步模式：完全同步（FULL_SYNC）
每次写操作（put/delete）必须等到所有备份节点都完成写入后才返回成功。
提供最强的数据持久性和一致性保证。

✅ 为什么用 FULL_SYNC？

系统数据不能丢失，哪怕节点宕机也要确保已提交的数据存在。
牺牲性能换取可靠性。

java 复制代码

cache.setAffinity(new RendezvousAffinityFunction(false, 100));

设置分区函数：Rendezvous 哈希（又名 Highest Random Weight - HRW）
参数说明：
- false：是否启用备份节点的"备份过滤"（这里禁用）。
- 100：虚拟节点（replicas）数量，用于提高哈希分布的均匀性。

✅ 为什么用 Rendezvous？

虽然是 REPLICATED 缓存，但 AffinityFunction 仍然用于：
- 决定"哪个节点是主节点"（primary for key）。
- 用于某些协调操作（如 leader 选举、分布式 ID 生成等）。
Rendezvous 简单、均匀、再平衡开销小。

java 复制代码

cache.setNodeFilter(CacheConfiguration.ALL_NODES);

节点过滤器：所有节点都参与该缓存
没有部署限制，每个集群节点都会持有这个系统缓存的实例。

✅ 因为是系统级功能，必须全员参与。

java 复制代码

cache.setRebalanceOrder(-2); // Prior to user caches.

再平衡顺序：-2（优先于用户缓存）
当集群启动或节点加入时，缓存的再平衡有执行顺序：
- 数值越小，优先级越高。
- -2 表示：先于大多数用户缓存（通常是 0 或正数）进行再平衡。

✅ 为什么优先？

系统缓存包含集群协调数据（如节点列表、任务路由），必须先就绪，其他用户缓存和服务才能正常启动。

java 复制代码

cache.setCopyOnRead(false);

关闭"读时复制"
如果为 true，每次 get(key) 会返回值的一个副本，防止用户修改缓存内部对象。
false 表示直接返回引用，性能更高，但要求用户（这里是系统代码）不要修改返回的对象。

✅ 系统内部使用可控，关闭以提升性能。

📌 总结：这个缓存是干什么的？

特性	说明
用途	存储 Ignite 集群的系统级元数据和协调数据，如： • 分布式事件/消息 • 任务映射 • 分布式锁 • WAL 检查点协调 • 内部服务注册
模式	`REPLICATED`：所有节点都有完整副本，读取极快
一致性	`TRANSACTIONAL + FULL_SYNC + SYNC`：最强一致性，牺牲性能保正确性
优先级	`rebalanceOrder=-2`：启动时优先恢复，支撑其他服务
访问控制	内部专用，用户代码不应直接操作

🎯 一句话理解

这是一个为 Ignite 内核服务量身定制的高可靠、强一致、全复制系统缓存，它像集群的"神经系统"一样，承载着节点协调、事务控制、任务调度等关键元数据，因此配置了最严格的同步和事务保障，并在启动时优先初始化，确保整个集群能正确协作。

💡 补充知识

Ignite 有多个系统缓存，如：
- ignite-sys-cache（Utility Cache）
- ignite-atomics（分布式原子变量）
- ignite-metas（SQL 元数据）
用户不应创建名为 ignite-* 的缓存，避免冲突。
这种配置绝不适用于业务数据------太重、太慢，只适合小规模系统数据。

如果你看到这个方法，说明你正在阅读 Ignite 内部源码（如 GridCacheProcessor），它揭示了 Ignite 如何构建一个可靠的分布式基础。