当 Commerce 后端运行多个Pods/节点时，当连续的请求过快到达时，后端将无法在集群中发送缓存失效通知。此外，如果多个请求分散到多个节点上，会产生延迟和不必要的资源消耗。
Spartacus 尽可能与单个后端进行交互，以服务于单个客户端。这通常被称为 sticky session.
Sticky session（粘滞会话）是一种负载均衡策略，用于在多个服务器之间分配客户端请求。在具有多个Java应用服务器的集群中，负载均衡器将客户端请求分发到不同的服务器上，以实现性能优化和高可用性。然而，这可能会导致一个问题：当一个客户端需要与特定服务器上的会话（例如，一个购物车或登录会话）进行交互时，由于负载均衡器将请求分发给不同的服务器，会话数据可能不会保持一致。
为了解决这个问题，引入了粘滞会话（sticky session）策略。粘滞会话策略确保同一个客户端的所有请求都会被分配到之前处理其请求的同一个服务器。这通常是通过将客户端的会话标识符（例如，JSESSIONID）与特定服务器关联来实现的。负载均衡器在将请求分发到服务器之前，会检查请求中的会话标识符，并将请求路由到与该标识符关联的服务器。
粘滞会话确保了会话数据的一致性，但可能导致服务器负载不均衡。如果一个服务器上的用户会话特别活跃，那么这个服务器的负载可能会变得很高，而其他服务器则相对较低。因此，在选择粘滞会话策略时，需要权衡会话数据一致性和负载均衡的需求。
CCv2在一定程度上为此做了准备。它在响应中添加了一个 ROUTE cookie. 然而，该cookie无法进行配置，并且没有SameSite策略。这意味着解耦的前端商店很可能无法使用它，因为它是在不同的域上操作。
为了启用 ROUTE cookie，必须执行以下操作：
- 在http客户端中使用withCredentials: true选项，以便在每个请求中发送cookie。
- 使用额外的CORS过滤器（Allow-Origin-With-Credentials:true）配置 Commerce backend，以确保cookie通过过滤器。