经典项目应用场景分享-下

上一章中讲到项目开发中实际应用场景，我们应该如何进行设计，今天接着上一章的内容，我们继续来讲叙。

想学习分布式、微服务、JVM、多线程、架构、java、python的童鞋，千万不要扫码，否则后果自负~

场景应用

1.商品规格设计问题

业务背景： 每一个商品都需要关联一个三级分类，每一个三级分类都会关联一个规格属性模板。因为商品-分类-规格属性模板-规格-商品价格，所以如果规格属性模板中的规格发送变化，就会导致商品获取价格的时候出错。

技术实现：

方案一： 在修改规格的时候，判断此规格是否绑定规格属性模板，如果是，则查询此规格属性模板是否被使用，如果被使用则不能删除，除非将所有关联此模板的商品取消关联。

方案二： 在修改规格的时候，判断此规格是否绑定规格属性模板，如果是，则查询此规格属性模板是否被使用，如果被使用则下架所以关联到此模板的商品。

方案三： 分类不直接绑定规格属性模板，而是绑定规格属性模板的快照，这样就可以避免上述的问题了。

2.多状态问题

业务背景： 用户交易记录中存放多种类型的提现记录，但是查询类型只有一种，无法进行区分（用户交易记录，存放所有的交易记录，例如：支付、退款、提现、充值等）。

技术实现： 设计字段的时候不要只用一个字段来区分所有的类型，最好用多个字段来区分，例如提现可以加上一个渠道，从商品分销账户这个渠道，进行提现操作。

3.用户注册产生多条注册数据

业务背景： 在高并发情况下，用户注册产生多条重复数据。

技术实现： 首先注册流程一定要简单，可以将耗时的操作放在MQ中执行，尽量保证注册的流畅性。还有数据流一定要短，不要发生A-》B-》C-》D这么长的微服务调用，如果这样，有很大可能A会被熔断掉，造成错误重试。最重要的一条：注册接口一定要做成幂等，否则就会出现上述所说的，出现重复数据问题。

4.对接第三方问题

业务背景： 用户资金相关的操作需要对接第三方支付公司，所以就涉及到接口互调问题，比如用户开户审核，第三方公司需要将审核结果推送给我们。

技术实现： 首先任何和第三方对接的接口都需要将请求日志和返回值记录下来，方便以后追踪查看问题。比如上面提到用户开户问题，对方将审核结果推送给我们的时候，需要记录下返回值，我们也需要主动去查询审核结果。最后还要定期扫描长时间没审核的记录，主动去获取审核结果或者找对方客服进行咨询。

5.供应商入住问题

业务背景： 供应商入驻需要进行基础资料审核和财务审核，所以入驻的状态就分为多种：待提交、基础资料待审核、基础资料审核不通过、基础资料审核通过、财务待审核、财务审核不通过、财务审核通过（入驻成功），审核不通过跳转页面出错。

技术实现： 首先要确定具体有多少种状态，每一种状态可以做的事情。千万不要用一种状态来区分这些状态（例如1是待提交、2是已经提交等等），最好采用多字段的标识，基础资料审核状态、财务审核状态。

还需要注意的是，审核不通过页面跳转地址也需要和前端商量好，比如基础资料审核不通过跳转到资料提交页面，财务审核不通过跳转到支付页面等。基础资料提交页面最好做成分步骤操作并添加保留草稿的功能，这样可以有效的提高用户体验。

6.供应商财务结算问题

业务背景： 平台需要定期将已经确认收获的订单结算给供应商，供应商可以申请提现，运营平台需要对申请进行审核，审核通过则可以提现（通过其实就是从总账转账给供应商账户）。但是这对审核人员的工作量会特别大，也可能存在失误的风险。

技术实现： 要有一个对账程序，定期去和第三方支付公司进行账户对账，如果账户出现问题，则推送给相关人员，如果对账没有问题，数额比较小的情况下，可以直接程序审核通过，如果数据比较大的情况下，可以程序+人工审核。

7.订单下单问题

业务背景： 商品下单的时候会生成一个待支付的订单，同时商品的库存会对应的扣除。但是库存为1的时候，并发操作会造成库存小于0，修改地址和商品价格，订单数据跟着改变。

技术实现： 首先订单数据是历史数据，不能因为商品或者收获地址修改而变化，所以在设计库表的时候，就需要将商品、地址、用户信息等通通保留下来，作为一份快照。下单的时候要加redis并发锁，保证同一时刻只有一个用户下单，但是要注意锁的颗粒。如果用户取消订单，就需要将库存加回去。

8.失效商品问题

业务背景： 收藏或者历史记录的商品点击出错。

技术实现： 商品可以用逻辑删除，查询的时候如果查无此商品，可以用一个失效状态标识，前端直接显示商品已经失效，跳转到其它页面。禁止因为商品不错在就报null指针错误，因为这类失效商品是合法的。

9.同一账号多台手机登录问题

业务背景： 同一个账号可以多台设备登录，导致数据错误。

技术实现： 可以采用token机制进行校验，当用户登录时候在redis存入一个key值为用户Id，值为token值，然后将token值返回给前端，当该用户在另一台设备登录的时候，查询key是否存在，如果存在则说明在另一台设备上面已经登录，发送极光推送（前端收到推送消息，强制性退出登录），并将token值更新，然后返回给前端。

前端每次请求接口都必须带上用户id、token值，如果返回其它设备已经登录，则强制性退出登录。

项目应用案例就介绍到这边了，如果对上述分析有疑问或者问题，都可以留言，博主会一一解答。

林老师带你学编程：https://wolzq.com