写点什么

模块九毕业设计

用户头像
以吻封笺
关注
发布于: 刚刚

计算性能估算

6.18 秒杀活动用户行为


秒杀商品查询、提交秒杀订单、秒杀成功订单支付


【秒杀商品查询】


  1. 日活用户大约 100 万,6.18 秒杀假设日活 120 万

  2. 秒杀活动假设在上午 10 点整开始,有 20%的用户会在 10 点参与秒杀,则 10 点秒杀最大 QPS 为:120 万*0.2 = 24 万/秒。


【提交秒杀订单】


  1. 日活用户大约 100 万,6.18 秒杀假设日活 120 万

  2. 秒杀活动假设在上午 10 点整开始,有 20%的用户会在 10 点参与秒杀,则 10 点秒杀最大 TPS 为:120 万*0.2 = 24 万/秒。


【秒杀成功订单支付】

存储设计

  1. 数据库使用 MySQL,并且采用主备架构。原因如下:


  • TPS 和 QPS 达到 24 万/秒,并发读写极大,因此必须使用缓存处理读写并发,处理结果先存储在缓存内,在秒杀结束后将结果写入到数据库即可,因此对数据库的读写性能要求并不大。

  • 采用 Redis 缓存,缓存信息有:秒杀商品信息、秒杀商品库存数、已秒杀成功用户和商品的对应关系数据


  1. 缓存存储使用 Redis 集群

  2. 读写并发基本都是基于 Redis 缓存数据

  3. 秒杀期间必须保证缓存可用,因此使用 Redis 集群



负载均衡设计

使用 nginx 作为负载均衡服务,一个 nginx 节点可以处理 10000 个并发请求,则需要 24 个节点,一个服务器部署 2 个节点,需要服务器 12 台。


缓存设计

只需分布式缓存,无需其他缓存,


应用缓存架构


分布式缓存框架使用 Redis,缓存数据如下:


  1. 使用 List 数据结构存储秒杀商品信息,商品 ID 包含在 key 中,入:20211010_ProductId。

  2. 使用 LIst 数据结构存储商品库存信息,一个库存在 List 中存储一条记录,因此 iphone 和充电宝分别在不同的 List 列表存储了 12 条记录和 1000 条记录。

  3. 私用 Set 数据结构存储用户秒杀成功的商品对应关系数据,以防一个人秒杀了多个。


使用 Redis 缓存还有如下好处:


  1. 可承载并发量大

  2. Redis 单线程,可防止商品超卖情况

  3. 丰富的数据结构

微服务设计

参考现有的成熟秒杀方案进行服务设计,经业务梳理分析得出业务模块图:



服务拆分


开发资源:全部 Java


服务开发资源分配:平均 2 个人开发一个微服务。


方案一:拆分成 3 个服务,商品服务、用户服务、秒杀服务

备选方案二:拆分成 2 个服务,商品服务、用户服务


微服务划分


  • 商品服务包含商品业务、品类业务、库存业务,三种业务关联比较大,先作为一个服务处理,后续随着业务需要可按需拆分,当前为一个粗粒度划分。

  • 用户服务包含用户业务、登录业务、订单业务等,三种业务关联大,后续可将订单独立。

  • 秒杀服务包含秒杀业务逻辑

基础设施选型

服务注册、发现、路由选择嵌入式 SDK,原因如下:


  • 统一 Java 语言,无需考虑多语言版本,学习成本小,出现问题可快速定位

  • 使用简单,无需维护高可用、高性能,运维简单

  • 网络代理和反向代理运维麻烦,成本高,不在现有的运维体系,出现问题排查困难

  • 适合从 0 开始的项目进行快速开发上线

  • 由于初创公司,嵌入式 SDK 可以节省成本,随着业务增长后续可切换成反向代理或网络代理


开发框架选择 SpringCloud,原因如下:


  • 整套的微服务技术体系,资料文档比较全,专用开发组件丰富,运用广泛,运用后排查问题方便

  • 微服务之间通信简单 http 即可,SpringCloud 已提供

  • SpringCloud 的注册中心 eureka 满足嵌入式 SDK 需要

  • SpringCloud 提供完善的链路追踪、熔断降级、网关等组件,拿来即用

高可用设计

因为只有一个机房,所以无需考虑跨机房同步。


  • MySQL 采用主备

  • Redis 使用集群

架构设计

秒杀系统架构图


系统架构一:



系统备选架构二:


用户头像

以吻封笺

关注

还未添加个人签名 2018.09.15 加入

还未添加个人简介

评论

发布
暂无评论
模块九毕业设计