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

Ignite3 竟然变成分布式数据库了!

news 2025/10/10 0:06:08

Ignite3 怎么变成一个分布式数据库了?

这个问题问得非常好。
Apache Ignite 3（正式名：Apache Ignite 3.x）之所以被称为“分布式数据库”，而不仅仅是 Ignite 2 那样的“内存数据网格 (IMDG)”，是因为它在架构、存储层、事务模型、SQL 层和一致性模型上都进行了深度重构，从缓存系统演化成了一个真正具备数据库语义的系统。

我们可以从以下几个方面看它是如何变成分布式数据库的：

一、从「数据网格」到「存储系统」

Ignite 2.x：

核心是内存分布式缓存 + 可选的持久化层（Persistence Store）。
持久化只是“可选缓存后端”，而非数据库主存储。
元数据（schema）与 SQL 解析层都比较轻量，偏向数据计算引擎而非数据库。

Ignite 3.x：

引入了 可持久化的分布式存储层（Distributed Storage Engine），基于 LSM-tree 设计。
所有数据（包括索引）都能持久化到磁盘，不再依赖外部存储。
数据分区与副本之间具备真正的 数据一致性、恢复、重平衡 功能。

👉 这意味着 Ignite 3 本身就是一个持久的分布式数据存储系统，而不是缓存别的数据库的数据。

二、统一的分布式 SQL 层

Ignite 3 的 SQL 层基于 Apache Calcite 重写：

完整支持 ANSI SQL-2011。
分布式查询执行计划可跨节点优化与调度。
提供 Schema-on-write（即真正的关系型表定义与约束）。
SQL 查询不再只是对缓存的语法糖，而是直接操作分布式表。

👉 这让 Ignite 3 拥有类似 分布式 PostgreSQL 或 CockroachDB 的语义。

三、强一致性事务

Ignite 2 的事务模型偏弱（主要基于悲观锁或 MVCC，但实现不彻底）。
Ignite 3 重新实现了一套 可线性化的分布式事务协议：

事务管理基于 Raft 共识协议，而非简单消息协调。
每个数据分区都有独立的 Raft group。
支持 ACID 事务，跨分区分布式提交时具备原子性。

👉 这部分设计类似 FoundationDB、TiDB、CockroachDB。

四、独立的存储层与计算层解耦

Ignite 2：节点既负责存储又负责计算。
Ignite 3：引入 “Storage Engine SPI” 和 “Compute Engine SPI” 的分层接口。
- 存储层负责持久化与复制。
- 计算层负责执行分布式查询、索引和事务调度。
这种解耦让 Ignite 3 可以像 TiDB 那样分为 “stateless SQL 层” + “stateful Storage 层”。

五、Schema 和元数据管理中心化

Ignite 3 引入 Meta Storage（基于 RAFT），保证集群元数据一致。
DDL（如 CREATE TABLE）操作不再广播，而是经共识提交。
保证集群 schema 在分布式环境下的一致性与可恢复性。

六、整体目标定位的变化

Ignite 版本	主要定位	核心特征
Ignite 2.x	分布式缓存 / 数据网格	IMDG + 可选持久化
Ignite 3.x	分布式关系型数据库	分布式事务 + SQL + 存储引擎

七、总结一句话

Ignite 3 不再是 “缓存”，而是 “有缓存能力的分布式数据库”。

它类似于：

TiDB（分布式 SQL 层 + 存储层）
CockroachDB（共识复制 + 分布式事务）
但仍保留了 Ignite 原有的 “内存优先 + 可计算” 特性。

是否希望我画一张对比图（Ignite 2 vs Ignite 3 的架构层次对照图）？
那样可以清晰看到它如何“从缓存到数据库”一步步演变。

那它之前的分布式锁和分布式Map呢

非常好的问题。
这正好触及到 Ignite 3 的一个核心变化：它不再是一个分布式缓存框架（data structure API）为中心的系统，而是转型为一个以表（table）与事务为中心的数据库。
因此，像 Ignite 2 那样的分布式 Lock、AtomicLong、DistributedMap 等 API，在 Ignite 3 里要么被删掉，要么被彻底换成“数据库语义”的替代机制。

我们可以详细拆开来看：

一、Ignite 2 时代的 “分布式数据结构”

在 Ignite 2.x 时代，它本质是个 分布式内存网格 (IMDG)，所以提供了一整套 类似 java.util.concurrent 的分布式集合与锁：

类型	Ignite 2 功能
`IgniteCache<K, V>`	分布式 Map（带 near-cache、分区、备份）
`IgniteLock`	分布式锁
`IgniteAtomicLong`, `IgniteAtomicReference`	分布式原子计数/引用
`IgniteQueue`, `IgniteSet`	分布式队列与集合
`IgniteCompute`	分布式任务执行

这些接口让它更像 一个内存分布式容器库（有点像 Hazelcast）。

二、Ignite 3 时代的架构转型

Ignite 3 彻底抛弃了“数据结构 API”这一层，转向更清晰的数据库模型。

在 Ignite 3 中，数据访问全部通过：

Table API（行级 API）
SQL API
事务 API（Transactional API）

也就是说：

你不再操作 “Map” 或 “Lock”，而是操作 “表”和“事务”。

三、那么分布式锁和 Map 现在怎么办？

🔹 1. 分布式 Map → Table API

IgniteCache<K,V> 被替代为 Table：

Table table = ignite.tables().table("person");RecordView<Person> view = table.recordView(Person.class);
view.upsert(tx, new Person(1, "Alice"));
Person p = view.get(tx, new Key(1));

这其实就是一个带 schema 的分布式 Map，只不过：

它是 持久化的；
支持 SQL 索引和查询；
具有 分布式事务一致性；
不能直接像 Java Map 一样随意使用（必须通过事务或 SQL）。

👉 所以 “分布式 Map” 功能仍然存在，只是语义升级成 “分布式表”。

🔹 2. 分布式锁 → 事务 + 共识机制

IgniteLock 已经被移除。原因是：

Ignite 3 采用 分布式事务 (ACID) + Raft 共识协议；
锁的语义由 事务的隔离级别（Serializable / Repeatable Read） 保证；
不再提供显式的可重入分布式锁对象。

想要“锁”的效果，现在有两种方法：

方式 A：通过事务实现

try (Transaction tx = ignite.transactions().begin()) {Person p = view.get(tx, new Key(1));// 修改数据，相当于获得写锁p.name = "Bob";view.upsert(tx, p);tx.commit();
}

此操作在 Serializable 级别下相当于“悲观锁 + 原子提交”。

方式 B：通过表模拟锁（推荐）
建一个表 locks(resource_id TEXT PRIMARY KEY)，用行存在性来表示锁状态：

CREATE TABLE locks (resource_id VARCHAR PRIMARY KEY
);

INSERT INTO locks VALUES ('my_resource') → 尝试加锁
DELETE FROM locks WHERE resource_id='my_resource' → 释放锁
插入冲突说明锁被占用（可重试）

这种方式在分布式数据库中非常常见，比如 CockroachDB、TiDB 都推荐这种模式。

🔹 3. 分布式 AtomicLong / Counter

IgniteAtomicLong 等结构也被移除。
替代方法是使用表加事务：

CREATE TABLE counters (name VARCHAR PRIMARY KEY,value BIGINT
);

然后：

UPDATE counters SET value = value + 1 WHERE name = 'hits';

或通过 Java API：

view.invoke(tx, key, old -> old.value + 1);

利用事务保证原子性。

四、这样做的好处

所有分布式一致性都通过 统一事务层 保证；
不再有一堆不一致的 “锁”、“原子值”、“缓存” API；
语义清晰：Ignite 3 = 分布式数据库，不是分布式内存容器；
减少了开发者混用缓存语义与数据库语义的歧义。

五、总结对比

特性	Ignite 2.x	Ignite 3.x
分布式 Map	`IgniteCache`	`Table` / `RecordView`
分布式锁	`IgniteLock`	事务 / 表模拟
原子计数器	`IgniteAtomicLong`	表 + UPDATE / invoke
队列 / 集合	`IgniteQueue`, `IgniteSet`	暂无直接替代（需自行建表）
一致性	基于节点消息 / MVCC	基于 Raft 共识协议
语义层	Cache / DataGrid	Database / Transactional SQL