订单秒杀解决方案
2021-11-27 15:03:59 3 举报AI智能生成
订单秒杀解决方案是一种针对电商平台在特定时间内高并发访问和大量订单生成问题的解决方案。通过采用分布式缓存、消息队列、负载均衡等技术手段，实现对用户请求的快速响应和订单处理能力的提升。同时，通过对数据库进行优化和读写分离，降低数据库压力，确保系统稳定运行。此外，还可以采用限流、熔断等策略，防止恶意攻击和系统崩溃。总之，订单秒杀解决方案旨在为电商平台提供一种高效、稳定、可靠的秒杀服务，满足用户对热门商品的需求，提升用户体验和商家销售额。
作者其他创作
大纲/内容
秒杀商品详情页解决方案
页面静态化
实现方式：通过FreeMarker创建每个商品的静态页面，避免每次请求都直接访问服务端。
优势：实现方式很简单。适用于产品相对比较少的商城，如小米商城。
劣势：更新HTML页面时需要进行全量复制，在商品比较多的商城，如京东，做全量复制是不现实的。
CDN+Nginx+Redis多级缓存
实现方式
一级缓存
请求秒杀商品详情页数据时，从就近的CDN加载，不需要每次都请求远端机房。
Nginx+lua实现本地缓存，提前把秒杀商品详情页放在Nginx，可以从Nginx中直接加载详情页。
二级缓存
有可能存在Nginx的缓存过期的情况，此时请求服务器的本地缓存。
三级缓存
如果还是没有找到，转发请求到Redis集群，加载详情页。
下单TPS压力过大解决方案
加数据库服务器
实现方式
分库分表，主从分离
存在问题
成本飙升，并且在秒杀场景中大部分都是无效请求，打入数据库是一种资源浪费。
库存超卖，虽然MySQL可以通过悲观锁或乐观锁去处理库存超卖的问题，但是性能不佳，并且容易存在数据库级别的问题（如悲观锁容易锁表，乐观锁容易发生多次访问数据的问题）
服务器分离
实现方式
将普通下单服务器和秒杀服务器分离, 若出现秒杀服务器崩溃,或不稳定的问题,也不会影响其他的下单操作。
Redis缓存拦截请求
实现方式
通过Redis记录库存数量，并且在进行库存扣减时先扣减Redis的库存。
抢购完毕后过滤请求
实现方式
一旦商品抢购完毕，可以在Redis或者ZK添加一个标记位，然后ZK反向通知Nginx中我们写好的lua脚本，通过lua脚本实现在Nginx过滤请求。
瞬时高并发场景秒杀下单进行削峰填谷
实现方式
当Redis成功进行库存扣减，及发送MQ消息，给Consumer进行订单创建等逻辑，创建完成之后，返回订单号保存到Redis中，当进行回调查询的时候，可以通过Redis获得订单创建结果。
实现消费者种类
异步下单
执行正常的下单操作。
库存同步
有可能出现的情况，Redis库存剩余2件商品，但是顾客需要买3件，此时就会出现库存为负数的情况，所以需要发送一条延时MQ消息，同步MySQL的库存情况。
延迟回滚
在执行下单操作之后，发送一个延迟的MQ消息，在一段时间后，检查顾客是否已经支付订单，若未支付则回滚库存，标记位，并对过期订单进行关闭。
通过前端限流
实现方式
在前端设置答题或验证码
错开下单时间,防止刷单
秒杀前预约
在活动中提前发放token,例如10件商品抢购, 前1000个人可以获得token,其他人虽然点了预约,但是无法获得token,最终效果是直接通过token过滤掉大部分的人
保证运行阶段稳定性解决方案
自动化运维
自动开关降级
配置超时(访问时间维度)
调用远程服务时,响应过慢会自动降级,先不调用
统计失败次数(访问成功率维度)
对不是特别稳定的服务,当调用失败到一定次数,即自动降级,通过异步线程去勘探服务存活情况,可用后恢复
限流(QPS维度)
当流量到达阈值,启动限流保护,后续请求自动降级
故障(服务是否存活维度)
服务不可用的情况,实现降级,返回默认参数
手动开关降级
秒杀活动前,一些非核心业务进行手动降级,节约系统资源
功能降级
读降级
对商品详情页的商家信息,推荐信息,配送至信息等不适核心的参数,压力较大时可以进行降级处理。在促销活动前，可以把整个页面切换为静态化，最大程度的降级读服务。
写降级
写降级的思路基本就是同步写转异步写，如redis扣减缓存操作，若数据库性能跟不上，可以先发送到队列，再慢慢写入数据库，实现最终一致性
多层限流
前端限流
主要控制页面功能的降级，在页面中通过JS脚本部署来控制在适当时机开启/关闭开关
接入层限流
Nginx限流
通过限制连接数或请求数控制
limit_conn_zone&limit_conn
limit_req_zone&limit_req
网关限流
通过网关控制接口流量, 或关联接口流量。
应用层限流
在应用中配置响应的功能开关，根据实际情况进行自动/人工降级。如给进入持久层的实现方法添加限流规则，若流量过大，对上游接口进行限流
0 条评论
下一页
