【续】你正在毁灭你的项目吗?

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

image

场景应用

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

林老师带你学编程 wechat
欢迎您扫一扫上面的微信公众号,订阅我的博客!