Skip to content

Home

Jump to bottom
幽灵柯南 edited this page Aug 13, 2022 · 10 revisions

系列专题 陆续完善中。。。 这里 你将学到

技术

1、Redisson 分布式锁

2、RocketMq

  • RocketMq作为消息中间件，在秒杀系统里面可以作为削峰的作用
  • 利用其延时队列，实现订单超时未支付取消功能
  • 支付成功之后的短信、微信模板消息通知等
  • 一些补偿措施，例如补偿优惠券，积分等

3、Nacos 配置中心、注册中心

  • 配置中心，实时更改生产配置，不需要重启服务
  • 注册中心，服务分组，注册到nacos

4、SpringCloud GateWay 网关

网关作为微服务的基础设施之一，作为系统的入口，提供内部服务的路由转发，可以实现一些公用逻辑， 例如认证、鉴权、路由转发、安全策略、防刷、限流、监控日志等

5、设计模式-策略模式

  • 优惠券规则计算，包含满减券计算规则、现金券计算规则、满折计算规则

6、设计模式-工厂模式

  • 结合策略模式

7、设计模式-状态模式（状态机）

  • 订单状态变更 传统的订单状态变更，前后没有逻辑校验，例如 订单只有在待支付的状态下才能去支付，而订单取消、交易完成等状态下的订单则不能支付， 传统的这种业务逻辑里面会交杂大量的if-else 等状态的判断，状态机能保证订单状态不会出现紊乱。

8、线程池

  • 如何动态调整线程池各种参数（核心线程数、最大线程数等参数） 1、系统初始化的时候，从数据库获取参数配置，获取到配置则根据配置的参数初始化线程池 如未取到配置，则初始化默认线程池 2、线程池参数，从Nacos获取 后续需要更改参数，改变nacos参数即可 ，应用跟nacos服务端之间会建立长连接，应用端有一个线程在长轮询 /V1/CS/CONFIGS/LISTENER 这个服务 参数改变实时更新
  • 如何监控线程池

9、采用异步，提高程序执行效率

  • CompletableFuture 异步编排

10、多级缓存

  • redis 、guava、ehcache 为何需要多级缓存？ 高并发情况下，频繁访问Redis 也会存在网络IO，网络IO也会成为性能瓶颈，如果秒杀情况下有些数据放在JVM内存里面，本地内存作为一级缓存，应用直接访问本地内存，访问耗时忽略不计。这里会带来领一个问题，本地缓存与Redis、Mysql等之间如何保持数据同步，双写一致性问题？后续系列文章会详细描述。

11、jvm调优

  • 流量预估 秒杀峰值预估，一个订单对象大小估算？
  • jvm调优 秒杀下JVM 如何调优？
  • 压测如何进行？

业务设计

1、秒杀功能设计

秒杀会有秒杀活动、秒杀场次、秒杀商品 一个秒杀活动，活有多个秒杀活动场次，（例如 上午场、下午场，X点场等） 一个秒杀场次，会包含多个秒杀商品

2、优惠券体系设计

优惠券包含 满减券、现金券、折扣券 满减券，指的是满XX元减多少元，可以配置指定商品可用、指定分类下商品可用，全场可用 现金券，指的是下单立减XX元，可以配置指定商品可用、指定分类下商品可用，全场可用 折扣券，指的是下单XX折，可以配置满XX元XX折，可以配置指定商品可用、指定分类下商品可用，全场可用 券体系设计，需要重点考虑购物车多商品，用券分摊计算的问题，因为后续如果商品部分退款，会设计退款金额计算等，比较复杂。

3、权限系统设计

C端：用户体系 基于jwt token设计，用户登录之后，返回token，后续使用token进行访问api，后端校验token合法性 B端：基于RBAC的用户权限控制体系，生成token，用户登录之后，返回token，后续使用token进行访问api，后端校验token合法性 包含token续期、token刷新、踢出等机制 gateway 网关层 各api层均会校验token合法性

4、订单系统设计

  • 下单扣库存 会出现恶意下单，不支付的情况，严重情况下会导致正常用户无法下单， 超时未支付，去掉订单，返回库存
  • 支付扣库存 支付扣库存，能防止恶意下单，但是可能出现超卖的情况，毕竟用户支付了，正常情况下都应保证下单成功（实物、虚拟商品情况有所不同）

5、商品系统设计

商品包括库存设计、SKU设计、物流设计,其中SKU设计较为复杂，也是商品设计的核心

Clone this wiki locally