外部缓存不可替代，1. PostgreSQL的shared_buffers和OS缓存虽能减小磁盘I/O，但高并发下仍需承担SQL解析、锁竞争等开销；2. 外部缓存如Redis可直接返回序列化结果，避免重复计算，支持分布式共享与细粒度控制；3. 多级缓存（L1本地、L2分布式、L3数据库）协同可提升响应速度并降低数据库压力；4. 通过写穿、失效或TTL策略保障一致性，结合逻辑复制实现最终一致。
很多人认为，只要数据库性能足够强，比如使用了高效的 PostgreSQL，缓存层就可以被绕过甚至省略。但实际上，即使 PostgreSQL 拥有强大的内部缓存机制（如 shared_buffers 和操作系统页缓存），外部缓存层依然不可替代。原因在于不同层级的缓存解决的问题不同，合理协同才能实现最佳性能。
PostgreSQL 自带缓存的能力与局限
PostgreSQL 通过以下两个主要机制实现数据缓存：
- shared_buffers：数据库实例级别的内存区域，用于缓存表和索引数据，减少磁盘 I/O。
- 操作系统页缓存：PostgreSQL 读取的数据也会被操作系统缓存，进一步提升后续访问速度。
这些机制确实能显著降低磁盘访问频率，但它们无法完全应对高并发场景下的热点数据访问压力。例如，当数千个请求同时查询同一个热门商品信息时，即便数据在 shared_buffers 中，每个请求仍需经过完整的 SQL 解析、执行计划生成、行锁检查等流程，带来不必要的 CPU 开销和连接竞争。
外部缓存的核心价值：减轻数据库负担
引入 Redis 或 Memcached 等外部缓存，目的不是“弥补”PostgreSQL 缓存的不足，而是将高频访问的热点数据从数据库中剥离出来。其优势体现在：
- 避免重复的 SQL 处理开销，直接返回序列化结果。
- 支持细粒度缓存控制，例如按用户、会话或接口维度缓存响应。
- 可实现分布式共享状态，适用于多应用实例部署场景。
- 提供 TTL、LRU 等策略，灵活管理数据生命周期。
以一个用户资料查询接口为例，若每次请求都走数据库，即使数据已在 shared_buffers 中，仍需执行查询解析和权限校验。而使用 Redis 后，可在首次查询后将 JSON 结果缓存 5 分钟，后续请求直接命中缓存，响应时间从毫秒级降至亚毫秒级。
缓存协同策略：分层设计更高效
理想架构应是“内外结合”的多级缓存体系，各层分工明确：
- L1：应用本地缓存（如 Caffeine）—— 存放极热数据，访问速度最快，但容量小且不共享。
- L2：分布式缓存（如 Redis）—— 共享缓存层，支撑多个服务实例，适合热点数据集中管理。
- L3：PostgreSQL 缓存（shared_buffers + OS cache）—— 底层保障，处理未命中上层缓存的请求。
这种结构下，系统优先尝试本地缓存，失败后再查 Redis，最后才落到数据库。数据库自身的缓存仍起作用，尤其对范围查询、复杂 JOIN 等无法轻易缓存的场景至关重要。
缓存一致性与更新策略
多层缓存带来的挑战是数据一致性。常见的应对方式包括：
- 写穿策略（Write-through）：数据更新时同步写入缓存和数据库，保证一致性。
- 失效策略（Invalidate on write）：更新数据库后主动删除相关缓存项，下次读取时重建。
- 设置合理 TTL：对容忍短暂不一致的场景，依赖过期自动刷新。
结合 PostgreSQL 的逻辑复制或触发器机制，还可以将数据变更事件推送至消息队列，异步清理或更新缓存，实现最终一致性。
基本上就这些。PostgreSQL 的缓存能力虽强，但不能替代外部缓存的角色。两者不是“谁更好”，而是“如何配合”。合理的缓存协同策略，能让系统在性能、扩展性和一致性之间取得平衡。
