关于购物车添加商品何时持久化的讨论

[selrain]

有 2 个问题：
1、限购商品在购买的时候会减掉已经购买的订单量吗？比方说 A 商品限购 3 件，已经买了 1 件，那么是不是下次只可以买 2 件？
2、添加购物车的商品何时入库？ 目前认为用户点击添加购物车的按钮就入库？但是这种不停的往后台请求压力会有点大。
还有一种就是前端缓存下数据，合适的时机再统一发送给后台，“合适的时机”是什么时候也没确定好

[airyland]

1.是，用当前订单 quantity + 历史订单 quantity <= 限购数量 来做检验。
2.直接入库。你想多了，可以说这基本没有什么压力的。防止恶意操作对单个用户加 ratelimit 就行了。

[yulitian888]

1、显然是，否则限购可以被轻易绕过还有何意义？
2、请求压力大么？大么？大么？嫌大了加服务器啊，谁规定只能用一个数据库实例了？
再说，有人恶意增加压力的话，去商品下面去刷评论不是来得更快么？加购物车那点压力怎么不算啥

[also24]

1、有这个疑问，应该是 产品 /运营需求 不明确导致的，限购分好几种：
a. 单 用户 /支付账户 /真人 限购（例如新人特惠商品）
b. 单 订单 限购（例如最近各家的 19.9 车厘子）
c. 从单纯限购拓展出的 首单特价 /折扣 or 首件特价 /折扣

具体采取哪一种限购，应该是从 产品 /运营需求 方面先明确好才对

2、这个怎么做都行，见仁见智。
项目小的话直接读写应该都没啥问题，反正后端那边自己也有读写缓存。
复杂点儿的我觉得 前端 先合并一下短时间（秒级）内的请求，Web 服务器 限制一下接口频率，后端再加个简单的限速，应该就足够应付大部分情况了。

[also24]

似乎上一条回复中所有的"/"前都被加了空格，是在半角字符和全角字符之间强行加了分隔么？

测试：这,是.一-段 /没+有=空 a 格 1 的|话

[winglight2016]

一般来说，每次进入购物车页面的时候，都需要从后台重新获取购物车数据（获取购物车数据），其他页面加入购物车的时候，也是从后台接口（添加到购物车接口）返回实际数据，所以：
1.提交订单后，后台会把购物车中的相应商品从购物车删除
2.添加商品到购物车如果碰到限购超额，返回数据里面应该包括相关提示，由前端根据具体情况判断是否显示这条消息
3.关于缓存，只有在非购物车界面才会使用本地缓存——但是跳转页面时会根据具体情况判断是否要刷新购物车数据
以上所谓的具体情况，应该由产品经理确认处理逻辑

[DeutschXP]

- 关于限购数量，有两种方法：一是只在结账的时候判断，这种简单。另一种是放入购物车就先检测判断一次，这种会适当增加服务器开销，但可以通过缓存优化。但即便已经先判断一次，在结账时还是需要判断一次的。所以先判断一次仅仅是为了提高用户体验。

- 关于入库的问题，如果你的商品库存充足，也就是一般销售场景，那么何时入库都可以。就按最简单的方法就好，结账才入库。
如果是需要抢购的，类似于秒杀，几种方法：
1. 简单的就是结账时才入库，用户体验会差一些，因为放入购物车不一定购买成功。但如果只是用于单件商品抢购，推荐使用这种方法，也增加趣味性，因为抢购秒杀，就是比谁的手快，所以结账输入地址等信息这些都应该作为比快的环节。
2. 如果是多个商品抢购，那么放入购物车就应该入库，但增加超时时间。譬如可以设置普通会员 15 分钟超时，VIP 会员 30 分钟超时，白金会员 60 分钟超时。这种方法，与后台的通讯会增加一些些的服务器开销，但可以忽略。主要的压力是在于用户会不停的刷新页面，检查是否有其他用户释放的商品。
所以进一步的做法是，增加排队名单，用户没有抢到东西，自动加入排队名单，会自动定时检测位置，避免了用户手动刷新，也提高了用户体验。

[selrain]

@DeutschXP 结账时入库，结账的时候不是要把购物车的数据清理了么

[also24]

@selrain #7
你问题里的 “入库” 指的是 “将购物车数据存入后端数据库” （讨论的是频繁读写购物车数据的问题）
他的 “入库” 指的是 “购买成功时核减库存” （讨论的是何时变更库存的问题）

不在一个频道上

[selrain]

@also24 😂 是我理解错了么

[wangdu2012]

这有什么好讨论的…