首先声明本系统是完全按照分布式系统设计，非分布式系统不在本系统考虑范围内。
秒杀系统是商城类应用的较高性能要求的应用场景，其一般包含以下几个特点：
1、并发性高
2、瞬时流量大
3、实时性要求略低于接入能力
前一段时间看了kafka消息的服务处理模式，略有感受，做了一点调整以后移植到本秒杀系统的设计中。
整个系统从功能划分来讲，包含两部分内容：
1、功能系统
2、保障系统
功能系统负责实际功能的实现，保障系统负责为功能系统提供性能、安全等方面的保障。
简单的业务划分图如上。
可以简单的把这个流程理解成去面馆点单的过程。
1、进入面馆（可能你不是真顾客或者因为什么原因，所以被面馆门口的服务员拦下）（请求接入）
2、面馆有一个点菜的服务员帮助顾客点单，点单的时候就会确认还有面没有，只有当有面的时候才会创建出订单（订单创建）
3、如果顾客拿到了订单，则说明订购成功，订单被发到了后厨的排队系统里面，反之，则顾客订购失败，顾客离场（创建有效订单或者告知请求失败）
4、后厨的排队系统拿到订单后，依次发出要求，要求后厨根据订单制作面品，此时顾客也可以随时向后厨查询订单的进度（准备订单相关数据，包括商品、物流等）
5、后厨做好面品以后，将成品放置在成品区，并通知服务员可以发送货品（数据落库）
6、当服务员接收到通知可以发送货品时，开始执行发送操作，并顺次将货品送至顾客手里（订单落库已经全部完成，开始执行后续操作）
按照上述层级（或者面馆模式）进行划分，每一层的处理都是相对独立的，如果门口的服务员不够，可以增加门口的服务员，如果厨师的处理速度太慢，可以增加厨师数量和厨房面积，入股排队的位置不够，则可以考虑增加队列的容量能力。总之这个模式充分考虑了各个职能的划分，在需要的时候可以对其中任何一个层级进行扩充，以增加整个架构的处理能力（保证了结构的可伸缩性）。至于处理能力，在可伸缩性能得到保障的前提下，处理能力不会成为真正的系统瓶颈。
说完了功能划分，我们再来说服务保障层面。
这个系统需要从有效请求和系统保护两个层面进行保障系统的设计。
1、有效请求
有效请求是用户发起的真实有效的下单请求，我们可以根据活动和商品设置用户有效请求的过滤条件，在接入层对用户请求的有效性进行管控，只放入系统认可有效的请求，过滤掉无效的部分。
2、系统保护
系统保护分为三个层面的内容：
（1）最大请求量保护
最大请求保护是接入层能够接入的最大请求数量，一旦接入层瞬时接入的数量超过或者大大超过其有效接入能力，应该快速返回用户请求，抛弃过量的请求，以保证系统的整体有效性。
（2）各层最大处理能力保护
不同的层级内的各自的业务处理能力是有限的（在一定的服务部署条件下），因此应该设定每层最大并发处理能力，以保证各层服务的最大有效服务能力，提高处理效率。超过的部分必须在队列中进行等待，而不是无限制的从队列中接入请求。
（3）队列保护
各层级间的队列能力也不是无限制的，必须对各队列的最大接入能力做好设置和预估（性能预演），以确保队列的有效性，超过队列接入能力的增加队列请求必须要求业务方等待队列，或者要求业务方抛弃或者其他方式处置当前请求。
再聊一下整个服务的设计依赖。
上述服务的结构是按照java微服务的结构进行设计，各层间均没有直接依赖，而是依赖以下服务或者中间件。
1、nginx+Lua，接入层
2、redis+kafka，各缓存层和通知
3、mysql或mongo，数据库层
需要注意的几个设计点：
1、各层，尤其是缓存层的处理机制，务必根据使用场景进行足够大压力的测试，以做出最优配置设置。
2、数据库层，由于订单类数据的海量特性以及高时效性的特点，需要根据业务情况进行单独设计，通常可以考虑进行分表和分库的设计，另外还可以根据时间进行归档。
3、网络带宽，这是容易忽略的一个点。设计时应该考虑每次请求的带宽占用情况，按照成交数的10倍以上预留带宽，以确保带宽不成为整个结构的设计瓶颈
4、中间件的性能压力测试，这也是整个服务压力测试的重点，必须对各中间件的独立承载能力做出极限测试。
