我找到了一个商场。我可以在不登录的情况下将商品添加到购物车。添加几件商品后，我就可以付款了。需要先登录，登录后支付，现在很多商城都要求用户先登录，登录后才能将商品添加到购物车，这样用户、购物车、商品就形成了绑定关系三个物体之间。对于我一开始提到的情况，其实是基于session的。当客户端将第一个项目添加到购物车时，它会发送一个请求。服务端收到请求后创建session并返回当前session对应浏览器在cookie中保存一个JessionId，当客户端添加第二个商品到购物车时携带JessionId，服务端更新session收到请求后。浏览器关闭后cookie失效，JessionId丢失。您需要重新将商品添加到购物车。默认情况下，会话有效期为30分钟。在分布式环境下，session会出现问题，如果服务器部署在A和B两台服务器上，第一次添加商品到购物车时，请求落在A服务器上，A服务器创建session，返回JessionId。第二次向购物车添加商品时，请求落在了B服务器上，请求中携带JesssionId的请求不会在B服务器上找到对应的session，此时B服务器会新建一个session，并返回对应的JessionId。客户发现第一次添加的产品丢失了。..接下来，让我们学习如何在分布式环境中实现会话一致性。1.客户端存储由于在分布式环境中，一个客户端的多个请求可能会落在多个服务器上，我们是否可以改变策略，将会话信息直接存储在客户端上呢？是的，服务端直接将session信息保存在cookie中，这样可以保证session的一致性，但是不推荐这样做，因为将一些信息保存在cookie中，就相当于把这些信息暴露给客户端，客户端有严重的安全隐患。缺点：存在安全问题。Cookies对数据类型和数据大小有限制。2.会话复制将服务器A的会话复制到服务器B，同时也将服务器B的会话复制到服务器A，使两台服务器的会话一致。tomcat等Web容器支持session复制的功能。在同一个局域网内，一台服务器的会话会广播到其他服务器。缺点：同一网段的服务器过多，每个服务器都会复制session，造成服务器内存浪费。3、会话粘性使用Nginx服务器的反向代理代理服务器A和服务器B，然后使用ip_hash加载策略绑定客户端和服务器，也就是说客户端A第一次访问的是服务器B，然后第二次访问也一定是服务器B，所以不存在session不一致的问题。缺点：如果服务器A宕机，客户端A和客户端B的会话将丢失。4、集中会话管理这种方式是对所有服务器的会话进行统一管理。可以使用redis等高性能服务器来集中管理session，spring官方提供的spring-session就是这样处理session一致性问题的。这也是目前企业开发中使用的分布式会话方案。五、spring-session实战Spring提供了一个处理分布式会话的方案——SpringSession。SpringSession提供了用于管理用户会话的API和实现。SpringSession提供了对redis、mongodb、mysql等常用存储库的支持。SpringSession提供了与HttpSession的透明集成，这意味着开发者可以将HttpSession的实现与SpringSession支持的实现进行切换。还是原来的配方，做出不一样的味道！SpringSession增加了一个SessionRepositoryFilter过滤器来修改封装请求和响应。打包请求为SessionRepositoryRequestWrapper。在调用getSession()方法时，实际上是在调用SpringSession实现的session。SpringSession使用起来非常简单。添加相关依赖后，直接操作HttpSession即可达到效果。第一步：添加SpringSession和redis的相关依赖org.springframework.session
