跨FPM与Supervisor Worker独立容器的内存缓存失效管理

一、当前方案的合理性判断 #

当前基于FPM+Nginx的内存缓存方案在FPM核心业务环境是合理的——它确实能有效降低Redis访问量，提升请求响应速度。但Supervisor Worker容器场景下的缓存一致性问题，是跨容器进程内缓存的典型痛点，会导致Worker侧出现脏读、数据不准确的情况，这一缺陷拉低了整体方案的合理性，必须针对性优化。

二、核心问题拆解 #

• 重复查询问题：foreach循环中重复数据触发多次查询，本质是内存缓存的前置处理不到位，和容器环境无关，属于可优化的通用问题。
• 跨容器缓存一致性问题：Worker与应用分属不同容器，进程内内存缓存相互隔离，依赖事件分发删除缓存存在延迟，甚至可能因消息丢失导致脏缓存长期存在。

三、具体优化方向 #

1. 解决重复查询问题 #

• 循环前先对数据去重，批量查询后映射回原列表，从根源减少查询次数。示例伪代码：

// 提取唯一IATA代码
$uniqueIatas = array_unique(array_column($flights, 'airline_iata'));
// 批量查询并以IATA为键整理结果
$airlineInfo = Airline::whereIn('iata', $uniqueIatas)->get()->keyBy('iata');
// 循环映射数据
foreach ($flights as $flight) {
    $flight->airline = $airlineInfo[$flight->airline_iata] ?? null;
}

• 统一内存缓存的键规则，确保相同数据的缓存键全局一致，即使循环内触发查询也能直接命中缓存。

2. 解决跨容器缓存一致性问题 #

• 替换Worker侧内存缓存：将Worker的缓存层统一到Redis，虽然会增加Redis访问量，但能从根本保证缓存一致性，适合对数据准确性要求高的场景。
• 优化事件分发可靠性：使用RabbitMQ这类可靠消息队列替代简单事件分发，确保ForgetMemoryCache事件100%投递到Worker；同时给Worker的内存缓存添加自动过期兜底策略，即使事件丢失，脏缓存也能在设定时间内自动清理。
• 共享内存备选方案：若容器部署在同一宿主机或K8s同节点，可尝试PHP的shmop扩展实现共享内存缓存，但这种方式扩展性差，不适合分布式集群场景。

四、最终建议 #

如果业务对数据一致性要求极高，建议调整Worker侧缓存策略，将进程内内存缓存替换为Redis缓存，以少量性能损耗换取数据准确性；若业务能接受短时间脏数据，且能优化事件分发的可靠性，可以保留当前方案，同时优先解决重复查询问题。

内容的提问来源于stack exchange，提问作者Iman Parvizi