超详细的秒杀架构设计，运维，认识一下
发布时间：2022-07-16 12:17:31 所属栏目：云计算 来源：互联网
导读：秒杀系统相信很多人见过，比如京东或者淘宝的秒杀，小米手机的秒杀，那么秒杀系统的后台是如何实现的呢？我们如何设计一个秒杀系统呢？对于秒杀系统应该考虑哪些问题？如何设计出健壮的秒杀系统？本文我们就来探讨一下这个问题。 超详细的秒杀架构设计，运维
|
秒杀系统相信很多人见过，比如京东或者淘宝的秒杀，小米手机的秒杀，那么秒杀系统的后台是如何实现的呢？我们如何设计一个秒杀系统呢？对于秒杀系统应该考虑哪些问题？如何设计出健壮的秒杀系统？本文我们就来探讨一下这个问题。 超详细的秒杀架构设计，运维，了解一下 秒杀应该考虑哪些问题 超卖问题 分析秒杀的业务场景,最重要的有一点就是超卖问题，假如备货只有100个，但是最终超卖了200，一般来讲秒杀系统的价格都比较低，如果超卖将严重影响公司的财产利益，因此首当其冲的就是解决商品的超卖问题。 高并发 秒杀具有时间短、并发量大的特点，秒杀持续时间只有几分钟，而一般公司都为了制造轰动效应，会以极低的价格来吸引用户，因此参与抢购的用户会非常的多。短时间内会有大量请求涌进来，后端如何防止并发过高造成缓存击穿或者失效，击垮数据库都是需要考虑的问题。 接口防刷 现在的秒杀大多都会出来针对秒杀对应的软件，这类软件会模拟不断向后台服务器发起请求，一秒几百次都是很常见的，如何防止这类软件的重复无效请求，防止不断发起的请求也是需要我们针对性考虑的。 秒杀 URL 对于普通用户来讲，看到的只是一个比较简单的秒杀页面，在未达到规定时间，秒杀按钮是灰色的，一旦到达规定时间，灰色按钮变成可点击状态。这部分是针对小白用户的，如果是稍微有点电脑功底的用户，会通过F12看浏览器的network看到秒杀的url，通过特定软件去请求也可以实现秒杀。或者提前知道秒杀url的人，一请求就直接实现秒杀了。这个问题我们需要考虑解决。 数据库设计 秒杀有把我们服务器击垮的风险，如果让它与我们的其他业务使用在同一个数据库中，耦合在一起，就很有可能牵连和影响其他的业务。如何防止这类问题发生，就算秒杀发生了宕机、服务器卡死问题，也应该让他尽量不影响线上正常进行的业务。 大量请求问题 按照「高并发」的考虑，就算使用缓存还是不足以应对短时间的高并发的流量的冲击。如何承载这样巨大的访问量，同时提供稳定低时延的服务保证，是需要面对的一大挑战。我们来算一笔账，假如使用的是 Redis 缓存，单台 Redis 服务器可承受的 QPS 大概是 4W 左右，如果一个秒杀吸引的用户量足够多的话，单 QPS 可能达到几十万，单体 Redis 还是不足以支撑如此巨大的请求量。缓存会被击穿，直接渗透到 DB，从而击垮MySQL，后台会将会大量报错。 秒杀系统的设计和技术方案 秒杀系统数据库设计 针对「数据库设计」提出的秒杀数据库的问题，因此应该单独设计一个秒杀数据库，防止因为秒杀活动的高并发访问拖垮整个网站。这里只需要两张表，一张是秒杀订单表，一张是秒杀货品表。 超详细的秒杀架构设计，运维，了解一下 其实应该还有几张表，商品表：可以关联goods_id查到具体的商品信息，商品图像、名称、平时价格、秒杀价格等，还有用户表：根据用户user_id可以查询到用户昵称、用户手机号，收货地址等其他额外信息，这个具体就不给出实例了。 秒杀 URL 的设计 为了避免有程序访问经验的人通过下单页面url直接访问后台接口来秒杀货品，我们需要将秒杀的 URL 实现动态化，即使是开发整个系统的人都无法在秒杀开始前知道秒杀的URL 。具体的做法就是通过 md5 加密一串随机字符作为秒杀的 URL，然后前端访问后台获取具体的 URL，后台校验通过之后才可以继续秒杀。 秒杀页面静态化 将商品的描述、参数、成交记录、图像、评价等全部写入到一个静态页面，用户请求不需要通过访问后端服务器，不需要经过数据库，直接在前台客户端生成，这样可以最大可能的减少服务器的压力。具体的方法可以使用freemarker模板技术，建立网页模板，填充数据，然后渲染网页。 单体 Redis 升级为集群 Redis 秒杀是一个读多写少的场景，使用 Redis 做缓存再合适不过。不过考虑到缓存击穿问题，我们应该构建 Redis 集群，采用哨兵模式，可以提升Redis的性能和可用性。 使用 Nginx Nginx 是一个高性能 Web 服务器，它的并发能力可以达到几万，而 Tomcat 只有几百。通过 Nginx 映射客户端请求，再分发到后台 Tomcat 服务器集群中可以大大提升并发能力。 精简 SQL 典型的一个场景是在进行扣减库存的时候，传统的做法是先查询库存，再去update。这样的话需要两个SQL，而实际上一个SQL我们就可以完成的。可以用这样的做法：update miaosha_goods set stock =stock-1 where goods_id ={#goods_id} and version = #{version} and stock>0;这样的话，就可以保证库存不会超卖并且一次更新库存，还有注意一点这里使用了版本号的乐观锁，相比较悲观锁，它的性能较好。 Redis 预减库存 很多请求进来，都需要后台查询库存,这是一个频繁读的场景。可以使用Redis来预减库存，在秒杀开始前可以在 Redis 设值，比如 redis.set(goodsId,100)，这里预放的库存为100可以设值为常量，每次下单成功之后，Integer stock = (Integer)redis.get(goosId); 然后判断 sock 的值，如果小于常量值就减去1；不过注意当取消的时候，需要增加库存，增加库存的时候也得注意不能大于之间设定的总库存数（查询库存和扣减库存需要原子操作，此时可以借助 lua 脚本）下次下单再获取库存的时候，直接从Redis里面查就可以了。 接口限流 秒杀最终的本质是数据库的更新，但是有很多大量无效的请求，我们最终要做的就是如何把这些无效的请求过滤掉，防止渗透到数据库。限流的话，需要入手的方面很多： 前端限流 首先第一步就是通过前端限流，用户在秒杀按钮点击以后发起请求，那么在接下来的5秒是无法点击（通过设置按钮为disable）。这一小举措开发起来成本很小，但是很有效。 （编辑：我爱制作网_潮州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330565号