Cachex库中fetch函数可能多次执行fallback回调的问题分析

问题背景

在Cachex这个Elixir缓存库中，fetch/4函数是一个常用的功能，它允许开发者在缓存未命中时通过fallback回调函数自动生成并缓存值。按照设计预期，对于同一个键，fallback函数应该只执行一次，其他并发请求应该等待第一次执行的结果。

问题现象

通过测试发现，在某些特定的并发场景下，fallback函数可能会被多次执行。这会导致缓存一致性问题，特别是当fallback函数有副作用（如计数、写数据库等）时，会产生不符合预期的行为。

问题根源分析

这个问题本质上是一个经典的并发竞态条件问题。具体流程如下：

1. 多个进程同时调用fetch/4函数查询同一个不存在的键
2. 每个进程首先检查缓存，发现键不存在
3. 进程向Courier（调度器）发送请求
4. 在Courier处理这些请求的间隙，第一个任务可能已经完成并更新了缓存
5. 后续到达的请求由于在发送前缓存尚未更新，仍然会触发新的fallback执行

技术细节

Cachex的Courier模块是一个GenServer，它负责协调fallback函数的执行。虽然GenServer本身是串行处理消息的，但在以下时间间隙中可能出现问题：

• 客户端检查缓存和发送消息到Courier之间的时间窗口
• Courier收到消息和实际执行任务之间的时间窗口

解决方案

修复方案的核心思想是在Courier真正执行任务前，再次检查缓存状态。具体实现是在Courier的handle_call回调中，在准备启动新任务前增加一个缓存检查步骤：

1. 收到dispatch消息后，首先检查任务映射表
2. 如果已有任务在运行，将新调用方加入监听列表
3. 如果没有任务运行，再次检查缓存
4. 如果缓存已有值，直接返回
5. 如果缓存仍为空，才启动新任务执行fallback

影响评估

这个问题的实际影响取决于具体使用场景：

• 对于无副作用的fallback函数，影响较小，只是多消耗了一些计算资源
• 对于有副作用的fallback函数，可能导致数据不一致
• 在高并发环境下更容易触发此问题

最佳实践建议

在使用Cachex的fetch功能时，开发者应该：

1. 尽量保持fallback函数的幂等性
2. 避免在fallback中执行有副作用的操作
3. 对于关键业务场景，可以考虑在外层添加额外的同步机制
4. 关注Cachex的版本更新，及时获取修复

总结

Cachex的这个并发问题展示了分布式系统中常见的竞态条件挑战。通过深入分析问题根源，我们不仅找到了解决方案，也更好地理解了缓存一致性的复杂性。这个案例提醒我们，在设计高并发系统时，需要仔细考虑每一个可能的时间窗口和状态转换。