4. 缓存一致性模型：强一致性、最终一致性、弱一致性在 Ent 场景下的选择
在 Ent 搜索缓存闭环中，缓存一致性模型决定了数据写入后，缓存何时对搜索请求可见。选择错误的模型会导致搜索结果不一致、用户体验下降或系统吞吐量骤降。本节从 Ent 搜索的读写路径出发，对比三种核心一致性模型，并给出选型建议。
4.1 三种一致性模型的定义与 Ent 映射
| 模型 | 核心定义 | Ent 场景映射 | 典型延迟 |
|---|---|---|---|
| 强一致性 | 写入完成后，后续所有读操作立即看到最新值 | Ent 节点更新后，搜索缓存必须同步刷新，查询结果与数据库完全一致 | 高（需等待所有副本确认） |
| 最终一致性 | 写入后不保证立即一致，但经过足够时间后所有副本收敛到相同值 | Ent 更新写入主库，缓存异步失效或延迟刷新，搜索可能短时读到旧数据 | 低（异步处理） |
| 弱一致性 | 写入后不保证任何后续读操作能看到新值，直到显式同步 | Ent 更新后不主动通知缓存，依赖定时全量重建或手动触发 | 极低（无同步开销） |
关键权衡： 强一致性保证搜索准确，但会降低写入吞吐并增加缓存失效延迟；最终一致性在大多数 Ent 搜索场景中提供“足够好”的体验，且系统吞吐更高。
4.2 强一致性在 Ent 场景下的实现与代价
强一致性要求 Ent 写入操作在返回成功前，必须确保搜索缓存已经更新或失效。常见实现方式：
- 同步双写： 应用层在更新数据库后，同步更新搜索缓存（如 Redis 或 Elasticsearch 索引），全部成功才返回。
- 缓存失效 + 读修复： 写入后立即删除缓存键，下次搜索请求回源数据库并重建缓存。
- 分布式锁 + 版本号： 写入时获取全局锁，缓存携带版本号，读请求校验版本一致性。
Ent 场景避坑： 强一致性在跨地域部署或高并发写入时，容易导致缓存雪崩——大量缓存同时失效，所有请求穿透到数据库，引发连接池耗尽。建议仅在核心元数据（如 Ent 唯一标识、状态字段）上使用强一致性，非关键字段使用最终一致性。
4.3 最终一致性：Ent 搜索的主流选择
最终一致性在 Ent 搜索缓存闭环中应用最广，因为它平衡了搜索时效性与系统吞吐。典型实现路径：
- 写入 Ent 数据库（主库成功即返回客户端）。
- 异步发送缓存失效消息（通过消息队列，如 Kafka / RabbitMQ）。
- 缓存消费者处理失效，删除或更新对应缓存键。
- 搜索请求命中缓存：若缓存未更新，返回旧数据；若已更新，返回新数据。
- 收敛时间窗口：通常控制在 100ms ~ 5s 内，取决于消息队列延迟和消费速度。
Ent 最佳实践： 为每个缓存键设置 TTL（如 60s），即使消息丢失，缓存也会自动过期并回源数据库，保证最终收敛。同时配合“读时校验”策略：搜索请求读取缓存后，异步对比缓存版本与数据库版本，不一致时触发修复。
4.4 弱一致性：何时用于 Ent 搜索
弱一致性几乎不做同步保证，适用于非关键搜索场景：
- Ent 标签/分类统计： 搜索结果的计数、聚合值允许短时偏差。
- 推荐列表： 个性化推荐结果允许数分钟甚至数小时的滞后。
- 历史归档数据： 已归档的 Ent 记录不再变更，弱一致性等同于最终一致性。
弱一致性通常配合定时全量重建（如每 10 分钟重建一次搜索索引）或手动触发刷新按钮使用。
4.5 一致性模型选型决策树
4.6 混合模型：Ent 场景下的最佳实践
实际生产环境中，单一一致性模型无法满足所有 Ent 搜索需求。推荐按字段粒度分层：
| Ent 字段类型 | 推荐模型 | 实现方式 | 示例 |
|---|---|---|---|
| 标识字段（ID、Slug） | 强一致性 | 写入后同步删除缓存，读时回源 | Ent 详情页 URL 参数 |
| 状态字段（上架/下架、审核） | 强一致性 | 分布式锁 + 版本号校验 | 商品上下架状态 |
| 搜索属性（标题、描述、标签） | 最终一致性 | MQ 异步更新搜索索引 | 全文搜索匹配 |
| 聚合字段（销量、评分、评论数） | 最终一致性 | 异步累加 + 定时刷入缓存 | 搜索结果排序因子 |
| 推荐权重、个性化分数 | 弱一致性 | 定时全量重建 | 首页推荐列表 |
核心原则： 离用户决策越近的字段（如价格、库存状态），一致性要求越高；离用户决策越远的字段（如推荐排序、标签云），越可以放宽一致性要求。Ent 搜索缓存闭环的稳定性，取决于能否在关键路径上保证强一致，在非关键路径上容忍最终一致。