本文介绍: 写多读多、写多读少的场景,以 Redis 作为主存储通过 MQ 异步数据进行落库持久化如果存在读出来数据,并对读出来的数据进行修改的场景的话,就要考虑是否存在并发问题了,如果存在的话,要加分布式锁进行控制

社区电商购物车缓存架构

购物车中的功能主要有这几个:商品加入购物车查看购物车列表删除购物车商品选中购物商品进行结算

这里购物车的场景和之前用户信息以及菜谱分享信息不同,如果在举办了大型购物活动时,购物可能需要面临写多读少或者写多读多的场景,面临高并发的读和写,那么在购物车中就以 Redis 作为主存储异步的将数据进行落库持久化

商品加入购物

那么我们先来看一下商品加入购物车的业务场景,当将一个商品加入购物车,流程如下

商品加入购物车,首先需要判断,商品是否已经在购物车中存在了,那么就分了两种情况,如果商品在购物车中已经存在,我们需要去对购物车中该商品的数量 +1 ,然后缓存更新购物车里这个商品的信息最后发送更新消息到 MQ 中进行异步落库;如果商品在购物车中不存在,那么就直接去缓存添加购物车里该商品的信息,再发送持久化消息到 MQ 中进行落库

那么缓存需要存储的数据以及存储使用数据结构如下

那么添加购物车商品的流程如下

在这里插入图片描述

在 MQ 中订阅更新消息和持久化消息即可这里注意在订阅更新消息时,是更新用户购物车中的商品信息,那么有可能是增加商品的数量也有可能是减少商品的数量,所以在数据库我们判断,如果商品的数量更新后为 0 的话,就直接删除掉这条数据就好了

以及要做一些数据校验,如商品的数量最小值为 0,不可以为负数,这些都是业务层面上的考虑

这里的购物车存储架构使用 Redis 作为主存储,MySQL 作为持久化,那么如果 Redis 崩溃无法使用的话,MySQL 也可以作为一个备用存储,基于 MySQL 做一个降级处理,在 Redis 恢复时候可以数据库中的数据再重新加载到 Redis 中来

就算 Redis 中一些数据没来得及发送到 MQ 进行消息落库,影响也不大,购物车中的数据在未提交订单之前,本来就是临时数据,丢一个影响不大

查询购物车中商品

查询购物车中的商品的话,直接从 Redis 中进行查询,先按照商品加入购物车的时间查询出来所有的商品 id,再根据商品 id 去查询商品的详情,这个流程还是比较简单

购物车中的商品是根据加入购物车的时间加入到 zset 中去的,那么查询的话使用 zrevrange shopping_cart_zset:{userId} 0 -1 根据 score 获取从大到小排序的商品 id

再根据这些商品 id 去 Redis 的 hash 中查数据的商品的详情信息通过 hgetall shopping_cart_extra_hash:{userId}获取用户购物车中的所有商品信息,将这些商品信息返回即可

购物车中商品在缓存中的可视化存储结构下图

在这里插入图片描述

选中购物车中的商品

在商品实体类中,通过一个字段 flag控制该该商品是否选中了,如果选中该商品,就将 flag 设置为 1,如果取消选中,就将 flag 设置为 0

选中商品之后,直接在缓存更新该商品的详情即可,也就是对 key=shopping_cart_extra_hash:{userId}field={skuId} 的商品详情信息进行更新

总结

  • 写多读多、写多读少的场景,以 Redis 作为主存储,通过 MQ 异步将数据进行落库持久化
  • 如果存在读出来数据,并对读出来的数据进行修改的场景的话,就要考虑是否存在并发问题了,如果存在的话,要加分布式锁进行控制

原文地址:https://blog.csdn.net/qq_45260619/article/details/134757821

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任

如若转载,请注明出处:http://www.7code.cn/show_30086.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱suwngjj01@126.com进行投诉反馈,一经查实,立即删除

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注