30 秒速读：PostgreSQL 读压力一大，加读副本要改应用、自己写缓存失效逻辑又怕读到脏数据。本篇讲的是 pgcache：一个面向 PostgreSQL 的一致性查询缓存代理，它用 Rust 实现，插在应用和数据库之间，通过逻辑复制把源库变更实时同步进缓存，只缓存真实的热点查询，不可缓存的请求直接透传回源库，应用侧改个连接字符串就能接入。关键词：pgcache。
软件信息一览
| 项目 | 说明 |
|---|---|
| 项目名称 | pgcache |
| 项目定位 | 面向 PostgreSQL 的一致性查询缓存代理 |
| 实现语言 | Rust |
| 接入方式 | PostgreSQL 线协议（应用改连接字符串即可） |
| 一致性机制 | 逻辑复制（CDC）+ 复制槽，变更驱动缓存更新或失效 |
| 缓存数据库 | 独立 PostgreSQL 实例（需安装 pgcache_pgrx 扩展） |
| 适配评估 | Fit Analyzer（浏览器 WebAssembly，本地分析查询输入） |
| 兼容版本 | PostgreSQL 16、17、18（据项目说明） |
| 许可证 | README 展示 Elastic License 2.0（分发前请核对 LICENSE 文件） |
版本选择：评估期用 Docker 快速启动，生产评审再看源码构建
结论先行：先拿 Docker 快速启动 + Fit Analyzer 把”我的查询到底能不能缓存”验证清楚，再谈生产部署；需要定制功能或跟进最新提交，才考虑源码构建。缓存代理一旦进生产链路，版本漂移的排查成本很高，评估期别贪新。
| 取用方式 | 适合谁 | 风险点 |
|---|---|---|
| Docker 快速启动 | 评估适配性、跑 POC | 默认参数未必适合生产 |
| 源码构建 | 定制功能、跟进最新提交 | 构建链复杂，版本漂移自担 |
| 多种源库连接配置 | 已有 PostgreSQL 环境接入 | upstream、DATABASE_URL、.env、PG* 环境变量别混用 |
推荐路线：先用 Docker 把代理、源库、缓存库三件套跑通，再用 Fit Analyzer 喂真实查询看可缓存比例，比例可观再进入生产评审；源码构建留给有定制需求的团队。
上手只盯 3 个卡点
- 先开逻辑复制，再谈其他。pgcache 的一致性完全依赖源库的逻辑复制和复制槽，wal_level 没开成 logical、publication 没建，代理连启动都过不去。这是硬门槛，先确认源库允许，再往下走。
- 独立缓存库别想着省。缓存数据存在另一个装了 pgcache_pgrx 扩展的 PostgreSQL 实例里，不是随便找个库就能当。代理到源库、到缓存库的连通性，以及扩展版本和主程序版本的对应关系，三处对不上就先别部署。
- 先跑 Fit Analyzer，再决定投不投入。用 pg_stat_statements 导出或 csvlog 拿到真实查询，丢进浏览器里的 Fit Analyzer（WebAssembly 本地分析），看看你的查询到底有多少可缓存。可缓存比例低，这个项目再好也帮不上你。
落地前必做的 4 项配置
- 源库连接配置。入口：配置文件或 CLI 参数（upstream、DATABASE_URL、.env、PG* 环境变量任选其一）。体感差别：四种写法都能用，但一个部署只留一种；混用了出问题，第一反应永远是”到底连的是哪个库”。
- 逻辑复制与复制槽。入口：源库 wal_level=logical、publication、复制槽。体感差别：复制槽没人消费时 WAL 删不掉，会把源库磁盘撑爆；复制延迟和槽积压必须进监控，这是运维 pgcache 最容易被忽视的一环。
- 缓存库扩展版本。入口：独立缓存 PostgreSQL 上的 pgcache_pgrx 扩展。体感差别：扩展版本、pgcache 主程序版本、PostgreSQL 大版本三方要对齐；升级时三处一起核对，只升一处最容易翻车。
- 透传比例观察。入口：代理日志与查询分析。体感差别：不是所有查询都会进缓存，透传比例高意味着收益打折；上线初期盯着”缓存了多少、透传了多少”，再决定要不要调整。
先看 5 条限制，再决定上不上
- 只有被判定为可缓存的查询才走缓存。其余请求全部透传回源库；热点不集中、查询形态复杂的应用，实际收益可能不如预期，先拿 Fit Analyzer 验证。
- 部署三件套缺一不可。启用逻辑复制的源库、带 pgcache_pgrx 扩展的独立缓存库、代理本身，环境不完整就无法按项目说明的方式运行。
- 查询语义与事务边界要自己确认。公开摘要没有完整列出查询语义、事务行为、缓存容量策略和故障切换边界，生产前必须结合文档或源码逐项确认。
- 许可证分发前当面核对。README 展示 Elastic License 2.0，但仓库 API 的许可证字段显示 NOASSERTION，分发和商用前务必打开 LICENSE 文件确认。
- 备份、监控、故障恢复方案缺失。公开信息未说明备份、监控、故障恢复和容量管理方案，长期运行前自行补齐运维验证。
适合谁用：想降主库读压力、又不想在应用里写失效逻辑的团队
适合：希望降低 PostgreSQL 主库读取压力、又不想在应用代码里维护缓存失效逻辑的开发团队；读多写少、热点查询集中的业务。
不适合：无法启用逻辑复制、腾不出独立缓存数据库，或要求项目自带完整高可用运维方案的场景——先把这三项的答案准备好再立项。
一句话总结：pgcache 的价值在于”只复制热点、不复制全库”的一致性缓存，应用侧改个连接字符串就能接入。但它是个代理层组件，不是开箱即用的数据库：逻辑复制、独立缓存库、扩展版本三处都得自己运维。评估顺序别反：先 Fit Analyzer 看可缓存比例，再 Docker 跑通，最后才谈生产。
开源地址
GitHub 国内访问较慢，如打不开可多刷新几次
关注「软件教程管家」
回复软件名即取即下：网盘下载链接 + 提取码，一步直达，不用再跳转。
本站资源仅供个人学习交流，请勿用于商业用途。软件与资料版权归原作者所有；如有侵权，请通过公众号「软件教程管家」联系我们，我们将在 24 小时内下架处理。查看免责声明 ›
