基于redis购物车

基于redis的购物车流程（不是很详细）

请勿喷哦！！
>_<

我在之前的项目中，做过购物车的功能，当时从表设计到最后用postman进行接口的测试，都是我负责做的。

考虑到用户操作购物车的性能问题，我当时做的是基于redis的购物车，将购物车的所有数据都存储到redis中。

当时用了redis中的hash结构来存储所有用户购物车的数据，咱们都知道在使用hash的时候，涉及到key,field,value这三个方面的参数信息，key这块我用了 CartInfo/CartMap/CartData 这个固定的字符串来表示，在field这块为了能够表示不同用户的购物车，我用来 member:会员id:cart/member:会员id/cart:会员id 来表示，在value这块我是把会员对应的整个购物车的信息都转换为Json格式进行了存储。整个购物车对应的数据结构是这个样子的。

购物车中包含商品总件数，总价格，以及购物车的商品项列表，在商品项中包含商品id,商品名，商品单价，商品件数，商品图片，商品小计等，这里面特别要注意的就是关于价格这块在java中要用bigDecimal这个数据类型，这样可以防止精度丢失。

只有会员登录后才能操作购物车，比如添加商品，删除商品等。关于登录这块，我采用的是基于token的用户登录，类似于自己写了一个jwt【java web token】。

这样用起来更加的灵活方便，在自定义的拦截器中，当通过了层层关卡的验证后，将会员信息存入到request中，这样在其他的控制层方法中就可以通过request来获取当前登录的用户信息。为了方便在每个控制层方法中获取会员信息，我采用了 spring中自定义的参数解析器，这样就避免了在每个控制层方法中都使用requst.getAttribue来获取会员信息，而是在自定义的参数解析器中写一遍即可。

具体我是这样做的，自定义了一个实现HandlerMethodArgumentResolver接口的参数解析器类，这里面最主要有两个方法，supportsParameter和resolveArgument，在supportsParameter中我通过methodParameter获取参数的类型和我自定义的会员类进行对比如果相等则返回true,证明找到了会员类型的参数，当返回true时就会走resolveArgument方法，在该方法中，通过request.getAttribute()获取拦截器中存入的会员信息，并将其强转为指定的会员类，进行返回。最后要想使自定义的参数解析器生效，则需要在spring-mvc的配置文件中配置mvc:annotation-driven，并在其中配置mvc:argument-resolvers，通过bean class指定自定义的参数解析器类，这样就可以在控制层的各个方法中，直接写上会员类参数，就可以通过会员类获取其中的会员id等信息。

这里面涉及到添加商品到购物车的业务逻辑是这样的。这个接口方法接受3个参数，其中商品id和商品个数是直接从前台传过来的，而会员类则是通过自定义的参数解析器来完成赋值的。首先我会根据商品id判断该商品是否存在，如果不存在则提示商品不存在的信息，如果存在则需要判断该商品的状态是否正常，比如是否是上架状态，如果状态是下架则提示该商品已经下架。

经过这些验证后，我会判断该会员在redis中是否有对应的购物车信息，是通过封装的工具类redisUtil中的hget来获取的，如果该会员对应的购物车信息为空，则首先要创建购物车，并且将当前商品添加到购物车中，最后还要计算购物车中的总件数和总价格，通过阿里巴巴的fastjson将其转换为json格式，并通过我封装的redisUtil的工具类hset方法，将其存入到redis中的hash结构里。

如果会员对应的购物车信息不为空，则分情况进行处理。首先看看该商品是否已经在购物车中了，如果是，则找到该商品并更改商品的数量为商品原有的数量加上前台传过来的商品的数量，还要重新计算该商品的小计，以及重新计算整个购物车中商品的件数以及总价格，最后更新redis中的数据。

如果该商品不存在购物车中，则将该商品加入会员的购物车，并重新计算整个购物车中商品的件数以及总价格，最后更新redis中的数据。

这就是整个往购物车中添加商品的逻辑，至于减少商品的个数，完全可以使用和添加商品一样的方法，只不过传过来的商品的个数为负数就行了。

而且还有一些小细节，就是如果不断的减少商品个数，当商品个数减少到零的时候，就将该商品一并从购物车中删除掉。当购物车中所有的商品都被删除的时候，也同时删除整个购物车。最后都得更新redis。

请勿喷哦！！

>_<