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

/**
 * 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） 的配置方法，通常用于集群协调、元数据存储、分布式锁、任务调度等内部功能。我们来逐行解析其含义和设计意图。

🧩 方法概览

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

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

🔧 逐行详解

CacheConfiguration cache = new CacheConfiguration();

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

cache.setName(CU.UTILITY_CACHE_NAME);

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

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

cache.setCacheMode(REPLICATED);

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

✅ 为什么用 REPLICATED？

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

cache.setAtomicityMode(TRANSACTIONAL);

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

✅ 为什么需要事务？

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

cache.setRebalanceMode(SYNC);

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

✅ 为什么用 SYNC？

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

⚠️ 对比：

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

cache.setWriteSynchronizationMode(FULL_SYNC);

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

✅ 为什么用 FULL_SYNC？

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

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

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

✅ 为什么用 Rendezvous？

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

cache.setNodeFilter(CacheConfiguration.ALL_NODES);

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

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

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

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

✅ 为什么优先？

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

cache.setCopyOnRead(false);

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

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

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

🎯 一句话理解

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

💡 补充知识

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

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