电商系统设计艺术——秒杀业务设计

一、秒杀场景

1. 人多货少&＃xff0c;只有少量的人能够抢购成功。
2. 高并发&＃xff0c;秒杀业务在开始之前流量比较平稳&＃xff0c;开始后流量会直线性的上升。
3. 持续时间短&＃xff0c;秒杀开始随着库存的减少流量会以瀑布式的下降&＃xff0c;这个过程持续时间很短&＃xff0c;一般为秒级。

二、常见问题

• 系统崩溃&＃xff0c;导致系统崩溃的原因比较复杂&＃xff0c;常见的有以下几点&＃xff1a;

          1、mysql操作时间长&＃xff0c;优化表结构设计&＃xff0c;合理建立索引&＃xff0c;优化sql语句。通过调整尽量让sql语句的执行时间下降到30毫秒之内。至于如何优化sql操作感兴趣的可以关注我&＃xff0c;以后会讲。

          2、频繁的操作mysql&＃xff0c;在秒杀场景中&＃xff0c;高频率的操作mysql是大忌&＃xff0c;使用缓存或队列来减少mysql的压力。

          3、代码逻辑写的不合理或是业务本身导致&＃xff0c;原则上尽量把可能造成较高性能消耗的逻辑靠后执行&＃xff08;下面系统 瓶颈会列出性能排序&＃xff09;&＃xff0c;通过层层验证阻断来减少消耗性能的逻辑执行&＃xff0c;可重复利用的数据重复利用&＃xff0c;减少性能低效的函数或第三方库使用。如果说是业务本身导致那基本无解&＃xff0c;找负责人好好谈谈吧。

          4、文本操作过于频繁&＃xff0c;常见于日志的写入、配置文件的读取。php作为一门脚本语言处理能力比较低&＃xff0c;每次执行都需要进行解析释放等很多不必要重复的环节导致消化性能&＃xff0c;利用swoole会好一些&＃xff0c;但依然不建议使用PHP开发。对于日志写入这个不管用什么语言都会遇到相同的问题&＃xff0c;可以利用延迟写入或异步写入来解决。

           5、带宽达到上限&＃xff0c;这是一个经常会被忽视的细节&＃xff0c;并发一上来总感觉慢&＃xff0c;不知道为啥慢&＃xff0c;看服务器的状态也抖很正常&＃xff0c;其实很有可能是宽带跑满了。每一个用户的请求都会占用一定的宽带&＃xff0c;所以尽量减少输入输出的大小&＃xff0c;除此之外只能提高带宽来解决。

• 库存超卖&＃xff0c;在秒杀场景中库存超卖是很常见的问题&＃xff0c;一般采用锁或原子操作来控制库存。
• 机器人刷单攻击&＃xff0c;对于火爆的单品很可能会被羊毛党进行刷单&＃xff0c;在做防护的同时也需要强大自身防止服务器雪崩。

三、常见的系统瓶颈

对于系统瓶颈我们要先有一个处理速度上的基本认知&＃xff0c;在程序开发的过程中我们劲量使用速度快的方式来处理&＃xff0c;比如能用redis的别用mysql&＃xff0c;能不夸机房请求的别夸机房&＃xff0c;能内网的千万别外网&＃xff0c;要合理的利用资源。

1、数据读写操作&＃xff1a;程序自身数据读写>redis>mysql>磁盘

2、网络操作&＃xff1a;本机>局域内网>跨机房>外网

四、正片

服务器层面的架构设计这里就不多做介绍了&＃xff0c;感兴趣的可以看下这篇文章&＃xff1a;电商系统设计艺术——高并发架构搭建

我们来看下应对秒杀场景都需要做哪些事

1、单独部署&＃xff0c;这点基本上是必须要做的&＃xff0c;秒杀场景往往突发流量会很高导致压垮服务器&＃xff0c;如果未进行单独部署的话会导致其他业务也会受影响&＃xff0c;单独部署可以有效的解决此问题&＃xff0c;同时也更方便维护。

2、页面静态化&＃xff0c;同时利用CDN或NGINX缓存可有效减少部分用户对后端业务的请求&＃xff0c;将请求拦截在上游&＃xff0c;同时前端页面还需要做到防止重复提交。

3、缓存应用&＃xff0c;缓存是一个神器可以说&＃xff0c;他能在很多层面来减少服务器的负担&＃xff0c;常见的有利用缓存来减少数据库的操作。

4、限流、降级、熔断、隔离。秒杀只有少部分人可以抢购成功&＃xff0c;限流可以挡住一大部分的流量。至于降级、熔断、隔离&＃xff0c;这一系列的操作主要是为了保证服务的稳定性。虽然前段已经做了防重复提交手段&＃xff0c;但是挡不住恶意用户利用机器人刷接口&＃xff0c;这时候后端同样也需要做防重复提交的机制&＃xff0c;IP锁&＃xff0c;用户锁&＃xff0c;口令等都可以&＃xff0c;但是各有各的优缺点&＃xff0c;结合实际场景使用&＃xff0c;

5、削峰填谷&＃xff0c;其实就是消息队列&＃xff0c;如MQ&＃xff0c;利用消息队列的特性来讲流量进行平滑过渡。

6、异步&＃xff0c;在程序设计中能采用异步的地方就采用异步的形式&＃xff0c;如&＃xff1a;日志写入&＃xff0c;下单等。

7、分布式负载&＃xff0c;这个不用多说了吧&＃xff0c;单机肯定是扛不住的&＃xff0c;需要分布部署到多台机器上来分摊压力。

8、可伸缩&＃xff0c;一是指业务的可扩展性&＃xff0c;二是指方便服务器进行弹性伸缩操作以便合理利用服务器资源。

搞完后差不多就是上面的这种结构图&＃xff0c;有了基本的结构我们在具体的看下如何扣减库存来保证不超卖同时又保证性能高效。

扣库存的方式分为三大类&＃xff0c;支付减库存、下单减库存、预扣库存。

1、下单减库存&＃xff1a;

这种方式在扣库存的过程中如果采用一定的限制条件是不会出现超卖的情况&＃xff1a;update set num &＃61; num - 1 where &＃61; num>0&＃xff0c;这里需要特别注意WHERE条件&＃xff0c;如果在num-1小于0的情况下是不会更新成功的&＃xff0c;这就保证了不会出现超卖的情况&＃xff0c;弊端就是这种sql在执行效率上比较抵效&＃xff0c;而且需要频繁的去操作sql显然不适用秒杀场景。

2、支付减库存&＃xff1a;

 这种情况存在很多的弊端&＃xff0c;从下面列举的弊端来看显然更加不适合秒杀场景。

     1&＃xff09;会存在大量的垃圾订单&＃xff08;无法支付的订单&＃xff09;占用资源。

     2&＃xff09;会造成下单后无法支付或支付后无法正常修改库存导致超卖&＃xff0c;这是一个很严重的问题&＃xff0c;老板被整破产都有可能~

3、预扣库存&＃xff1a;

 我们讲库存预先存入redis里&＃xff0c;当用户下单后利用redis的原子特性预先去扣减redis里的库存量&＃xff0c;当扣减成功后在去异步生成订单&＃xff0c;这样可有效减少对数据库的直接操作同时又避免了超卖情况的发生&＃xff0c;这么看来预扣库存更加适合的秒杀场景。

可以看到不管使用哪种扣库存的方式都会有一个超时取消订单的模块&＃xff0c;当用户下单后不支付在超过一定的时间范围后会自动取消订单保证不少卖。