SQLite能替代SAP Cloud Platform Cache吗？实战项目验证

在SAP Cloud Platform上做应用性能调优时，缓存层选型总是一个绕不开的话题。有人觉得SQLite够轻量，一个文件就能把数据都存下来，干脆拿它当缓存层。实际跑起来后，读延迟没有明显下降，多实例部署还会出现数据不一致。出现这种偏差，主要是因为把嵌入式数据库和平台级缓存服务当成了同类组件。本文用一个商品库存查询项目，演示SQLite如何与SAP Cloud Platform Cache分层配合，让热数据快速命中缓存，冷数据落在本地快照。

一、SQLite与SAP Cloud Platform Cache的定位差异

SQLite是一个嵌入式关系型数据库，它的数据文件可以随应用一起部署，支持完整的ACID事务和标准SQL查询。听起来功能很全，但它的写入锁是文件级的，同一时间只允许一个写操作。对于缓存场景中大量并发读和频繁更新，SQLite容易在锁竞争上消耗时间。尤其是在SAP Cloud Platform上多实例部署时，每个应用实例各自维护一份SQLite文件，数据天然隔离，根本做不到集中式缓存的效果。

SAP Cloud Platform Cache通常是基于Redis的托管缓存服务，定位是进程外的共享内存存储。它支持键值读写、过期时间、发布订阅、原子操作和集群模式。应用实例通过统一的连接地址访问同一份缓存，天然适合保存会话状态、热点商品库存、接口限流计数等临时数据。和SQLite不同，它不需要开发者处理表结构、索引或锁，只需要关注键设计和失效策略。

下面这张表可以直观看出两者的差异：

可以看出，SQLite的优势在于本地事务处理和小规模数据落盘，而SAP Cloud Platform Cache的优势在于低延迟访问和跨实例共享。如果把缓存直接建在SQLite上，等于让一个面向磁盘的数据库去承担内存缓存的职责，性能自然不会理想。

二、实战项目：订单查询服务的数据分层设计

假设有一个部署在SAP Cloud Platform的Node.js订单查询服务，商品资料和实时库存来自后端SAP系统或HANA数据库。如果每个查询都直接回源，延迟通常在200毫秒以上，高峰时源系统压力也很大。为了降低延迟，团队引入了两层本地加速：第一层是SAP Cloud Platform Cache，专门保存最近被访问的热门商品库存；第二层是应用实例本地的SQLite文件，保存最近一次成功同步的商品快照。

查询路径设计成三级：请求先查Cache，命中后直接返回；未命中再查SQLite快照，如果快照在有效期内则返回并异步回填Cache；SQLite也没有命中时，才回源到SAP系统或HANA，拿到结果后写SQLite并写入Cache。这样做的好处是，即使Cache整体失效或短暂不可用，SQLite仍能兜住一部分读请求，避免雪崩到源系统。

缓存键采用命名空间加业务主键的规范，例如stock:10001表示商品10001的库存值，price:10001表示价格。命名空间可以避免不同业务类型之间的键冲突。所有写入Cache的键都设置TTL，库存数据通常设置30秒左右，保证不会长期返回过期值。

SQLite表结构不用复杂，只保留查询需要的字段。下面以库存快照为例：

CREATE TABLE product_snapshot (
  id TEXT PRIMARY KEY,
  name TEXT NOT NULL,
  stock INTEGER NOT NULL,
  updated_at INTEGER NOT NULL
);
CREATE INDEX idx_product_updated ON product_snapshot(updated_at);

这里把商品ID作为主键，并额外对更新时间建立索引，方便后续清理旧数据。SQLite的PRIMARY KEY能保证单个商品不会重复插入，配合INSERT OR REPLACE就可以完成快照更新。

三、关键代码实现与配置

项目使用Node.js运行在SAP Cloud Platform上，核心依赖是better-sqlite3、redis和express。其中better-sqlite3负责本地SQLite读写，redis负责和SAP Cloud Platform Cache交互。安装命令如下：

npm install better-sqlite3 redis express

初始化SQLite时，建议开启WAL模式。WAL把写入先落到单独的日志文件，读操作不需要等待写锁释放，对查询性能和并发都有明显改善。连接Cache时，地址来自环境变量REDIS_URL，这个变量通常由SAP Cloud Platform的服务绑定自动注入。以下是一个可运行的封装示例：

const Database = require('better-sqlite3');
const redis = require('redis');

const db = new Database('/mnt/data/catalog.db');
db.pragma('journal_mode = WAL');

const cache = redis.createClient({
  url: process.env.REDIS_URL
});
cache.connect();

async function getStock(productId) {
  const cacheKey = `stock:${productId}`;
  const cached = await cache.get(cacheKey);
  if (cached !== null) {
    return JSON.parse(cached);
  }

  const row = db.prepare('SELECT stock FROM product_snapshot WHERE id = ?')
    .get(productId);

  if (!row) {
    return null;
  }

  await cache.set(cacheKey, JSON.stringify(row.stock), { EX: 30 });
  return row.stock;
}

这段代码先查Cache，命中后返回数字；未命中时读取SQLite，拿到快照后写入Cache并设置30秒过期。注意读SQLite用的prepare加get是同步调用，在Node.js中不会占用事件循环太久，因为SQLite本地读取通常在亚毫秒级完成。如果业务要求严格异步，也可以用better-sqlite3的同步特性直接获取数据，配合缓存异步写入不会影响主流程。

更新商品库存时，需要同时维护SQLite快照和Cache一致性。常见的做法是先更新SQLite，再删除Cache中的旧值，而不是更新Cache。这样下一个读请求会发现Cache未命中，然后从SQLite读取新值并重新回填，避免并发更新时多个请求写入不同版本的缓存数据。示例代码如下：

async function updateStock(productId, newStock) {
  const stmt = db.prepare(
    'UPDATE product_snapshot SET stock = ?, updated_at = ? WHERE id = ?'
  );
  stmt.run(newStock, Date.now(), productId);

  await cache.del(`stock:${productId}`);
}

代码中没有直接更新Cache，而是采用删除策略。这样即使后续有并发请求同时读取，也只会有一个请求最终回填Cache，其他请求短暂未命中后查SQLite，读到的仍是一致的值。对于库存这类允许短暂不一致的数据，这种模式足够稳定。配置SAP Cloud Platform Cache时，需要确保服务实例已绑定到应用，并且应用能读取到REDIS_URL。如果是本地开发环境，可以使用Redis官方镜像或本地Redis服务，把连接地址写进环境变量即可。

四、性能对比与踩坑记录

在本地模拟环境中，单实例、单线程读SQLite单条记录可以到0.1毫秒左右，而访问Cache因为存在网络往返，约0.5毫秒。乍看SQLite更快，但把并发提高到10个请求后，SQLite由于文件读锁排队，平均延迟升到2毫秒以上，而Cache仍能稳定在0.6毫秒附近。这个差距在多实例部署时更明显，因为每个实例的SQLite文件相互独立，热门商品在不同实例上可能各自维护一份快照，命中率不统一。

第一个容易踩的坑是忘记开启WAL模式。SQLite默认的journal模式会让读和写互相阻塞，缓存回填和快照更新同时发生时，可能出现偶发慢查询。解决方法是初始化时执行db.pragma('journal_mode = WAL')，并确保SQLite文件所在目录有写权限。第二个坑是缓存穿透。如果某个商品ID在源系统不存在，每次请求都会回源查询，造成不必要的压力。可以在Cache中写入空值标记，例如null:1，并设置较短的TTL，让穿透请求快速返回。

第三个坑是SQLite文件路径。SAP Cloud Platform的容器文件系统默认是可写的，但应用重启后文件会丢失。如果希望快照跨重启保留，需要把SQLite文件放到持久化存储挂载点，例如/mnt/data目录，并且确认该目录在应用实例之间不会互相覆盖。第四是双写不一致。不要同时更新SQLite和Cache为一个新值，这样并发请求可能把旧值重新写入Cache。采用先更新SQLite再删除Cache的方式，能避免大部分竞态问题。

综上，SQLite和SAP Cloud Platform Cache在实战中不是替代关系，而是互补关系。SQLite负责本地快照和兜底读，SAP Cloud Platform Cache负责高性能共享缓存。判断标准可以看数据访问频率和实例数量：只有单实例、低并发、数据结构复杂时，可以适当依赖SQLite；一旦服务需要多实例部署或热点数据明显，就应当把Cache放在核心路径上。

SQLiteSAP Cloud Platform Cache缓存策略修改时间：2026-10-03 20:10:41