SQLite作为全球部署量最大的嵌入式关系型数据库，几乎不需要单独的数据库服务进程，一个文件就是一整套库表结构。而Pivotal GemFire（现VMware Tanzu GemFire）则是面向企业级的分布式内存数据管理平台，擅长在集群节点间复制和分区数据。这两者的能力看起来一个偏本地、一个偏分布式，把它们放到同一个项目里，往往能形成"边缘持久化加中心同步"的混合架构。本文将通过一个完整的实战项目，演示如何在GemFire的集群事件回调中把数据落到本地SQLite文件，同时保留GemFire的高吞吐特性。
一、两者的定位差异与互补关系
先明确SQLite的边界。它是一个进程内数据库，数据存放在单个跨平台的文件中，没有独立的服务端，也不存在网络协议层的开销。读取性能极快，写入在开启WAL模式后也能满足中等强度的并发需求。它的局限同样明显：不适合多进程同时写入、不提供网络访问、没有原生的分布式能力。
GemFire走的是完全相反的路线。它将数据以Region（区域）的形式组织，Region可以配置为复制模式或分区模式，数据在多个节点之间自动同步。它还提供持续查询、事件监听、异地网关等企业级特性，代价是部署和运维复杂度远高于SQLite。
两者结合的典型场景是：GemFire作为内存中的权威数据源，承担高并发的读写请求；SQLite作为节点本地的持久化快照，用于服务重启后的快速预热、审计留痕，或者在网络分区时提供降级读取能力。这种组合避免了每次都依赖关系型数据库做落盘，又保证了节点级别的数据不丢失。
二、准备环境与SQLite的基本操作
实战项目使用Java开发。SQLite侧推荐使用sqlite-jdbc驱动，它内嵌了本地库，开箱即用。在Maven项目中加入以下依赖即可。
<dependency>
<groupId>org.xerial</groupId>
<artifactId;gt;sqlite-jdbc</artifactId>
<version>3.45.1.0</version>
</dependency>
<dependency>
<groupId>org.apache.geode</groupId>
<artifactId>geode-core</artifactId>
<version>1.15.1</version>
</dependency>接下来封装一个简单的SQLite访问工具类。注意两点：一是连接建议使用单例或连接池复用，SQLite建立连接虽然便宜，但频繁开关文件句柄在高频写入时仍有代价；二是务必开启WAL模式，否则并发读写会出现SQLITE_BUSY错误。
public class SQLiteStore {
private final Connection conn;
public SQLiteStore(String path) throws SQLException {
this.conn = DriverManager.getConnection("jdbc:sqlite:" + path);
// 开启WAL模式，提升并发读写能力
try (Statement st = conn.createStatement()) {
st.execute("PRAGMA journal_mode=WAL;");
st.execute("PRAGMA synchronous=NORMAL;");
}
}
public void initTable() throws SQLException {
try (Statement st = conn.createStatement()) {
st.execute("CREATE TABLE IF NOT EXISTS t_user (" +
"id TEXT PRIMARY KEY, name TEXT, balance REAL, updated_at INTEGER)");
}
}
public void upsert(String id, String name, double balance) throws SQLException {
try (PreparedStatement ps = conn.prepareStatement(
"INSERT INTO t_user(id,name,balance,updated_at) VALUES(?,?,?,?) " +
"ON CONFLICT(id) DO UPDATE SET name=excluded.name, " +
"balance=excluded.balance, updated_at=excluded.updated_at")) {
ps.setString(1, id);
ps.setString(2, name);
ps.setDouble(3, balance);
ps.setLong(4, System.currentTimeMillis());
ps.executeUpdate();
}
}
}这段代码里用了ON CONFLICT DO UPDATE语法实现upsert，这是SQLite原生的写法，比先查再插的方案性能更好，也能避免并发下的重复插入问题。
三、GemFire区域配置与缓存监听器
数据落盘的关键在于GemFire的CacheListener机制。每当Region中的条目发生创建、更新或销毁时，对应的回调方法会被触发，我们可以在回调里把变更写入SQLite。先定义一个持久化的Region并注册监听器。
public class GemFireDemo {
public static void main(String[] args) throws Exception {
Cache cache = new CacheFactory().set("log-level", "warning").create();
RegionFactory<String, String> rf = cache.createRegionFactory(RegionShortcut.REPLICATE);
rf.addCacheListener(new SqliteSyncListener("node1.db"));
Region<String, String> userRegion = rf.create("userRegion");
userRegion.put("u1001", "{\"name\":\"张三\",\"balance\":888.5}");
}
}监听器的实现需要注意一个原则：回调方法运行在GemFire的操作线程上，任何耗时操作都会拖慢数据写入路径。因此对SQLite的写入如果非常频繁，建议先放入内存队列，再由独立线程批量落盘。
public class SqliteSyncListener extends CacheListenerAdapter<String, String> {
private final BlockingQueue<String[]> queue = new LinkedBlockingQueue<>(10000);
private final SQLiteStore store;
public SqliteSyncListener(String dbPath) throws Exception {
store = new SQLiteStore(dbPath);
store.initTable();
// 后台消费线程，批量写入SQLite
Thread worker = new Thread(() -> {
try {
while (true) {
List<String[]> batch = new ArrayList<();
String[] first = queue.take();
batch.add(first);
queue.drainTo(batch, 500);
for (String[] row : batch) {
store.upsert(row[0], row[1], Double.parseDouble(row[2]));
}
}
} catch (Exception e) {
// 记录日志，必要时重放
}
}, "sqlite-writer");
worker.setDaemon(true);
worker.start();
}
@Override
public void afterCreate(EntryEvent<String, String> event) {
afterUpdate(event);
}
@Override
public void afterUpdate(EntryEvent<String, String> event) {
String json = event.getNewValue();
// 实际项目中可解析JSON后入队，这里简化为拆分字符串
queue.offer(new String[]{event.getKey(), parseName(json), parseBalance(json)});
}
@Override
public void afterDestroy(EntryEvent<String, String> event) {
// 对应执行DELETE语句，逻辑类似
}
}这个异步批处理结构是整个方案的核心。队列充当了内存中的缓冲区，GemFire的高频写入不会因为磁盘IO而阻塞；后台线程通过drainTo一次性取出最多500条记录集中写入，配合SQLite的事务批量提交，吞吐量可以轻松达到每秒数万条。
四、一致性、容灾与部署注意事项
异步落盘必然带来一个窗口期内的数据不一致：进程突然崩溃时，队列中未写入的数据会丢失。如果业务无法接受，可以开启GemFire的持久化Region（RegionShortcut.REPLICATE_PERSISTENT），让GemFire自己先落盘到磁盘队列文件，SQLite则退化为查询和审计用途。两种持久化各司其职，可靠性由GemFire保证，分析能力由SQLite的SQL查询提供。
多节点部署时要防止重复写入。GemFire的监听器事件默认在每个承载该Region的节点上都会触发，如果每个节点都写各自本地的SQLite文件，天然不冲突；但如果多个节点共享一个网络存储上的数据库文件，SQLite的文件锁会成为瓶颈甚至报错。经验做法是：每个节点一个独立的db文件，文件名加上节点标识，汇聚分析时再合并。
最后关注SQLite文件的运维细节。WAL模式下会额外产生-wal和-shm文件，备份时必须一并处理，或者使用VACUUM INTO命令生成一致性快照；定期执行PRAGMA wal_checkpoint(TRUNCATE)可以回收WAL文件空间，避免其无限增长。掌握这些细节，SQLite与GemFire的组合就能在真实生产环境中稳定运行。
SQLitePivotal GemFire分布式缓存修改时间：2026-09-13 07:06:32