PostgreSQL 18进阶指南：用原生方案替代Redis构建无缓存架构
关于缓存，我的立场并非全盘否定。当你需要处理跨请求协调、速率限制，或是在不同服务间进行扇出扇入操作时，缓存或消息总线依然是可行的解决方案。我只是在那些因其掩盖优化器错误、增加查询波动性的场景中将其剔除。一个坦诚的分享：我曾尝试通过降低 synchronous_commit 参数来提升性能，但最终还是撤销了这项调整——对这条路径而言，写入语义层面的风险实在不值得冒险。
我在生产环境中停用了 Redis，并且从未回滚这一决定。”
每当想起这句话，我内心仍然会感到一阵紧张——毕竟缓存就如同系统的一条安全绳。但在 PostgreSQL 18 上经过大量谨慎测试后，p95 响应时间显著下降，系统架构更加简洁，值班团队的压力也随之减轻。
风险是真实存在的：用户会话、结算流程、我们的口碑信誉。
收益同样是真实的：更少的活跃组件、更少的告警短信。
下面我将分享自己的实践历程：我优化过的查询语句、关于唯一键的示意图，以及几个起到关键作用的小配置。
一、关闭缓存开关那一天
我们的热路径是一个参数化的产品查询，并附带一定的个性化特征。
缓存确实帮我们提高了命中率，但未命中的情况却相当棘手，而且序列化操作还额外增加了工作量。
我对这条路径进行了端到端的分析，随后尝试了一个更直接的数据库方案——使用更紧凑的索引和预先计算好的投影。
第一次运行结果令人心惊胆战……但随后数据逐渐稳定下来。
我让缓存停用了一个完整周期，见证了图表曲线最终趋于平静的过程。
二、Postgres里到底发生了什么
没有深奥的玄学，只有两件落地的事情：
1、覆盖度与选择性
覆盖索引配合生成列，让优化器能够只获取我们需要的字段，不再触及堆表。
2、预计算形态
物化视图（支持并发刷新）将原先依赖缓存隐藏的高昂聚合计算任务承接了过来。
PostgreSQL 18 凭借更智能的执行计划以及可预测的I/O完成了其余工作。
三、那个让Redis变得多余的查询
下面的表结构映射了一条常见的Feed流或目录切片场景：商品信息、软删除标识、新鲜度标记、个性化键值。
重点不在于字段名称，而是"生成列+覆盖索引"的组合完美匹配了返回结果。
应用程序调用随后变成了单次往返：
简而言之：规划器停留在索引层面，堆表保持"冷状态"，视图从热路径中移除了沉重的聚合操作。
四、从源头削减延迟
两个小的配置调整起到了重要作用。它们并非万能药，但确实让I/O保持稳定，并使优化器能够可靠地利用索引和并行性。
如果你在更快的本地NVMe上运行，设置较低的random_page_cost能保持索引扫描的吸引力。track_io_timing则会在你对自身磁盘性能判断有误时给出提示。
五、我是如何测量的
我运行了一个简单的客户端，它发出了我们通常会缓存的那组参数。下表来自我的测试环境，经过3次预热运行，显示的是中位数数据。网络跳数和序列化开销比人们预期的要多得多。
在我们的信息流端点测试中，直接的数据库路径击败了缓存未命中情况下的尾部延迟，同时消除了命中与未命中之间的悬崖式差距。那个差距过去常常出现在用户追踪记录和支持工单中。
六、前后对比，用ASCII图绘制
一个说服团队的过程流程图：
我们仍然保留了只读副本以确保安全，但热路径现在只有一个依赖项。
七、何时缓存仍然占优
我并不是反对缓存。如果你需要跨请求协调、速率窗口，或者是跨服务的扇出扇入操作，缓存或消息总线仍然有其用武之地。我只是在它掩盖了优化器错误并增加了方法差异的地方将它移除了。一个诚实的承认：我曾尝试通过降低synchronous_commit来榨取更多性能，但后来撤销了，因为对于这条路径来说，写入语义的风险不值得去冒。
八、我保留的可直接复用的更改
这些是实验结束后保留的两个应用层面的部分。
1、应用查询形态（SQL预处理语句），而非ORM猜测
参数顺序稳定的预编译语句使得执行计划稳定且解析迅速。它们也明确了需要什么索引。前面的代码块展示了fetch_slice和fetch_trending；那就是实际部署的代码。
2、适度、常规的刷新节奏
刷新mv_trending的作业每隔几分钟运行一次，使用CONCURRENTLY以保持读取端的流畅。没有复杂的cron技巧，没有失效风暴。
九、这对你的团队意味着什么
如果你的缓存只是为了掩盖源站慢读，请先尝试修复源站。
将查询完整覆盖，只预计算真正昂贵的部分。
关注p95分位点，别看平均值。
如果直接走数据库能击败缓存未命中的长尾，并减少运维痛苦，就让更简单的架构胜出。
作者│The Atomic Architect 编译│Rio
来源│网址：https://medium.com/@the_atomic_architect/postgresql-18-killed-my-cache-layer-and-i-am-not-bringing-it-back-764496b2a9a5
相关攻略
面试中被问到“Redis为什么这么快”，很多人的第一反应是“因为它是基于内存的”。这个答案正确，但只触及了最表层的原因。面试官点头后继续追问“还有呢？”，往往会让回答者陷入沉默。 实际上，Redis的高性能是一个系统工程，是多个精妙设计层层叠加、共同作用的结果，缺少任何一环，其速度都可能大打折扣。今
在统信UOS操作系统上部署Redis数据库，根据不同的应用场景与技术要求，通常有三种主流方案可供选择：一是通过APT包管理器进行快速安装，操作简便高效；二是通过源码编译进行定制化安装，实现对版本与功能的精准控制；三是通过systemd进行服务托管与集成，满足企业级生产环境的运维管理需求。这三种方法优
在 NET Aspire 框架中集成 Redis 的核心流程可概括为三个关键步骤：安装 Aspire Hosting Redis 组件包、通过 AddRedis( "cache ") 方法声明资源、在业务服务项目中借助 WithReference(cache) 和 GetConnectionStrin
在统信UOS系统上安装Redis主要有三种方法。使用APT包管理器安装最为简便，适合网络良好的环境。通过源码编译安装则能自定义版本和功能，适用于特定需求或离线环境。若采用源码安装，还需手动创建systemd服务单元文件，以便将Redis纳入系统服务进行统一管理。
缓存击穿需组合防御，分布式锁仅为其中一环。正确使用Redisson锁需明确触发条件、锁定对象、持有时间及失败兜底。避免直接使用RLock lock()，应采用tryLock配合双重检查，并显式设置等待与持有时间。解锁必须通过unlock()方法，且需结合过期时间随机化与空值缓存，从源头分散失效风险。锁是兜底手段，而非首要防线。
热门专题
热门推荐
比特币匿名交易指南：原理、方法与关键注意事项 提到比特币，很多人第一反应是“匿名”。但真相是，比特币交易在区块链上公开记录，其本质是“化名”而非完全匿名。这意味着，只要采取恰当的方法，完全可以将交易隐私提升一个层级。本文将系统梳理实现比特币匿名交易的几种实用方法，并为你提供相关可信工具的官方获取途径
PowerLawGLM：法律领域的AI“专家” 在人工智能大模型深刻变革各行各业的今天，法律这一专业壁垒高、知识体系复杂的领域，也迎来了其专属的智能解决方案。由幂律智能与智谱AI联合推出的PowerLawGLM，是一款拥有千亿级参数、专为中文法律场景深度优化的垂直大模型。它本质上是一位经过海量法律文
新SSR比斯塔天赋可叠加“蔷薇花刺”，三层后目标无法复活，有效克制副本复活机制。其技能多为全体伤害，适合PVP竞技场。闪避可减敌怒气，暴击能回复生命，兼具续航与干扰能力。终结技提升闪避，配合额外魂玉实现连招。奥义击倒目标后可回血，增强生存能力。
手游《代号：逍遥游》即将上线，以“选择”为核心玩法。玩家将在宏大仙侠世界中，面对飞升或逆天等不同道路，通过自身决策破解宿命迷局，体验多线命运走向。
在《方舟：生存进化》中，探险者笔记是揭示世界秘密的关键物品。可通过探索地图角落、完成特定任务、与NPC互动、寻找隐藏地点以及参与游戏内特殊事件等多种途径获取。收集过程融合了探索、解谜与社交，集齐笔记不仅能获得经验加成，更能深入理解游戏世界的背景与故事。