Java生鲜电商平台-秒杀系统微服务架构设计与源码解析实战

Java生鲜电商平台-秒杀系统微服务架构设计与源码解析实战

 

Java生鲜电商平台-  什么是秒杀

通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动

好比说京东秒杀，就是一种定时定量秒杀，在规定的时间内，不管商品是否秒杀完毕，该场次的秒杀活动都会结束。这种秒杀，对时间不是特别严格，只要下手快点，秒中的几率仍是比较大的。

淘宝之前就作过一元抢购，通常都是限量 1 件商品，同时价格低到「使人发齿」，这种秒杀通常都在开始时间 1 到 3 秒内就已经抢光了，参与这个秒杀通常都是看运气的，没必要太强求

业务特色

 

 

 

瞬时并发量大

秒杀时会有大量用户在同一时间进行抢购，瞬时并发访问量突增 10 倍，甚至 100 倍以上都有。

库存量少

通常秒杀活动商品量不多，这就致使了只有极少许用户能成功购买到。

业务简单

流程比较简单，通常都是下订单、扣库存、支付订单

技术难点

 

 

现有业务的冲击

秒杀是营销活动中的一种，若是和其余营销活动应用部署在同一服务器上，确定会对现有其余活动形成冲击，极端状况下可能致使整个电商系统服务宕机

直接下订单

下单页面是一个正常的 URL 地址，须要控制在秒杀开始前，不能下订单，只能浏览对应活动商品的信息。简单来讲，须要 Disable 订单按钮

页面流量突增

秒杀活动开始先后，会有不少用户请求对应商品页面，会形成后台服务器的流量突增，同时对应的网络带宽增长，须要控制商品页面的流量不会对后台服务器、DB、Redis 等组件的形成过大的压力

架构设计思想

 

 

限流

因为活动库存量通常都是不多，对应的只有少部分用户才能秒杀成功。因此咱们须要限制大部分用户流量，只准少许用户流量进入后端服务器

削峰

秒杀开始的那一瞬间，会有大量用户冲击进来，因此在开始时候会有一个瞬间流量峰值。如何把瞬间的流量峰值变得更平缓，是可否成功设计好秒杀系统的关键因素。实现流量削峰填谷，通常的采用缓存和 MQ 中间件来解决

异步

秒杀其实能够当作高并发系统来处理，在这个时候，能够考虑从业务上作兼容，将同步的业务，设计成异步处理的任务，提升网站的总体可用性

缓存

秒杀系统的瓶颈主要体如今下订单、扣减库存流程中。在这些流程中主要用到 OLTP 的数据库，相似 MySQL、SQLServer、Oracle。因为数据库底层采用 B+ 树的储存结构，对应咱们随机写入与读取的效率，相对较低。若是咱们把部分业务逻辑迁移到内存的缓存或者 Redis 中，会极大的提升并发效率

总体架构

 

 

 

客户端优化

秒杀页面

秒杀活动开始前，其实就有不少用户访问该页面了。若是这个页面的一些资源，好比 CSS、JS、图片、商品详情等，都访问后端服务器，甚至 DB 的话，服务确定会出现不可用的状况。因此通常咱们会把这个页面总体进行静态化，并将页面静态化以后的页面分发到 CDN 边缘节点上，起到压力分散的做用

防止提早下单

防止提早下单主要是在静态化页面中加入一个 JS 文件引用，该 JS 文件包含活动是否开始的标记以及开始时的动态下单页面的 URL 参数。同时，这个 JS 文件是不会被 CDN 系统缓存的，会一直请求后端服务的，因此这个 JS 文件必定要很小。当活动快开始的时候（好比提早），经过后台接口修改这个 JS 文件使之生效

API 接入层优化

客户端优化，对于不是搞计算机方面的用户仍是能够防止住的。可是稍有必定网络基础的用户就起不到做用了，所以服务端也须要加些对应控制，不能信任客户端的任何操做。通常控制分为 2 大类

限制用户维度访问频率

针对同一个用户（ Userid 维度），作页面级别缓存，单元时间内的请求，统一走缓存，返回同一个页面

限制商品维度访问频率

大量请求同时间段查询同一个商品时，能够作页面级别缓存，无论下回是谁来访问，只要是这个页面就直接返回

SOA 服务层优化

上面两层只能限制异经常使用户访问，若是秒杀活动运营的比较好，不少用户都参加了，就会形成系统压力过大甚至宕机，所以须要后端流量控制

对于后端系统的控制能够经过消息队列、异步处理、提升并发等方式解决。对于超过系统水位线的请求，直接采起 「Fail-Fast」原则，拒绝掉

秒杀总体流程图

 

 

秒杀系统核心在于层层过滤，逐渐递减瞬时访问压力，减小最终对数据库的冲击。经过上面流程图就会发现压力最大的地方在哪里？

MQ 排队服务，只要 MQ 排队服务顶住，后面下订单与扣减库存的压力都是本身能控制的，根据数据库的压力，能够定制化建立订单消费者的数量，避免出现消费者数据量过多，致使数据库压力过大或者直接宕机。

库存服务专门为秒杀的商品提供库存管理，实现提早锁定库存，避免超卖的现象。同时，经过超时处理任务发现已抢到商品，但未付款的订单，并在规定付款时间后，处理这些订单，将恢复订单商品对应的库存量

Nginx优化

1. 动静分离，不走tomcat获取静态资源

server {
        listen       8088; location ~ \.(gif|jpg|jpeg|png|bmp|swf)$ { root C:/Users/502764158/Desktop/test; } location ~ \.(jsp|do)$ { proxy_pass http://localhost:8082; } } } 

2. gzip压缩，减小静态文件传输的体积，节省带宽，提升渲染速度

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_comp_level 3;
gzip_disable "MSIE [1-6]\."; gzip_types text/plain application/x-javascript text/css application/xml text/javascript image/jpeg image/gif image/png; 

3. 配置集群负载和容灾，设置失效重连的时间，失效后，按期不会再重试挂掉的节点,参数

• fail_timeout默认为10s
• max_fails默认为1。就是说，只要某个server失效一次，则在接下来的10s内，就不会分发请求到该server上
• proxy_connect_timeout 后端服务器链接的超时时间_发起握手等候响应超时时间

upstream  diancai.com {  
  #服务器集群名字 server 127.0.0.1:8080; server 127.0.0.1:38083; server 127.0.0.1:8083; } server { listen 88; server_name localhost; location / { proxy_pass http://diancai.com; proxy_connect_timeout 1; fail_timeout 5; } } 

4. 集成Varnish作静态资源的缓存
5. 集成tengine作过载的保护

页面优化

1. 下降交互的压力

• 尽可能把js、css文件放在少数几个里面，减小浏览器和后端交互获取静态资源的次数
• 尽可能避免在秒杀商品页面使用大的图片，或者使用过多的图片

2. 安全控制

• 时间有效性验证：未到秒杀时间不能进行抢单，而且同时程序后端也要作时间有效性验证，由于网页的时间和各自的系统时间决定，并且秒杀器能够经过绕开校验直接调用抢单
• 异步抢单：经过点击按钮刷新抢宝，而不是刷新页面的方式抢宝（答题验证码等等也是ajax交互）
• redis作IP限流
• redis作UserId限流

Redis集群

1. 分布式锁（悲观锁）

2. 缓存热点数据（库存）：若是QPS过高的话，另外一种方案是经过localcache，分布式状态一致性经过数据库来控制

3. 分布式悲观锁（参考redis悲观锁的代码）

• 悲观锁（由于确定争抢严重）
• Expire时间（抢到锁后，马上设置过时时间，防止某个线程的异常停摆，致使整个业务的停摆）
• 定时循环和快速反馈（for缓存有超时设置，每次超时后，从新读取一次库存，还有货再进行第二轮的for循环争夺，实现快速反馈，避免没有货了还在持续抢锁）

4. 异步处理订单

• redis抢锁成功后，记录抢到锁的用户信息后，就能够直接释放锁，并反馈用户，经过异步的方式来处理订单，提高秒杀的效率，下降无心义的线程等待
• 为了不异步的数据不一样步，须要抢到锁的时候，在redis里面缓存用户信息列表，缓存结束后，触发抢单成功用户信息持久化，而且定时的比对一致性

消息队列限流

消息队列削峰限流(RocketMQ自带的Consumer自带线程池和限流措施)，集群。通常都是微服务，订单中心、库存中心、积分中心、用户的商品中心

数据库

• 拆分事务提升并发度
• 根据业务需求考虑分库：读写分离、热点隔离拆分，可是会引入分布式事务问题，以及跨库操做的难度
  要执行的操做：扣减库存、生成新订单、生成待支付订单、扣减优惠券、积分变更
  库存表是数据库并发的瓶颈所在，须要在事务控制上作权衡：能够把扣减库存设置成一个独立的事务，其它操做成一个大的事务（订单、优惠券、积分操做），提升并发度，可是要作好额外的check
  update 库存表 set 库存=库存-1 where id=** and 库存>1
• 为了提高并发，须要在事务上作妥协
  单机上拆分事务：好比扣减库存表+(生成待支付订单+优惠券扣减+积分变更)是一个大的事务，为了提升并发，能够拆分为2个事务
  分库之后引入分布式事务问题,为了保证用户体验，最好仍是经过日志分析来人工维护，不然阻塞太严重，并发差

答题验证码

1. 能够防止秒杀器的干扰，让更多用户有机会抢到
2. 延缓请求，每一个人的反应时间不一样，把瞬间流量分散开来了
3. 验证码的设计能够分为2种

• 验证失败从新刷新答题（12306）：服务器交互量大，每错一次交互一次，可是能够大大下降秒杀器答题的可能性，由于没有试错这个功能，答题一直在变
  验证失败提示失败，可是不刷新答题的算法：要么答题成功，进入下单界面，要么提示打错，继续答题（不刷新答题，无须交互，用js验证结果)。
  这种方案，能够在加载题目的时候一块儿加载MD5加密的答案，而后后台再校验一遍，实现相似的防止做弊的效果。好处是不须要额外的服务器交互。
  MD加密答案的算法里面要引入 userId PK这些因素进来来确保每次答案都不同并且没有规律，避免秒杀器统计结果集

• 答题的验证：除了验证答案的正确性意外，还要统计反应时间，例如12306的难题，正常人类的答题速度最快是1.5s，那么，小于1s的验证能够断定为机器验证

总结

层层过滤，尽可能将请求拦截在上游，下降下游的压力，充分利用缓存与消息队列，提升请求处理速度以及削峰填谷的做用

削峰限流

• 前端+Redis拦截，只有redis扣减成功的请求才能进入到下游
• MQ堆积订单，保护订单处理层的负载，Consumer根据本身的消费能力来取Task，实际上下游的压力就可控了。重点作好路由层和MQ的安全
• 引入答题验证码、请求的随机休眠等措施，削峰填谷

安全保护

• 页面和前端要作判断，防止活动未开始就抢单，防止重复点击按钮连续抢单
• 防止秒杀器恶意抢单，IP限流、UserId限流限购、引入答题干扰答题器，而且对答题器答题时间作常理推断
• 过载丢弃，QPS或者CPU等核心指标超过必定限额时，丢弃请求，避免服务器挂掉，保证大部分用户可用

页面优化，动静分离

• 秒杀商品的网页内容尽量作的简单：图片小、js css 体积小数量少，内容尽量的作到动静分离
• 秒杀的抢宝过程当中作成异步刷新抢宝，而不须要用户刷新页面来抢，下降服务器交互的压力
• 可使用Nginx的动静分离，不经过传统web浏览器获取静态资源
• nginx开启gzip压缩，压缩静态资源，减小传输带宽，提高传输速度
• 或者使用Varnish，把静态资源缓存到内存当中，避免静态资源的获取给服务器形成的压力

异步处理

• redis抢单成功后，把后续的业务丢到线程池中异步的处理，提升抢单的响应速度
• 线程池处理时，把任务丢到MQ中，异步的等待各个子系统处理（订单系统、库存系统、支付系统、优惠券系统），异步操做有事务问题，本地事务和分布式事务，可是为了提高并发度，最好牺牲一致性。经过定时扫描统计日志，来发现有问题的订单，而且及时处理

热点分离

尽可能的避免秒杀功能给正常功能带来的影响，好比秒杀把服务器某个功能拖垮了
分离能够提高系统的容灾性，可是彻底的隔离的改形成本过高了，尽可能借助中间件的配置，来实现冷热分离

• 集群节点的分离：nginx配置让秒杀业务走的集群节点和普通业务走的集群不同。
• MQ的分离：避免秒杀业务把消息队列堆满了，普通业务的交易延迟也特别厉害。
• 数据库的分离：根据实际的秒杀的QPS来选择，热点数据分库之后，增长了分布式事务的问题，以及查询的时候跨库查询性能要差一些（ShardingJDBC有这种功能），因此要权衡之后再决定是否须要分库

避免单点

各个环节都要尽力避免

降级

临时关闭一些没那么重要的功能，好比秒杀商品的转赠功能、红包的提现功能，待秒杀峰值过了，设置开关，再动态开放这些次要的功能