SQLite作为轻量级嵌入式数据库，被广泛用在移动端、桌面软件和小型服务中。它零部署、单文件、事务完整，但它终究是单机存储，一旦并发读压力上来，或者多个服务实例需要共享热点数据，单靠SQLite就会捉襟见肘。把阿里云云数据库Redis版（ApsaraDB for Redis）引入到以SQLite为持久层的系统中，用Redis承担热点读、用SQLite保证数据落盘，是一个非常实用的混合架构方案。本文结合一个商品信息查询服务的实战项目，完整讲解这套架构的设计思路、代码实现和踩坑经验。
一、项目背景与整体架构设计
这个实战项目的业务场景很典型：一个商品详情服务，商品基础数据（名称、价格、库存快照、描述）总量在百万级，冷数据居多，但头部几千个热门商品占了绝大部分查询流量。服务早期直接查SQLite，单机QPS在几百时表现尚可，但大促期间读请求飙升到每秒数千，SQLite的文件锁和磁盘IO成了明显瓶颈，接口P99延迟一度超过500毫秒。
分析流量特征后发现，80%以上的请求集中在不到5%的商品上，这正是缓存的经典适用场景。于是架构调整为三层：客户端请求先查阿里云Redis，命中则直接返回；未命中则回源查询SQLite，并将结果写入Redis设置过期时间；SQLite作为唯一可信数据源，负责持久化和事务。Redis只存热点数据的JSON序列化结果，不承担持久化职责，这样即使Redis故障或数据丢失，系统也只是退化为直查SQLite，不会造成数据错误。
选择阿里云云数据库Redis版而不是自建Redis，主要出于运维考虑：它提供主备架构、自动故障切换、白名单访问控制和备份恢复能力，无需自己维护哨兵或集群，对于小团队来说节省了大量精力。实例规格上，初期选择1GB标准版主备实例即可满足需求，后续可通过控制台在线升配。
二、核心读写逻辑的代码实现
项目使用Java加Spring Boot实现，SQLite通过JDBC访问，Redis客户端使用Jedis。首先封装一个缓存服务类，把读写策略集中在同一个地方，避免缓存逻辑散落在各个业务方法里。核心代码如下：
public Product getProduct(long id) {
String key = "product:" + id;
// 1. 先查Redis缓存
String cached = jedis.get(key);
if (cached != null) {
if ("NULL".equals(cached)) {
// 缓存空值标记，防止缓存穿透
return null;
}
return JSON.parseObject(cached, Product.class);
}
// 2. 缓存未命中，回源查询SQLite
Product product = sqliteDao.findById(id);
// 3. 写回Redis，过期时间加随机偏移防止雪崩
if (product != null) {
int ttl = 1800 + new Random().nextInt(600);
jedis.setex(key, ttl, JSON.toJSONString(product));
} else {
// 空结果也缓存，但过期时间设置得短一些
jedis.setex(key, 60, "NULL");
}
return product;
}这段代码体现了三个关键细节。第一是空值缓存：如果恶意请求不断查询不存在的商品ID，每次都会穿透到SQLite，把空结果缓存60秒能有效挡住这类攻击。第二是TTL随机化：所有热点key如果设置相同的过期时间，会在同一时刻集中失效，造成瞬时大量请求打到SQLite，这就是缓存雪崩，加上0到10分钟的随机偏移可以让失效时间打散。第三是过期时间不宜过长：本例设置30分钟左右，在性能与数据新鲜度之间取平衡。
更新数据的逻辑同样重要。商品价格调整时，推荐的顺序是先更新SQLite，再删除Redis缓存（Cache Aside模式），而不是更新缓存。删除比更新更安全，因为删除是幂等操作，即使并发更新导致顺序错乱，最多造成短暂不一致，下一次读请求会把最新数据加载回来。
public void updateProduct(Product product) {
// 先写SQLite，事务保证落盘
sqliteDao.update(product);
// 再删除缓存，让下次读取时重新加载
jedis.del("product:" + product.getId());
}三、连接阿里云Redis的配置与安全要点
购买阿里云云数据库Redis实例后，控制台会提供一个内网连接地址（形如r-xxxxxxxx.redis.rds.aliyuncs.com）和默认端口6379。强烈建议启用密码认证，并在白名单中只放行应用服务器的内网IP段。Jedis连接配置示例：
JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxTotal(200);
poolConfig.setMaxIdle(50);
poolConfig.setTestOnBorrow(true);
// 使用连接池，避免频繁创建连接
JedisPool jedisPool = new JedisPool(
poolConfig,
"r-xxxxxxxx.redis.rds.aliyuncs.com",
6379,
2000, // 连接超时毫秒
"你的Redis密码",
0, // 默认db
false // 是否启用SSL，内网可不启用
);这里有几个生产环境的经验值得强调。首先是必须使用连接池，每次请求新建Jedis连接的开销在高峰期会拖垮性能；其次设置合理的连接超时和读写超时，避免Redis偶发抖动时请求线程被长时间占用；最后是故障降级，建议对Redis访问包裹try-catch，任何Redis异常都记录日志后直接回源SQLite，保证缓存层故障不影响核心功能可用性。
另外要注意SQLite本身的并发限制。即使在加了缓存之后，回源请求仍可能并发读写SQLite文件。SQLite默认的journal模式在并发写下容易出现database is locked错误，建议开启WAL模式（执行PRAGMA journal_mode=WAL;），它能显著改善读写并存的场景，配合连接池设置busy_timeout为5000毫秒，基本可以消除锁冲突报错。
四、压测效果与方案取舍
完成架构改造后，使用压力测试工具对商品详情接口做了对比。直连SQLite方案在QPS达到400时P99延迟已超过400毫秒，继续加压则大量报锁等待错误；引入Redis缓存层后，缓存命中率稳定在92%以上，整体QPS提升到8000以上，P99延迟降到15毫秒以内，回源请求对SQLite的压力反而比改造前更低。效果提升的主要来源是热点数据全部由Redis的内存读取承担，SQLite只处理长尾冷数据和写入。
当然，这套方案并非没有代价。引入Redis意味着系统多了一个外部依赖，数据一致性从强一致退化为最终一致，缓存与数据库之间的同步逻辑增加了代码复杂度。如果业务对一致性要求极高（比如库存扣减的精确计数），就不能简单用Cache Aside模式，而应该让计数类操作直接走Redis原子命令，再异步持久化到SQLite。选型时务必先评估业务特征：读多写少、允许秒级延迟的数据适合缓存；强一致要求的写路径仍要以SQLite事务为准。
总结来说，SQLite负责可靠与轻量，阿里云Redis负责速度与并发，两者组合能以很低的成本支撑起中型业务的访问量。关键在于把缓存策略写对：空值防穿透、随机TTL防雪崩、先库后缓存删防不一致、异常降级保可用，这四条原则做到位，这套混合架构就能稳定运行。