在逛各大电商网站的时候，总会有将商品加入购物车，然后合并付款，这个大大的提高了用户的体验，某东更是任性，在未登录的情况下都可以将商品加入购物车，但是任性总是有代价的，后面我会说一下这个小bug。可能不算是个bug，但是体验上也有不爽的地方。

还是谈谈购物车是如何实现的吧，购物车首先标识要唯一，因为每个账号要对应一个购物车，在登录状态下，我们可以直接将数据保存到数据库中，使用用户的id表示自己购买的商品，但是如果在未登录状态下呢，或者对购车访问量大的时候，这个就存在弊端，因为这样高速的读写数据库，会对数据库的压力比较大，在这里我们就看看如何用Redis和RabbitMQ解决这个问题。

第一章：登录状态下添加商品到购物车

此时购物车是对应一个用户，很简单，就是将商品的数据插入数据库中即可，但是如果读写频繁的时候，就存在压力问题，此时我们可以使用Redis担任读的部分功能。

在向数据库中插入数据的时候，使用RabbitMQ发送消息，然后有一个消息系统监听消息，将RabbitMQ中消息内容(插入数据库中的商品数据)保存到Redis中，但是此时Redis中我们该用什么存储结构，在Redis中存储结构有很多种.

从上面的图我们可以看的出来，这个图有两个键，一个是外部键，一个是内部键，这个就体现了购物车的好处，这里外部键可以标记一个唯一的购物车，内部键就可以标记购物车上的一个商品，一个外部键可以对应多个内部键，这个和一个购物车里有多个商品是相符合的，在用户查询自己的购物车数据的时候，就不要到数据库中查询，而是直接从redis中将数据拿出来即可，这样数据库的读压力就被Redis分担出去了。

就这样把登录状态下购物车问题解决了。

第二章：未登录下加入购物车，登录下合并购物车

在未登录状态下，没有指定的用户，此时购物车应该怎么分配，数据把偶才能在什么位置，这个其实也不难，我们可以将数据临时保存到Redis中，并不插入数据库中，因为此时没有对应的用户，Redis生成一个唯一的outerKey，保存到cookie中，每次添加商品，带上这个cookie，这样就保证每次加入同一个购物车，这个数据会被保存一段时间，当用户登录的时候，我们该如何将未登录状态下的购车和登录状态下的购车数据合并呢。这个就需要使用到消息了，我们可以发送一个消息给后台系统，将未登录状态下的outerKey传递给后台系统，后台系统到Redis中查询到未登录状态下的购物车，将购物车中的数据插入到数据库中，和之前登录状态下的购车数据合并，重新缓存到Redis中，此时缓存到Redis中的购物车是和未登录状态不同的，因为这个缓存的购物车是有主人的，未登录状态下缓存的临时购物车是没有主人的。

小小bug的解析：

在开头我们曾说到未登录状态下加入临时购物车，登录后合并到登录用户的购物车中，接下来我看一下这个场景。

小王用小李的电脑逛商城，没有登录，将看中的商品加入到了临时的购物车中，小王还没有来得及登录自己的账号结算购物车，因有事出去了一下，此时小李回来了，他想到之前自己的购物车里还有商品需要付款，他就毫不犹豫的登录了自己的账号，这时候问题来了，小王之前临时购物车中的商品都会合并到小李的账户下，小李的购物车凭空出现自己未加入购物车的商品。过了一会小王回来了，发现自己临时购物车中的数据都没有了。这样是不是就存在用户体验的问题，俗称灵异事件，呵呵，开个玩笑。这种情况就导致了用户的体验不好了。

上面的问题我也想过解决方案，但是无果，求各路大神共同解决。

疑问解决：

1、Redis担任读的问题，当像双11这种大量访问的情况下，Redis会不会崩溃？

这个问题我也想过，这个我们可以考虑使用Redis的集群，这样就可以解决大部分的问题。

2、数据库也可以做读写分离，为什么要使用Redis担任读呢，直接使用读写分离不就可以了吗？

数据库的读写分离的确可以解决问题，但是像Redis这种非关系型数据库比较明显的优点就是数据处理效率高，读写分离和Redis的效率相比较来说，个人感觉还是使用Redis可靠。

3、在文章中提到RabbitMQ消息机制，这个到底怎么用？

这个吗，说来话长，在接下来的博文中我会慢慢的道来RabbitMQ的基本使用和RabbitMQ与spring的整合。

如果还存在什么疑问，很欢迎你回复本帖，大家一起讨论。

开发网站需要注意的安全方面的问题:http://www.360doc.com/content/13/0518/00/12136407_286230998.shtml

购物车相当于现实中超市的购物车，不同的是一个是实体车，一个是虚拟车而已。用户可以在购物网站的不同页面之间跳转，以选购自己喜爱的商品，点击购买时，该商品就自动保存到你的购物车中，重复选购后，最后将选中的所有商品放在购物车中统一到付款台结账，这也是尽量让客户体验到现实生活中购物的感觉。服务器通过追踪每个用户的行动，以保证在结账时每件商品都物有其主。

购物车的功能包括以下几项：

n 把商品添加到购物车，即订购

n 删除购物车中已定购的商品

n 修改购物车中某一本图书的订购数量

n 清空购物车

n 显示购物车中商品清单及数量、价格

实现购物车的关键在于服务器识别每一个用户并维持与他们的联系。但是HTTP协议是一种“无状态(Stateless)”的协议，因而服务器不能记住是谁在购买商品，当把商品加入购物车时，服务器也不知道购物车里原先有些什么，使得用户在不同页面间跳转时购物车无法“随身携带”，这都给购物车的实现造成了一定的困难。

目前购物车的实现主要是通过cookie、session或结合数据库的方式。下面分析一下它们的机制及作用。

1. cookie

cookie是由服务器产生，存储在客户端的一段信息。它定义了一种Web服务器在客户端存储和返回信息的机制，cookie文件它包含域、路径、生存期、和由服务器设置的变量值等内容。当用户以后访问同一个Web服务器时，浏览器会把cookie原样发送给服务器。通过让服务器读取原先保存到客户端的信息，网站能够为浏览者提供一系列的方便，例如在线交易过程中标识用户身份、安全要求不高的场合避免用户重复输入名字和密码、门户网站的主页定制、有针对性地投放广告等等。利用cookie的特性，大大扩展了WEB应用程序的功能，不仅可以建立服务器与客户机的联系，因为cookie可以由服务器定制，因此还可以将购物信息生成cookie值存放在客户端，从而实现购物车的功能。用基于cookie的方式实现服务器与浏览器之间的会话或购物车，有以下特点：

n cookie存储在客户端，且占用很少的资源，浏览器允许存放300个cookie，每个cookie的大小为4KB，足以满足购物车的要求，同时也减轻了服务器的负荷；

n cookie为浏览器所内置，使用方便。即使用户不小心关闭了浏览器窗口，只要在cookie定义的有效期内，购物车中的信息也不会丢失；

n cookie不是可执行文件，所以不会以任何方式执行，因此也不会带来病毒或攻击用户的系统；

n 基于cookie的购物车要求用户浏览器必须支持并设置为启用cookie，否则购物车则失效；

n 存在着关于cookie侵犯访问者隐私权的争论，因此有些用户会禁止本机的cookie功能。

2. session

session是实现购物车的另一种方法。session提供了可以保存和跟踪用户的状态信息的功能，使当前用户在session中定义的变量和对象能在页面之间共享，但是不能为应用中其他用户所访问，它与cookie最重大的区别是，session将用户在会话期间的私有信息存储在服务器端，提高了安全性。在服务器生成session后，客户端会生成一个sessionid识别号保存在客户端，以保持和服务器的同步。这个sessionid是只读的，如果客户端禁止cookie功能，session会通过在URL中附加参数，或隐含在表单中提交等其他方式在页面间传送。因此利用session实施对用户的管理则更为安全、有效。

同样，利用session也能实现购物车，这种方式的特点是：

n session用新的机制保持与客户端的同步，不依赖于客户端设置；

n 与cookie相比，session是存储在服务器端的信息，因此显得更为安全，因此可将身份标示，购物等信息存储在session中；

n session会占用服务器资源，加大服务器端的负载，尤其当并发用户很多时，会生成大量的session，影响服务器的性能；

n 因为session存储的信息更敏感，而且是以文件形式保存在服务器中，因此仍然存在着安全隐患。

3. 结合数据库的方式

这也是目前较普遍的模式，在这种方式中，数据库承担着存储购物信息的作用，session或cookie则用来跟踪用户。这种方式具有以下特点：

n 数据库与cookie分别负责记录数据和维持会话，能发挥各自的优势，使安全性和服务器性能都得到了提高；

n 每一个购物的行为，都要直接建立与数据库的连接，直至对表的操作完成后，连接才释放。当并发用户很多时，会影响数据库的性能，因此，这对数据库的性能提出了更高的要求；

n 使cookie维持会话有赖客户端的支持。

各种方式的选择：

虽然cookie可用来实现购物车，但必须获得浏览器的支持，再加上它是存储在客户端的信息，极易被获取，所以这也限制了它存储更多，更重要的信息。所以一般cookie只用来维持与服务器的会话，例如国内最大的当当网络书店就是用cookie保持与客户的联系，但是这种方式最大的缺点是如果客户端不支持cookie就会使购物车失效。

Session 能很好地与交易双方保持会话，可以忽视客户端的设置。在购物车技术中得到了广泛的应用。但session的文件属性使其仍然留有安全隐患。

结合数据库的方式虽然在一定程度上解决了上述的问题，但从上面的例子可以看出：在这种购物流程中涉及到对数据库表的频繁操作，尤其是用户每选购一次商品，都要与数据库进行连接，当用户很多的时候就加大了服务器与数据库的负荷。