电商秒杀系统架构

 

一、背景

       秒杀其实主要解决两个问题,一个是并发读,一个是并发写。并发读的核心优化理念是尽量减少用户到服务端来“读”数据,或者让他们读更少的数据;并发写的处理原则也一样,它要求我们在数据库层面独立出来一个库,做特殊的处理。另外,我们还要针对秒杀系统做一些保护,针对意料之外的情况设计兜底方案,以防止最坏的情况发生。
       而从一个架构师的角度来看,要想打造并维护一个超大流量并发读写、高性能、高可用的系
统,在整个用户请求路径上从浏览器到服务端我们要遵循几个原则,就是要保证用户请求的
数据尽量少、请求数尽量少、路径尽量短、依赖尽量少,并且不要有单点。
       高性能  秒杀涉及大量的并发读和并发写,因此支持高并发访问这点非常关键
        一致性 秒杀中商品减库存的实现方式同样关键。可想而知,有限数量的商品在同一时
刻被很多倍的请求同时来减库存,减库存又分为“拍下减库存”“付款减库存”以及预扣
等几种,在大并发更新的过程中都要保证数据的准确性,其难度可想而知。
        高可用 现实中总难免出现一些我们考虑不到的情况,所以要保证系统的高可用和正确性,我们还要设计一个 PlanB 来兜底,以便在最坏情况发生时仍然能够从容应对
      
   

二、架构设计 

    现在以100w/s请求量为例设计一个秒杀系统,架构图如下:
三、存储架构设计 


四、计算架构设计 

秒杀请求依赖登录状态,登录状态一般都是保存在分布式缓存中的,因此发送秒杀请求发送给任意服务器都可以,这里选择“轮询”或者“随机”算法。

计算架构之缓存

五、高可用架构设计

1、秒杀请求排队架构

使用排队服务器,技术本质是:请求缓存+ 同步改异步+ 请求端轮询 。

2、主备级联复制

六、可扩展架构设计

微服务拆分

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值