单台服务器跑PrestaShop，Redis一装万事大吉。上了GCP自动扩缩容，噩梦才开始。

我维护的B2B店铺，30万SKU，日订单几百单。框架本身不是为分布式设计的，处处是坑。

打开网易新闻 查看精彩图片

800次查询的产品页

打开网易新闻 查看精彩图片

PrestaShop单页产品查询约800次SQL，分类页约2000次。不是bug，框架就这德行。

单机部署Redis缓存能糊弄过去。多节点？缓存同步成死结。

每个节点自建本地缓存。节点A 10:00缓存商品，节点B 10:02缓存同一商品，后台10:05改价——两个节点各自返回不同价格的老数据。

共享Redis？800次查询每页，每次网络延迟1ms就多耗近1秒。缓存比直接查库还慢。

我们的解法

不硬刚架构，绕过去。

Cloudflare粘性会话。用户落哪个节点，整会话钉死在那。用户视角无感知，节点间缓存不一致被隔离。

每节点本地Redis，TTL设10分钟。够快，无网络跳转。跟管理层对齐：商品描述最多延迟10分钟。B2B目录变动不频繁，接受。

表黑名单才是核心。触碰这些表的查询直落数据库：

购物车与会话——cart、cart_product、customer、guest、address。每点击都变。

订单与支付——orders、order_detail、order_history及支付网关表。财务数据不能旧。

打开网易新闻 查看精彩图片

库存——stock_available。显示错误库存比页面慢更糟。

分析数据——connections、page_viewed、log。写太频，会冲烂缓存。

第三方模块——涉及订单、心愿单、促销、折扣的。装新模块就检查表，加黑名单。这事没完。

配置表——configuration、configuration_lang。后台改设置需即时生效。

规则极简：10分钟内变动超过一次的表，进黑名单。

效果

缓存命中后：

产品页：800次→200-300次，降约65%

分类页：2000次→600次，降约70%

无分布式缓存。无失效逻辑。无延迟开销。粘性会话加本地Redis，够用了。