瞬时大并发；超卖；性能
- 数据尽量少
- 请求数尽量少
- 路径要尽量短
- 依赖要尽量少
- 尽量不要有单点
- 对于大促时的秒杀活动，一般运营商会配置静态的活动页面，因为秒杀活动页的流量是大促期间最大的，通过配置成静态页面可以将页面发布在公有云动态地横向扩展
- 将秒杀活动的静态页面提前刷新到CDN节点上，通过CDN节点的页面缓存来缓解公司网络带宽压力，CDN上缓存JavaScript、css和图片
- 将活动H5页面部署在公有云的网站服务器上，使用公有云最大的好处就是根据活动的火爆程度动态扩容而且成本较低，同时将访问压力隔离在公司系统外部
- 在提供真正商品秒杀业务功能的应用服务器上，需要进行请求限流和熔断控制，防止因为秒杀请求影响到其他正常服务的提供。在限流和熔断方面使用hystrix，在核心交易的接口中通过hystrix进行交易并发限流控制，当请求流量超出我们设定的流量最大值时，会对新请求进行熔断处理，直接返回静态失败响应
- 服务降级处理，除了上面讲到的限流和熔断控制，我们还设定了降级开关，对于首页、购物车、订单查询等功能都会进行一定程度服务降级，例如历史订单的查询会提供时间周期较短的查询。通过这样的降级处理能过过很好的保证整个系统在秒杀期间能够正常的提供组基础的服务，保证用户能够顾正常下单完成付款
- 将项目架构设定为微服务架构，有专门的秒杀系统，依赖统一的用户和鉴权系统，这些系统都注册到统一的服务注册中心，依赖统一的配置中心进行业务配置，而且这些服务都在统一的api网关之后，并会有专门的链路监控系统监控整个系统的运行。
- 移动端和前端应用通过网关与后端服务进行交互，进行网络请求。接入系统包括鉴权、负载均衡、限流和断路器，这是每个请求处理都需要的基础功能组件。
- 后端核心逻辑有用户登录、秒杀处理、秒杀活动管理、系统降级等，这些服务都注册到服务注册中心，并通过配置中心进行自身业务数据的配置。
- 链路监控时刻监控着系统的状态
- 最底层是换存层的redis以及持久化层MySQL和zookeeper。
项目具体的包接口如下：
- bootstrap：是服务启动时的初始化组件
- client：是用户和鉴权等系统提供给其他系统的rpc调用client
- common：是共同依赖，定义了一些基础结构
- config：是分布式配置中心接入组件
- discover：是服务注册与发现组件
- loadbalance：是客户端负载均衡组件
- MySQL：是MySQL数据库客户端组件
- ratelimit：是限流组件
普通用户进行秒杀时，首先与秒杀业务系统进行交互，秒杀业务系统主要负责对请求进行限流、用户黑白名单过滤、并发限制和用户数据签名校验。
秒杀业务系统的工作流程如下： 秒杀活动和秒杀商品的信息存储在zookeeper中，并且可以使用zookeeper的watch机制实时更新信息。
- 从zookeeper中加载秒杀活动数据到内存中
- 监听zookeeper中的数据变化，实时更新缓存在内存中秒杀活动数据
- 从redis中加载黑白名单数据到内存中
- 设置白名单
- 对用户请求进行黑名单限制
- 对用户请求进行流量限制、秒级限制、分级限制。
- 将用户数据进行签名校验、检验参数的合法性
- 将用户请求通过redis传递给业务核心系统进行处理
- 接收秒杀核心系统返回的秒杀处理结果，并返回给用户
秒杀核心系统主要负责进行真正的秒杀逻辑判断，依次处理redis队列中的用户请求，限制用户购买次数，根据商品抢购频率和频次对用户请求进行处理，并对获得抢购资格的用户生成对应的资格token
核心业务系统的工作流程如下：
- 从zookeeper中加载秒杀活动数据到内存中
- 监听zookeeper中数据的变化，实时更新缓存在内存中的秒杀活动数据
- 处理redis队列中秒杀业务系统传递过来的请求
- 限制用户对商品的购买次数
- 对商品的购买频次进行限制
- 对商品的抢购概率进行限制
- 对合法的请求给予生成抢购资格token令牌，并通过redis传递给秒杀业务系统
秒杀管理系统主要服务于秒杀活动管理人员，进行活动信息和秒杀商品信息的管理。
秒杀管理系统的功能：
- 配置并管理商品数据，提供对商品数据的增加和查询接口
- 配置并管理秒杀活动数据，提供对秒杀互动的增加和查询接口
- 将秒杀活动数据同步到zookeeper
- 将秒杀活动数据持久化到数据库