1. 项目整体设计与技术选型思路1.1 为什么不是 Redis而是 Apache Ignite聊到分布式缓存很多人的第一反应是 Redis。确实Redis 在缓存领域统治了很多年简单、成熟、生态好单机吞吐量极高。但我这次在项目里遇到的情况比较特殊——不只是要缓存还要在数据边上做分布式计算而且数据量到了 TB 级别之后Redis 的主从复制和内存成本就很尴尬了。我当时的业务场景是一套多节点部署的数据分析平台后端用的 Spring Boot 2.7最近在调研 Spring Boot 4 的迁移后面细说业务方要求基础配置数据能毫秒级访问同时对一批存量数据进行批量分组聚合计算计算量不小而且要求计算过程中数据不能频繁走网络 IO 往返。用 Redis 的方案其实能走通热点数据放 Redis计算放应用层节点之间共享数据。但问题是当计算任务涉及多个节点上的数据时你要么把数据从一个节点搬到另一个节点要么引入额外的消息中间件来协调整个架构链路拉得很长排查问题的时候非常痛苦。后来我重新审视了 Apache Ignite。它本质上是一个分布式内存计算平台数据以 key-value 或 SQL 表的形式分布在集群各节点上同时能直接在数据所在节点执行计算逻辑这种亲和性计算能力是 Redis 不能直接给到你的。我来说一个直观差异同样是做“对全量用户按省份分组求和”用 Redis 你得把所有原始数据拉回应用层自己聚合数据量大了之后网络开销直接要命用 Ignite 你可以把计算任务发给数据所在的节点并行执行最后只汇总一个很小的结果集。这个差别在数据量大时是数量级的性能差距。1.2 架构定位Ignite 在 Spring Boot 体系中扮演什么角色经过几轮技术预研我最终把 Ignite 定位成三个角色第一是分布式缓存层。替代原先的单机 Caffeine 缓存和多级缓存中不太稳定的 Redis 部分所有节点共享同一份数据视图配置变更后所有服务节点能几乎同时看到新值。第二是分布式计算引擎。SQL 聚合、MapReduce 类型的任务直接在 Ignite 集群内执行业务服务只提交任务、接收结果不需要关心数据在哪台机器上。第三是持久化存储的加速层。Ignite 原生支持持久化对于非核心业务数据可以直接把 Ignite 当主存储用省掉一层外部数据库依赖。我这里没有激进到这种程度核心数据仍然放在 PostgreSQL但耗时严重的统计报表场景已经把数据同步进 Ignite 跑计算了。这个架构选型有个特别重要的前提——Ignite 不是要替代你现有的关系型数据库而是在 Spring Boot 应用和数据库之间加一个分布式的数据与计算层让读多写少的数据访问和计算密集型任务能卸载到内存集群中。这一点想清楚之后后面怎么设计缓存键、怎么同步数据、怎么处理一致性思路就不会乱。1.3 整体落地路径从 POC 到生产环境的三个里程碑我不是一开始就上全套方案而是拆成了三个阶段第一个里程碑是“跑通”。Spring Boot 项目里引入 Ignite 依赖启动一个嵌入式 Ignite 节点验证数据读写、基本缓存能力、Spring Cache 注解能否正常工作。这个阶段的目标是把技术链路打通不追求性能。第二个里程碑是“集群化”。把 Ignite 从嵌入式模式切换到独立集群模式Spring Boot 服务作为客户端接入集群。这个阶段要验证节点发现、数据分区、故障转移这些分布式特性是否按预期工作。第三个里程碑是“上计算”。把业务中的分组聚合、去重统计、批量更新场景迁移到 Ignite 的计算 API 上配合亲和性配置让计算逻辑在数据节点本地执行最后对比性能数据和资源消耗。三个阶段走下来最大的感受是Ignite 集成本身并不难难的是想清楚你的数据结构怎么映射到 Ignite 的缓存模型上、计算任务怎么写才能利用亲和性以及集群失败时业务怎么兜底。2. 环境准备与核心依赖配置2.1 版本选型Spring Boot 2.7 与 Ignite 2.15 的兼容性版本这关我踩的坑不算少。建议直接上 Ignite 2.15 或更高版本对应 JDK 8 和 Spring Boot 2.x 都比较稳。Ignite 2.15 对分布式计算和 SQL 的支持已经很成熟缓存 API 也稳定不会出现什么幺蛾子。如果你和我一样在关注 Spring Boot 4 的迁移那要特别注意Spring Boot 4 基于 Spring Framework 7Jakarta EE 命名空间已经全面切换Ignite 官方对 Spring Boot 4 的集成支持目前还不是特别完善。很多老项目从 Spring Boot 3 升级到 4 时遇到 DataSourceAutoConfiguration 找不到的问题本质上是 Spring Boot 4 重构了自动配置注册机制。Ignite 的 spring-boot-starter 依赖还是面向 Spring Boot 2/3 体系设计的所以建议生产环境先停留在 Spring Boot 2.7 或 3.x等 Ignite 社区跟进。Maven 依赖我放到这里这是最基础的版本dependency groupIdorg.apache.ignite/groupId artifactIdignite-core/artifactId version2.15.0/version /dependency dependency groupIdorg.apache.ignite/groupId artifactIdignite-spring/artifactId version2.15.0/version /dependency dependency groupIdorg.apache.ignite/groupId artifactIdignite-indexing/artifactId version2.15.0/version /dependency dependency groupIdorg.apache.ignite/groupId artifactIdignite-rest-http/artifactId version2.15.0/version /dependencyignite-indexing 是必须的否则 SQL 查询和计算任务里依赖索引的功能无法使用。ignite-rest-http 是方便我用 REST API 做集群监控和调试的非必需但很推荐加上。2.2 配置文件详解从本机到集群的配置演进我的 Ignite 配置不是写死在代码里的而是通过 Spring Boot 的 application.yml 外置这样不同环境开发、测试、生产能复用同一套代码。先看最基础的配置类Configuration public class IgniteConfig { Bean public Ignite igniteInstance() { IgniteConfiguration cfg new IgniteConfiguration(); cfg.setIgniteInstanceName(my-ignite-cluster); cfg.setPeerClassLoadingEnabled(true); // 发现机制先用组播生产环境建议换 ZooKeeper 或 TcpDiscovery TcpDiscoveryMulticastIpFinder ipFinder new TcpDiscoveryMulticastIpFinder(); ipFinder.setAddresses(Arrays.asList(127.0.0.1:47500)); TcpDiscoverySpi discoSpi new TcpDiscoverySpi(); discoSpi.setIpFinder(ipFinder); cfg.setDiscoverySpi(discoSpi); // 持久化配置 DataStorageConfiguration storageCfg new DataStorageConfiguration(); DataRegionConfiguration regionCfg new DataRegionConfiguration(); regionCfg.setName(persistent-region); regionCfg.setPersistenceEnabled(true); storageCfg.setDefaultDataRegionConfiguration(regionCfg); cfg.setDataStorageConfiguration(storageCfg); // 缓存配置这里用编程式方便动态调整 CacheConfigurationObject, Object cacheCfg new CacheConfiguration() .setName(user-cache) .setCacheMode(CacheMode.PARTITIONED) .setBackups(1) .setWriteSynchronizationMode(CacheWriteSynchronizationMode.PRIMARY_SYNC); cfg.setCacheConfiguration(cacheCfg); return Ignition.start(cfg); } }这里有几个关键参数我要解释一下因为默认值在生产环境经常不够用。CacheMode.PARTITIONED 表示数据按 key 的哈希分布到不同节点这是分布式缓存的主流模式。backups 设置每个分区的副本数生产环境至少 1保证任意节点宕机数据不丢。WriteSynchronizationMode.PRIMARY_SYNC 表示写操作只需要主节点确认完成性能较好但如果你对数据一致性要求极高可以改成 FULL_SYNC。还要注意持久化开关。Ignite 默认是纯内存模式节点重启数据就没了。如果你需要把缓存数据落地到磁盘必须显式开启 PersistenceEnabled同时指定存储路径否则重启后 Eclipse 集群里的数据需要重新从上游加载这在生产环境是致命的。2.3 Spring Boot 自动配置与 Ignite 的整合方式这里我推荐三种整合方式分别对应不同场景。第一种是纯编程式就像上面写的手动创建 Ignite 实例并注册为 Spring Bean。这种方式的优点是配置完全可控适合需要动态调整缓存参数、按环境切换集群模式的场景。第二种是通过 Ignite 的 spring-boot-starter 自动配置。Ignite 官方提供了 ignite-spring-boot-starter 依赖项目启动后自动创建 Ignite 实例只需在 application.yml 里配置即可。这种方式初始化快、代码少但如果你在多个服务里共享同一个集群要注意实例名冲突的问题。第三种是 Spring Cache 抽象集成。这是最偷懒但最可维护的方式。用 Cacheable、CacheEvict 这类注解底层换成 IgniteCacheManagerBean public CacheManager cacheManager(Ignite ignite) { return new IgniteCacheManager(ignite); }之后在 Service 里就可以用 Spring Cache 注解Service public class UserService { Cacheable(value user-cache, key #userId) public User getUserById(Long userId) { // 数据库查询逻辑 return userMapper.selectById(userId); } }这种方式的优点是业务代码里不出现 Ignite 的 API后续要换缓存实现只需要换掉 CacheManager 的配置类。缺点是 Spring Cache 抽象只覆盖了缓存读写分布式计算和高级 API 还是要直接调用 Ignite 的原生接口。我的建议是缓存走 Spring Cache 抽象计算和需要细粒度控制的场景走原生 API两条腿走路。3. 核心模块实现分布式缓存的实战配置3.1 缓存键设计与序列化策略缓存设计里缓存键是容易翻车的地方。我第一次直接把业务对象的 toString() 当 key结果对象字段顺序一变、toString 实现一改所有缓存全部失效而且定位问题很痛苦。后来我养成了显式定义缓存键类的习惯。推荐使用 Apache Ignite 自带的 BinaryObject 机制或者用 Java 原生序列化但要注意 Ignite 的默认序列化方式是 Java 原生序列化跨语言调用的场景会出现大量兼容性问题。我这里实际采用的是 Ignite 的 BinaryMarshaller并对关键缓存键定义了统一的 Key 类public class UserCacheKey implements Serializable { private Long userId; private String region; public UserCacheKey(Long userId, String region) { this.userId userId; this.region region; } Override public boolean equals(Object o) { if (this o) return true; if (o null || getClass() ! o.getClass()) return false; UserCacheKey that (UserCacheKey) o; return Objects.equals(userId, that.userId) Objects.equals(region, that.region); } Override public int hashCode() { return Objects.hash(userId, region); } }缓存键必须同时重写 equals 和 hashCode这是 Ignite 做数据分区和去重的基础。如果你用了 Lombok 的 Data它会自动生成这两个方法但要注意如果你加了额外字段分区可能不均衡。序列化这一块我的经验是不要用 Java 原生序列化跨版本发布。Ignite 支持配置 Kryo 或自定义 Marshaller我最后选了 Kryo序列化速度快、生成的字节更小。你可以通过配置 IgniteConfiguration 的 Marshaller 属性替换默认实现。3.2 缓存过期策略与内存规划缓存过期的坑主要在于“缓存空值”和“缓存雪崩”。我在一个统计接口上吃过亏查询某天的汇总数据结果数据库里没记录返回 null结果 Cacheable 默认不缓存 null 值导致每次请求都穿透到数据库。解决办法有两个思路一是把 null 值包装成一个空对象缓存起来二是设置较短的过期时间。我选择了空对象包装方案因为既能防穿透又不需要频繁重建缓存。Cacheable(value summary-cache, key #date, unless #result null) public DailySummary getDailySummary(String date) { DailySummary summary summaryMapper.selectByDate(date); if (summary null) { summary new DailySummary(); // 空对象占位 } return summary; }关于过期策略Ignite 支持基于时间的过期。我在配置里用了 expireAfterWrite也就是写入后固定时长过期这种模式适合大多数业务缓存CacheConfigurationObject, Object cacheCfg new CacheConfiguration() .setName(summary-cache) .setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(Duration.ofMinutes(30))) .setCacheMode(CacheMode.PARTITIONED) .setBackups(1);这里要特别注意setExpiryPolicyFactory 配的是 CreatedExpiryPolicy即从创建时间开始计时30 分钟后过期。如果你想要访问后自动续期比如带活跃度的会话缓存需要用 AccessedExpiryPolicy。内存规划是很多人忽略的点。Ignite 集群的内存是有限的如果所有缓存无限制扩容最终会导致 OOM。DataStorageConfiguration 里可以给每个 DataRegion 设置初始大小和最大大小超过最大值的部分由 Ignite 根据 page replacement 策略淘汰。我给的参考配置是给持久化数据区分配内存的 60%给临时数据区比如计算过程中的中间结果分配 20%剩下 20% 作为 JVM 堆外内存留给操作系统和 Ignite 内部管理。3.3 写一致性从 PRIMARY_SYNC 到 FULL_SYNC 的取舍分布式缓存写一致性的问题本质上就是 CAP 理论中的 CP 和 AP 权衡。Ignite 提供了多种写同步模式默认是 FULL_ASYNC主节点和备份节点都异步写性能最好但可能丢数据。项目里我给核心的账户缓存设置了 PRIMARY_SYNC客户端发出写操作后只要主节点写成功就返回成功备份节点异步同步。这种模式在性能和一致性之间取了平衡我们的业务可以接受极端的副本短暂不一致。如果你做的是金融类或库存类的强一致场景必须用 FULL_SYNC同时配合 Ignite 事务 API。注意 Spring Cache 注解默认是不开启事务的缓存的原子性需要你自己控制。一个经验是缓存和数据库的一致性不能靠缓存自身实现要绕到业务层面用“先更新数据库再失效缓存”或者“订阅 binlog 异步更新缓存”的方式。3.4 缓存预热与批量加载项目启动时如果所有缓存都是空的第一个用户请求就要穿透到数据库出现一次明显的“冷启动延迟”。我踩过一次后写了缓存的预热逻辑在 Spring Boot 的 ApplicationReadyEvent 事件里执行Component public class CacheWarmer { private final Ignite ignite; public CacheWarmer(Ignite ignite) { this.ignite ignite; } EventListener(ApplicationReadyEvent.class) public void warmUp() { IgniteCacheString, Object cache ignite.cache(user-cache); // 从数据库加载最近7天的活跃用户批量写入缓存 ListLong activeUserIds userMapper.selectActiveUserIds(7); MapString, Object batch new HashMap(); for (Long userId : activeUserIds) { batch.put(buildKey(userId), userMapper.selectById(userId)); } cache.putAll(batch); } }批量写入时如果用 putAll 而不是循环 put性能差距非常明显。Ignite 对批量操作有内部优化减少了大量的网络往返。缓存预热要注意时序如果 Ignite 还没完全启动或者数据库连接池还没初始化预热代码就会报错。所以要监听 ApplicationReadyEvent这个事件是 Spring Boot 上下文完全启动后触发的这时候所有 Bean 和基础资源都已经就绪。4. 分布式计算从业务痛点出发的实现方案4.1 Ignite Compute API 的调用模式分布式计算模块是这次项目中我最满意的部分。业务场景是做用户行为分析按照用户 ID 分组统计行为次数和金额。数据量约 2 亿条分布在 4 台 64G 内存的服务器上。如果用传统方式服务端把 2 亿条数据取出来传输到应用层进行分组聚合内存立刻爆掉网络带宽也会被打满。用 Ignite 的 Compute API可以把聚合逻辑送到每台节点上在每个数据分片上执行本地聚合最后合并结果。这个模式的调用代码如下IgniteCompute compute ignite.compute(); // broadcast: 在所有节点上执行同一个任务 compute.broadcast(() - { System.out.println(Executing on: ignite.cluster().localNode().id()); }); // 自定义任务: 发送到指定节点集合执行支持负载均衡和故障转移 IgniteRunnable task () - { // 计算逻辑 }; compute.affinityCall(user-cache, userId, task);Ignite 的计算任务支持多种语义broadcast 广播给所有节点affinityCall / affinityRun 把任务发送到某个 key 所在节点execute 提交给节点池按负载均衡策略选择一个节点执行。实际项目里我主要用的是 affinityRun它能把针对特定用户的处理逻辑搬到该用户数据所在的节点上执行真正做到了数据本地化避免了跨节点搬迁数据。4.2 数据亲和性与 Colocation 设计分布式计算的核心技巧是数据亲和性也就是 Colocation。简单说如果你在处理“用户 A 的所有订单记录”这些订单记录最好与用户 A 的基本信息存储在同一个节点上这样计算时不需要跨节点拉数据。在 Ignite 里实现亲和性有两种方式第一种是 AffinityKey。在缓存配置CacheConfigurationAffinityKeyLong, Order orderCacheCfg new CacheConfiguration() .setName(order-cache) .setCacheMode(CacheMode.PARTITIONED) .setBackups(1);写入时用 AffinityKeyAffinityKeyLong key new AffinityKey(orderId, userId); cache.put(key, order);第二种是基于 SQL 的 CREATE TABLE用 AFFINITY_KEY 指定关联字段。我实际采用的是第一种方式因为数据模型是 Java 对象用代码控制亲和性更直观。AffinityKey 的构造参数里第一个是实际主键第二个是亲和性键Ignite 会按照亲和性键的哈希值决定这个 key 存储在哪台节点上。设计亲和性时要遵循一个原则同一业务实体关联的数据必须使用同一个亲和性键。比如订单和用户都以 userId 作为亲和性键这样某用户的所有订单必然与用户基本信息在同一节点上。这样后续计算该用户的订单总金额时job 只需要发送到一个节点即可执行完毕不需要广播。4.3 聚集器与分布式任务拆分实战接下来我们看一个真实的分布式计算场景统计全平台每天按用户分组的行为聚合结果。如果直接用简单遍历数据量大了之后性能极差所以需要把它拆成分散到各节点的子任务再用 Ignite 的累加器合并结果。Ignite 提供了 IgniteAtomicLong 和 IgniteAccumulator 用于集群范围内的数值聚合。我们在多个节点上执行计数的场景这个特性非常好用IgniteAtomicLong totalCounter ignite.atomicLong(total-counter, 0, true); compute.broadcast(() - { long localCount performLocalAggregation(); totalCounter.addAndGet(localCount); });AtomicLong 在集群里是分布式的底层通过原子操作在不同节点间同步。要注意设置 create 参数为 true否则第一次调用时如果原子量不存在会直接报错。对于更复杂的逻辑我用到了 Ignite 的 ComputeTask 接口。定义好任务拆分逻辑和结果合并逻辑public class GroupSumTask extends ComputeTaskSplitAdapterString, MapString, Long { Override protected Collection? extends ComputeJob split(int gridSize, String arg) { // 按节点拆分任务 ListComputeJob jobs new ArrayList(); for (int i 0; i gridSize; i) { jobs.add(new GroupSumJob(arg)); } return jobs; } Override public MapString, Long reduce(ListComputeJobResult results) { // 合并各节点的局部结果 MapString, Long merged new HashMap(); for (ComputeJobResult res : results) { MapString, Long partial res.getData(); partial.forEach((k, v) - merged.merge(k, v, Long::sum)); } return merged; } }SplitAdapter 模式很好理解split 阶段把任务按节点拆成子任务每个子任务在对应节点执行reduce 阶段把各节点返回的部分结果合并成最终结果。每个 ComputeJob 内部就是普通的 Java 逻辑但运行在数据所在节点上可以访问本地缓存数据。这个模式的关键点是“子任务里访问本地数据”因为 Ignite 的缓存 API 可以保证如果 key 的亲和性与当前节点匹配那么 get 操作走的是本地堆而不是远程网络调用。这一点写代码时要刻意注意别把 get 写成了远程提交流程。4.4 SQL 计算模式与注意事项Ignite 还有一个非常强的能力——分布式 SQL。你可以像操作普通数据库一样操作缓存中的对象数据Ignite 会把 SQL 语句自动分发给对应节点执行。引入 ignite-indexing 后在实体类上配置注解QuerySqlField(index true) private Long userId; QuerySqlField private BigDecimal amount;然后直接用 SQLIgniteCacheAffinityKeyLong, Order orderCache ignite.cache(order-cache); SqlFieldsQuery query new SqlFieldsQuery( SELECT userId, SUM(amount) FROM Order GROUP BY userId ); try (QueryCursorList? cursor orderCache.query(query)) { for (List? row : cursor) { // 处理聚合结果 } }这条 SQL 会触发 Ignite 内部的分布式 SQL 引擎在数据所在节点并行聚合然后把中间结果汇总到发起节点。性能非常可观2 亿条数据的分组聚合在我的 4 节点集群上大约 20 秒出结果相比之前的应用层内存聚合提升了接近一个数量级。SQL 计算有几个坑要注意一是设置索引。GROUP BY 涉及的字段必须建索引否则全表扫描性能完全没法看。二是结果集大小。如果聚合结果很大比如分组粒度很细最终结果可能也很大传输到发起节点时会有网络开销。这种情况下建议再分一层聚合或者直接用 Ignite 的 MapReduce 模式把最终结果也分散存储只返回结果的摘要信息。三是 SQL 查询里不要写 OR 条件Ignite 的 SQL 优化器对这种复杂条件支持不好很容易退化成全表扫描。5. 性能调优与高可用配置5.1 JVM 参数与堆外内存分配第一次部署 Ignite 集群的时候我以为默认配置就行结果上线第二天就遇到了频繁的 Full GC。原因很简单——Ignite 把大部分数据都放在堆外如果 JVM 堆设置得太小而 Ignite 内部又要用堆内存做对象封装和协调两者一叠加就悲剧了。我后来总结了一套相对稳妥的 JVM 参数组合给的是 32G 堆的参考配置-server -Xms32g -Xmx32g -XX:AlwaysPreTouch -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:HeapDumpOnOutOfMemoryError -XX:ExitOnOutOfMemoryErrorAlwaysPreTouch 的作用是启动时就把内存占好避免运行期频繁向操作系统申请内存引起性能抖动。G1GC 默认就可以那个 MaxGCPauseMillis200 是控制 GC 停顿时间的目标值。Ignite 的 DataStorageConfiguration 里可以设置堆外内存区域大小DataRegionConfiguration regionCfg new DataRegionConfiguration(); regionCfg.setName(persistent-region); regionCfg.setInitialSize(20L * 1024 * 1024 * 1024); // 20G regionCfg.setMaxSize(30L * 1024 * 1024 * 1024); // 30G regionCfg.setPersistenceEnabled(true);这里有个经验值堆外内存最大值不能超过物理内存的 70%否则操作系统都会进入内存压力状态。比如 64G 物理机的节点堆外最多给 45G剩余留给了 JVM 堆和系统缓存。5.2 集群发现机制从组播到 ZooKeeperIgnite 的节点发现机制默认使用组播Multicast开发环境很好用机器一启动就能自动加入集群。但生产环境组播在很多云环境下是不通的而且新节点加入时偶尔会出现发现延迟。我最后换成了 ZooKeeper 做集群发现和协调。这个选择的好处是稳定的服务注册节点不需要额外配置网络组播而且集群规模扩展时不会因为组播通信变化出现节点失联。TcpDiscoveryZooKeeperIpFinder ipFinder new TcpDiscoveryZooKeeperIpFinder(); ipFinder.setZkConnectionString(10.0.0.1:2181,10.0.0.2:2181,10.0.0.3:2181); TcpDiscoverySpi discoSpi new TcpDiscoverySpi(); discoSpi.setIpFinder(ipFinder); cfg.setDiscoverySpi(discoSpi);换 ZooKeeper 后发现的一个好处是集群成员的加入和退出情况都能通过 ZooKeeper 的临时节点感知到Ignite 对集群变化的响应时间从秒级压缩到了毫秒级。生产环境不建议用 Ignite 内嵌的 TcpDiscoveryMulticastIpFinder 配合组播除非你的网络环境能保证组播可用且低延迟。另外如果有条件Ignite 2.8 之后还支持了基于 K8s 的 IP Finder部署在 Kubernetes 里的集群可以直接用它和 Pod 生命周期对齐。5.3 持久化与 WAL 配置的实测调优设置 PersistenceEnabled 之后Ignite 用预写日志WAL保证数据安全。刚开启持久化时我跑了一天的数据后发现磁盘占用高得出奇排查下来是 WAL 归档不断累积而且我没有设置自动清理策略。后来我调整了 WAL 配置这里是一组实测下来比较稳的参数DataStorageConfiguration storageCfg new DataStorageConfiguration(); WalConfiguration walCfg storageCfg.getWalConfiguration(); walCfg.setWalMode(WALMode.LOG_ONLY); walCfg.setWalHistorySize(2000); walCfg.setWalSegmentSize(64 * 1024 * 1024);WALMode.LOG_ONLY 表示只写日志不强制每次都将数据同步到数据文件。这个模式对性能更友好但前提是磁盘不能挂掉。如果你对数据安全要求极其严格可以改成 FSYNC 模式但写入性能会下降 30% 左右。WALHistorySize 是控制 WAL 历史记录保留数量的参数太小会导致 checkpoint 频繁触发太大磁盘空间会爆炸。2000 个 segment、每个 64MB 大小实际运行下来大约占 128G 磁盘空间迭代开发环境可以把这个值调小一些。磁盘空间不足是很常见的问题。我用脚本定时监控每个节点的 WAL 目录和持久化文件目录超过 85% 后自动清理老旧的归档日志。这个运维策略虽然简单但帮我避免了两次因为磁盘爆满导致的集群写入故障。5.4 监控指标与告警不靠猜靠数据分布式的排障最难的就是看不见。Ignite 提供了一套完整的监控 API你也可以通过 JMX 暴露指标接入 Prometheus 和 Grafana。我重点监控这几个指标指标含义告警阈值PartitionState分区状态是否健康非OWNING状态立即告警NumberOfEntriesInMemory内存中的数据条目数接近 maxSize 判断扩容TotalAllocatedSize物理内存占用超过物理内存 80% 告警CurrentWalArchiveSizeWAL 归档大小超过阈值触发清理告警CacheEntriesPagedOut数据被换出内存的页数持续增长说明内存不足AverageQueryTimeSQL 平均执行时间超过 1s 报警这些指标通过 Ignite 的 MXBean 暴露出来我写了一个定时任务抓取并同步到监控系统。实测下来最有预判价值的是 CacheEntriesPagedOut这个指标一旦持续增长基本说明内存规划不合理数据被频繁换出内存性能断崖下跌。另外Ignite Visor 是一个挺好的命令行监控工具可以对 Ignite 集群节点执行各种管理命令比如查看缓存大小、节点状态、执行 SQL 查询等。生产维护时有它在手比直接连 JMX 方便很多。6. 踩坑实录高频问题的定位思路与解决模板6.1 节点启动后互不可见组播发现失效或者 ZooKeeper 连接串配错最容易出现的现象是单独启动的第一个节点一切正常第二个节点启动后却始终加入不了集群日志里反复出现连接超时。排查思路分两步走。第一步检查网络和端口Ignite 默认通信端口是 47100发现端口是 47500这两个端口必须能被其他节点访问。第二步检查发现配置如果你用的是 ZooKeeper确认 zk 连接串没有写错确认所有节点连接的是同一个 ZK 集群如果你用的是组播在机器上执行 tcpdump 抓包确认组播报文能正常到达目标节点。我的一个经验是配置日志级别为 DEBUG 再启动节点Ignite 的日志会输出很详细的节点发现全过程。根据日志里的提示定位基本不会超过十分钟。6.2 缓存查询超时与 OOM缓存查询超时大概率是缓存键设计不合理导致同一个 key 被集中写入同一台节点集群负载严重不均。可以用 Ignite 的 Visor 查看各节点缓存分区的分布情况如果某个节点的内存占用明显高于其他节点就要检查 key 的哈希是否均匀。OOM 的常见原因是内存规划没做好。我遇到过最典型的场景是持久化区设置了 30G但导入的数据量远超预期Ignite 只好不断把旧页换出内存表现为大量的磁盘 IO 和 CacheEntriesPagedOut 指标暴涨。解决方案要么扩容 DataRegion要么调整数据保留策略。另一种 OOM 出现在计算任务上某个节点的任务无限制地向缓存写入中间结果结果内存区的最大值被击穿。这种场景建议给临时数据单独建一个 DataRegion设置较小的 maxSize并开启 LRU 淘汰。6.3 亲和性配置不生效写好的 affinityRun 任务运行日志却显示它被路由到了别的节点数据却要从远端节点拉取。这个问题的根源是affinityRun 方法是根据你提供的 key 去定位节点的但这个 key 必须与缓存的 AffinityKey 一致。比如订单缓存用的 AffinityKey(orderId, userId)你计算时传的 key 也必须是 AffinityKey(orderId, userId)而不能只是 orderId。如果只用 orderIdIgnite 会按 orderId 的哈希路由节点而订单数据是按 userId 的哈希分布的两者可能落到不同节点上亲和性自然失效。这个问题排查起来很隐蔽因为代码不会报错只是性能不对。我的经验是写一个单元测试往一个缓存里写入一万个键值对然后分别用 affinityCall 和普通 call 访问同一批 key对比耗时差异。如果 affinityCall 没有明显优势说明亲和配置有问题。6.4 缓存数据与数据库数据不一致分布式缓存最头疼的问题就是数据一致性。我遇到过这样的场景管理后台直接改了数据库中的配置但缓存里的旧值还在业务服务一直读到旧数据持续了几个小时。这种问题的根治方案是主动失效缓存而不是等缓存过期。我实现了一个简单的双删策略更新数据库后先删除缓存中的 key然后通过消息队列发送一个异步任务延迟 5 秒再删除一次。这样即使第一次删除后又有并发请求把旧数据写回缓存第二次删也能兜底。代码逻辑不复杂public void updateUser(User user) { // 1. 更新数据库 userMapper.updateById(user); // 2. 立即删除缓存 cache.evict(buildKey(user.getId())); // 3. 延迟双删 scheduledExecutor.schedule(() - cache.evict(buildKey(user.getId())), 5, TimeUnit.SECONDS); }这种做法能有效缓解缓存与数据库在并发写场景下的短暂不一致但注意它不是严格的强一致方案。如果业务要求读写串行化那还是得走本地事务 消息事务的完整方案。6.5 Spring Cache 注解不生效的排查模板Spring Cache 注解不生效通常有三个原因第一个原因是缺少 EnableCaching 注解。这个最容易排除检查配置类或启动类上有没有加。第二个原因是目标类内部方法调用。同一个类内部a() 方法调用 b() 方法b 上加的 Cacheable 不会生效因为此时走的是 this 调用而不是 Spring 代理。要解决就需要把方法拆到不同的类里或者使用 AspectJ 模式。第三个原因是 cacheManager 没有把 IgniteCacheManager 设置为首选。Spring Boot 自动配置可能会生成多个 CacheManager如果不指定哪个是主要的注解就找不到正确的缓存管理器直接报错或不执行缓存逻辑。建议在启动时打印 CacheManager 的类型信息确认 Ignite 的 CacheManager 确实被使用。我刚开始做集成时打印出来的是 ConcurrentMapCacheManager当时就懵了后来才发现是自动配置没有显式指定。7. 从单点到集群部署与运维的落地经验7.1 Docker 镜像化与容器化部署为了统一各环境的一致性我最后把 Ignite 节点镜像化了。Dockerfile 写得比较简洁但在实际部署中发现几个必须注意的点。第一个是内存参数。Docker 容器默认的资源限制不会传递给 JVM如果容器 memory limit 是 8G而 JVM 启动参数还是 -Xmx32g容器会被直接杀死。一定要用 JVM 的可用内存自动感知特性或者手动在启动脚本里注入与容器 limit 一致的堆参数。FROM openjdk:8-jre-alpine WORKDIR /app COPY target/my-app.jar app.jar EXPOSE 47100 47500 10800 ENV JAVA_OPTS-Xms4g -Xmx4g -XX:UseG1GC ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar app.jar]第二个是端口映射。Ignite 有三个基本端口需要暴露通信端口 47100、发现端口 47500、SQL 客户端端口 10800。如果你用 Rest API 监控集群还要暴露 8080。Docker 网络用 host 模式最省事但如果你用 bridge 模式端口映射配置错误会导致节点之间无法发现。7.2 滚动升级与灰度发布Ignite 集群有节点动态加入退出能力这是滚动升级的基础。我的升级流程是先停止一个节点等待集群把该节点的分区数据重新平衡到其他节点。这个过程会持续一段时间期间部分缓存写入可能变慢因为需要重新平衡副本。再启动新版本的节点等待它加入集群并开始接收数据。此时 Ignite 会自动将部分分区从旧节点迁移到新节点实现自动数据再平衡。逐个节点重复这个过程直到所有节点都完成升级。这个方案可行但要注意在分区重平衡期间不要触发大规模数据更新否则可能造成数据版本冲突或性能下降。我在升级前会临时把写操作的同步模式从 PRIMARY_SYNC 改成 FULL_SYNC确保重平衡期间数据冗余度足够节点间数据差异能快速收敛。7.3 备份与容灾策略Ignite 集群虽然有多副本机制但备份不是万能的。比如误删数据、代码 bug 导致的大面积覆盖这类逻辑错误同样会同步到备份节点。所以持久化目录的定期快照备份依然需要。我使用文件系统层面的快照任务每天凌晨对每个节点的持久化目录做一次增量备份保留最近 7 天的备份数据。另外Ignite 支持原生快照机制在集群层面做一致性快照control.sh --snapshot create snapshot_name这个命令会创建一个集群范围内的一致性快照恢复时可以通过--restore参数指定快照名称。对于跨节点的数据恢复原生快照比直接复制文件可靠得多因为它能保证多节点之间数据的逻辑一致性。我用 cron 定时任务对接 Ignite 控制命令每周做一次全量快照保存到独立存储。这是最后的容灾兜底平时用不上但一旦出现逻辑性数据损坏它的价值就不可替代。8. 性能对比与优化效果8.1 缓存命中率与响应时间对比先看一下缓存层替换带来的收益。原先用 Caffeine 本地缓存时由于每个应用节点各自独立缓存单节点缓存命中率约 60%因为相同的请求可能被负载均衡分散到多个节点上本地缓存在各节点之间重复存储浪费内存但命中率提不上去。换成 Ignite 分布式缓存后所有节点共享同一份数据命中率直接提升到了 94%。由于缓存数据不再重复存储内存利用率更高同样的数据量下实际占用反而更少。响应时间方面接口的 P99 延迟从原先的平均 180ms 降到了 15ms 左右。提升最明显的是配置类数据和用户状态类数据的读取场景这些数据访问频率极高分布式缓存让大部分请求直接命中内存完全不需要经过网络服务或者数据库。8.2 分布式计算性能实测计算场景的性能收益我记录了一组实测数据。原先通过应用节点从 PostgreSQL 拉取数据、在内存里分组聚合的方案处理全量用户行为数据大约需要 6 分钟而且应用节点的内存经常顶到 90% 以上差点触发 OOM。迁移到 Ignite 分布式计算后同样是全量聚合最终耗时约 25 秒提升了约 14 倍。而且聚合期间应用节点内存很平稳因为压力全部分摊到了 Ignite 集群内部的各个节点上。这个收益的来源不复杂数据本地化计算和存储绑定在同一个节点并行执行4 个节点同时算分摊单节点负载按需传输最终只回传聚合结果避免原始数据的全量网络搬迁。8.3 成本与收益评估任何技术选型都不是免费的。Ignite 的引入带来了一些额外成本运维复杂度明显提高原先一个 Redis 实例就能解决的问题现在要维护一个 Ignite 集群。集群的监控、调优、故障恢复都需要额外的运维知识和人力投入。内存资源消耗不小Ignite 是多副本存储节点数的增加会导致数据总体占用内存上升。如果你的数据量不大或缓存命中率不高用 Ignite 属于杀鸡用牛刀。但如果你的业务场景和数据量确实到了 TB 级别同时有计算需求技术选型的结论就很清晰了Ignite 带来的性能收益和架构简洁性远高于增加的运维成本。它把数据层和计算层合并了架构上少了一层中间链路从长期维护角度反而是节省成本的。9. 经验总结与后续演进9.1 项目落地后的收获与反思做完这个项目我更清楚地认识到无视业务场景和团队承载能力盲目追求新技术方案是风险最高的行为。Ignite 集成的技术难点其实不在 API 使用而在于对整个分布式原理的理解——数据分布、亲和性、副本同步、故障恢复。这些概念如果你是第一次接触建议先在单机模式下把功能跑通再逐步增加节点测试分布效果别一上来就铺多个节点出了问题很难定位。我把这个过程中沉淀的几个可复用原则总结一下缓存键必须显式设计不要依赖业务对象的 toString 或默认 hashCode分布式的数据无论在哪一层都要遵循“先写主库再维护缓存”的流程缓存永远不承担主存储职责计算任务要利用亲和性把计算推到数据所在节点这是 Ignite 区别于 Redis 等纯缓存组件的最大价值。9.2 后续技术演进路径项目已经稳定运行半年多了后续我在考虑几个演进方向。首先是集群的容器化编排。目前 Ignite 节点跑在云主机上手工管理升级和扩容。之后我想把整个集群迁移到 Kubernetes利用 Ignite 官方提供的 K8s 集成让节点自动注册、自动发现配合 HPA 做自动扩缩容运维压力会更小。其次是数据同步实时化。目前缓存数据是通过定时任务从 PostgreSQL 同步到 Ignite 的有分钟级延迟。后续计划引入 CDC 机制订阅数据库的变更日志比如 Debezium让配置类数据在秒级内更新到缓存。最后是计算能力的深化。Ignite 的机器学习模块我已经在做 POC准备把一些特征计算和模型推理任务直接放到 Ignite 集群里减少特征数据和模型服务之间的传输成本。9.3 一个值得分享的调优细节最后分享一个我踩了三次的坑Ignite 的 peerClassLoadingEnabled 参数。开发环境我设置了 true这样各节点把任务类自动分发给其他节点省去每台机器都打包部署的麻烦。但生产环境我把它关了因为开启后每台节点都会动态加载任务类如果代码版本不统一集群里会出现类版本互相覆盖的诡异问题非常难排查。生产环境所有节点必须保证依赖的 jar 包完全一致不要在运行期依赖类动态加载。这是 Ignite 集群稳定运维的第一条军规。另外如果你的项目也用 Spring Boot 3 或 4升级前务必确认 Ignite 的版本支持情况。Ignite 2.15 有专门针对 Jakarta EE 的兼容分支但文档不多遇到问题只能自己啃源码。如果团队对这块没有足够的排查耐心建议先锁在 Spring Boot 2.7 版本上等 Ignite 官方整合完善后再升级。这套方案跑起来之后性能和稳定性给我留下了很深的印象也让团队对分布式缓存和分布式计算有了更具体的认知。后续的业务扩展和架构演进我都多了一个可以落地的可选方案。
