服务拆分

image

主要包含四块逻辑：
1.系统管理侧，统一认证，用户管理等。后台管理系统
2.查询逻辑处理，电商在高并发的场景下，查询响应给用户体验至关重要，所以对于查询要做一些细致的优化，上面先从大模块做了划分。
3.有查询就必须有数据，而电商场景下，将商品数据构建了有通用性的数据模型，而且商品的库存，已经商品对应的营销属性也很重要，所以也会是独立的模块。
4.说完前面，购买逻辑的处理，应该是电商最大头的东西，一般分为，购物车，订单，支付三个环境，这样设计在一定程度上帮助处理并发。

模块分析

系统管理

单点登陆(jwt+rsa)==》(两种实现：session有状态，token无状态)
 cros跨域问题处理(option预请求的方式)
 oss图片存储
 登陆逻辑处理(验证码，失败次数等)

数据录入

 数据模型：类目，品牌，spu(product级别描述商品)，sku(库存级别描述商 
 品)，属性，规格，描述 

添加数据：在后台录入商品数据，同时将商品id发到mq，搜索模块的监听器，监听到动作就将商品信息录入ES。

数据查询

主页的类目(电商都是三级)：由于主页访问量比较大，且三级类目改动频率低，所以将类目数据存放在redis。
 --每次访问首页的时候，就会去查类目数据，首先会去redis查，没有就去查db，然后更新到redis，在redis没有的时候，会去竞争锁，获取锁之后，才能查询db，这样处理是为了避免缓存击穿，并保证redis和db数据的一致性。在将db数据加入缓存的时候会为缓存设置了固定时间+随机数的过期时间，防止缓存雪崩。(上写一致性先保证db)

商品搜索：由于商品的数据量大，且需要搜索的时候对关键字高亮显示，所以选择将商品数据放到ES，来实现海量数据的检索。

商品详情：这类数据变得小，关系多，所以考虑将其放到关系数据库中。

购买逻辑

     购物车：注意两个问题
     购物车商品合并：购物车中的数据分登陆数据和未登陆数据。
     价格同步：在下单的时候，需要比较购物车价格和商品表的价格，并在下单页面显示价格变动，避免用户歧义。
结算：在加入购物车或直接商品页点击"结算"，就会显示订单详情(送货地址，商品价格，促销信息等)。在点击"结算"，后台会将上面的信息传给前端，还会返回一个唯一标示(雪花算法生成)，存在redis中，并返回给前端。前端每次提交带上这个唯一标示，避免重复提交订单。

提交订单：提交订单流程"防重--验价---锁库存---生成订单---删除购物车---生成付款码"。
        防重：唯一标示
        验价：
        锁库存：处理前加分布式锁，防止超卖；锁库存的数据，添加到延迟队列，过期后释
               放库存。
        生成订单：生成订单一般会设置30分钟，未支付，自动关单，并释放库存(这个也是
        通过延迟队列实现)。
 支付：  下单完成后，调用支付包或微信的接口生成付款码(注意过期处理)，然后用户扫码支付，调用第三的接口，支付完后，回调本地系统更改支付状态，减库存，加积分。

 这个过程有分布式事务，一般两种方式处理：
      二阶段提交(tcc，seata等)，性能稍差，实时性高些。
      基于mq的消息补偿，性能比上面好，保证最终一致性。