單臺(tái)服務(wù)器跑PrestaShop，Redis一裝萬事大吉。上了GCP自動(dòng)擴(kuò)縮容，噩夢才開始。

我維護(hù)的B2B店鋪，30萬SKU，日訂單幾百單?？蚣鼙旧聿皇菫榉植际皆O(shè)計(jì)的，處處是坑。

800次查詢的產(chǎn)品頁

PrestaShop單頁產(chǎn)品查詢約800次SQL，分類頁約2000次。不是bug，框架就這德行。

單機(jī)部署Redis緩存能糊弄過去。多節(jié)點(diǎn)？緩存同步成死結(jié)。

每個(gè)節(jié)點(diǎn)自建本地緩存。節(jié)點(diǎn)A 10:00緩存商品，節(jié)點(diǎn)B 10:02緩存同一商品，后臺(tái)10:05改價(jià)——兩個(gè)節(jié)點(diǎn)各自返回不同價(jià)格的老數(shù)據(jù)。

共享Redis？800次查詢每頁，每次網(wǎng)絡(luò)延遲1ms就多耗近1秒。緩存比直接查庫還慢。

我們的解法

不硬剛架構(gòu)，繞過去。

Cloudflare粘性會(huì)話。用戶落哪個(gè)節(jié)點(diǎn)，整會(huì)話釘死在那。用戶視角無感知，節(jié)點(diǎn)間緩存不一致被隔離。

每節(jié)點(diǎn)本地Redis，TTL設(shè)10分鐘。夠快，無網(wǎng)絡(luò)跳轉(zhuǎn)。跟管理層對齊：商品描述最多延遲10分鐘。B2B目錄變動(dòng)不頻繁，接受。

表黑名單才是核心。觸碰這些表的查詢直落數(shù)據(jù)庫：

購物車與會(huì)話——cart、cart_product、customer、guest、address。每點(diǎn)擊都變。

訂單與支付——orders、order_detail、order_history及支付網(wǎng)關(guān)表。財(cái)務(wù)數(shù)據(jù)不能舊。

庫存——stock_available。顯示錯(cuò)誤庫存比頁面慢更糟。

分析數(shù)據(jù)——connections、page_viewed、log。寫太頻，會(huì)沖爛緩存。

第三方模塊——涉及訂單、心愿單、促銷、折扣的。裝新模塊就檢查表，加黑名單。這事沒完。

配置表——configuration、configuration_lang。后臺(tái)改設(shè)置需即時(shí)生效。

規(guī)則極簡：10分鐘內(nèi)變動(dòng)超過一次的表，進(jìn)黑名單。

效果

緩存命中后：

產(chǎn)品頁：800次→200-300次，降約65%

分類頁：2000次→600次，降約70%

無分布式緩存。無失效邏輯。無延遲開銷。粘性會(huì)話加本地Redis，夠用了。