电商秒杀系统架构

 

一、背景

       秒杀其实主要解决两个问题，一个是并发读，一个是并发写。并发读的核心优化理念是尽量减少用户到服务端来“读”数据，或者让他们读更少的数据；并发写的处理原则也一样，它要求我们在数据库层面独立出来一个库，做特殊的处理。另外，我们还要针对秒杀系统做一些保护，针对意料之外的情况设计兜底方案，以防止最坏的情况发生。

       而从一个架构师的角度来看，要想打造并维护一个超大流量并发读写、高性能、高可用的系

统，在整个用户请求路径上从浏览器到服务端我们要遵循几个原则，就是要保证用户请求的

数据尽量少、请求数尽量少、路径尽量短、依赖尽量少，并且不要有单点。

       高性能  秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键
        一致性 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时
刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣
等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。
        高可用 现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，我们还要设计一个 PlanB 来兜底，以便在最坏情况发生时仍然能够从容应对

      

   

二、架构设计 

    现在以100w/s请求量为例设计一个秒杀系统，架构图如下：

三、存储架构设计 

四、计算架构设计 

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

计算架构之缓存

五、高可用架构设计

1、秒杀请求排队架构

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

2、主备级联复制

六、可扩展架构设计

微服务拆分