北京
单台服务器跑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，够用了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
