<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>缓存 on 工程师手记</title><link>https://junozee.com/tags/%E7%BC%93%E5%AD%98/</link><description>Recent content in 缓存 on 工程师手记</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Wed, 12 Aug 2026 15:00:00 +0800</lastBuildDate><atom:link href="https://junozee.com/tags/%E7%BC%93%E5%AD%98/index.xml" rel="self" type="application/rss+xml"/><item><title>缓存一致性：先定义允许的不一致</title><link>https://junozee.com/posts/cache-consistency-tradeoffs/</link><pubDate>Wed, 12 Aug 2026 15:00:00 +0800</pubDate><guid>https://junozee.com/posts/cache-consistency-tradeoffs/</guid><description>&lt;p&gt;缓存一致性不是二元命题。对大多数业务来说，重要的不是“绝对一致”，而是明确：&lt;strong&gt;哪一类数据可以旧多久，哪一类操作绝不能错。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;商品详情允许数秒的价格展示延迟，库存扣减通常不能接受；报表看板可以异步刷新，支付状态必须有可追溯的最终结果。把这些边界说清楚，才有资格讨论 Cache Aside、延迟双删、消息驱动或版本号校验。&lt;/p&gt;&#10;&lt;p&gt;设计缓存时，我会先写下三条约束：&lt;/p&gt;&#10;&lt;ul&gt;&#10;&lt;li&gt;不一致的可见范围与最长时间；&lt;/li&gt;&#10;&lt;li&gt;缓存失效或穿透时的服务降级策略；&lt;/li&gt;&#10;&lt;li&gt;写入失败时的补偿、告警与人工介入方式。&lt;/li&gt;&#10;&lt;/ul&gt;&#10;&lt;p&gt;技术方案只是实现手段。先定义业务可承受的风险，缓存设计才会变得简单。&lt;/p&gt;</description></item></channel></rss>