當(dāng) Commerce 后端運行多個Pods/節(jié)點時,當(dāng)連續(xù)的請求過快到達(dá)時,后端將無法在集群中發(fā)送緩存失效通知。此外,如果多個請求分散到多個節(jié)點上,會產(chǎn)生延遲和不必要的資源消耗。
Spartacus 盡可能與單個后端進(jìn)行交互,以服務(wù)于單個客戶端。這通常被稱為 sticky session
.
Sticky session(粘滯會話)是一種負(fù)載均衡策略,用于在多個服務(wù)器之間分配客戶端請求。在具有多個Java應(yīng)用服務(wù)器的集群中,負(fù)載均衡器將客戶端請求分發(fā)到不同的服務(wù)器上,以實現(xiàn)性能優(yōu)化和高可用性。然而,這可能會導(dǎo)致一個問題:當(dāng)一個客戶端需要與特定服務(wù)器上的會話(例如,一個購物車或登錄會話)進(jìn)行交互時,由于負(fù)載均衡器將請求分發(fā)給不同的服務(wù)器,會話數(shù)據(jù)可能不會保持一致。
為了解決這個問題,引入了粘滯會話(sticky session)策略。粘滯會話策略確保同一個客戶端的所有請求都會被分配到之前處理其請求的同一個服務(wù)器。這通常是通過將客戶端的會話標(biāo)識符(例如,JSESSIONID)與特定服務(wù)器關(guān)聯(lián)來實現(xiàn)的。負(fù)載均衡器在將請求分發(fā)到服務(wù)器之前,會檢查請求中的會話標(biāo)識符,并將請求路由到與該標(biāo)識符關(guān)聯(lián)的服務(wù)器。
粘滯會話確保了會話數(shù)據(jù)的一致性,但可能導(dǎo)致服務(wù)器負(fù)載不均衡。如果一個服務(wù)器上的用戶會話特別活躍,那么這個服務(wù)器的負(fù)載可能會變得很高,而其他服務(wù)器則相對較低。因此,在選擇粘滯會話策略時,需要權(quán)衡會話數(shù)據(jù)一致性和負(fù)載均衡的需求。
CCv2在一定程度上為此做了準(zhǔn)備。它在響應(yīng)中添加了一個 ROUTE cookie
. 然而,該cookie無法進(jìn)行配置,并且沒有SameSite策略。這意味著解耦的前端商店很可能無法使用它,因為它是在不同的域上操作。
為了啟用 ROUTE cookie
,必須執(zhí)行以下操作:
在http客戶端中使用withCredentials: true選項,以便在每個請求中發(fā)送cookie。
使用額外的CORS過濾器(Allow-Origin-With-Credentials:true)配置 Commerce backend,以確保cookie通過過濾器。
聯(lián)系客服