网站的设计与开发的图片,wordpress 积分打赏,无需登录网页小游戏网站,网上花店 网站源代码秒杀场景的设计思考
在学习Redis的之后#xff0c;一个绕不开的话题就是秒杀系统的设计。本文将从下面#x1f447;#x1f3fb;几个方面展开一下个人简单的理解#xff1a;
秒杀场景的介绍设计的核心思路怎么限流、削峰、异步planB总结
秒杀场景的介绍
秒杀场景是…秒杀场景的设计思考
在学习Redis的之后一个绕不开的话题就是秒杀系统的设计。本文将从下面几个方面展开一下个人简单的理解
秒杀场景的介绍设计的核心思路怎么限流、削峰、异步planB总结
秒杀场景的介绍
秒杀场景是大家常说的高并发场景但是实际上其与单纯的高并发还有一点不同主要区别就是其流量来的猛增几乎是一个垂直的增长而非线性增长的并发。
其具有如下特点
瞬时高并发读多写少不能超卖
设计的核心思路
在解决系统架构的问题上我们设计可以参考三要和一不要的原则从一些通用性的角度提高一些系统健壮性
要要减少请求数据量要减少请求次数要减少依赖不要不要有“单点”
要减少请求数据量后台返回前台的数据一般分为动态数据和静态数据对于秒杀场景我们可以考虑动静分离对于不怎么会变化的数据我们可以用cache、cdn等手段来直接处理避免对后端资源的占用对于库存这样的动态数据我们才真正的去调用关键的接口和服务器。
要减少请求的次数减少请求数最常用的一个实践就是合并CSS和JavaScript文件把多个JavaScript文件合并成一个文件。这种方式在服务端仍然是单个文件各自存放只是服务端会有一个组件解析这个URL然后动态把这些文件合并起来一起返回。 有些同学会感觉这个第二点和第一点不是冲突的吗 第一点说要减少请求数据量所以要使用动静结合第二点又说要减少请求的次数和第一点不是矛盾了吗实际上确实有一些矛盾的地方就看取舍了不同场景的考虑不一样在秒杀场景来说动静分离的好处肯定是比 动静合并一起返回的带来的收益更大的。 要减少依赖这点很好理解。我们在设计系统的时候在能满足需求和拓展性等能力的基础上系统的架构约简单越好。此外在架构设计的时候我们必须要很好的梳理清楚系统的强弱依赖这样才能在发生系统瓶颈或者异常的情况下及时定位到问题并解决。
不要有“单点” 在分布式的架构设计的时候我们的一个大忌就是“单点”问题而解决的方法就是一般来说就是服务无状态话。服务无状态之后我们可以非常方便的进行服务的扩容和迁移等。当然对于数据库这样保存数据的服务很难没办法做到无状态话这时我们一般会采用冗余备份等方法增强其可靠性。
如何防止瞬时高并发
主要三个措施缓存预热、流量限制。 我们也可以从事前、事中、事后的时间轴的角度来理解事前缓存预热事后流量限制、以及一些常用手段限流、削峰、异步事后并发较低主要考虑对库存的一些处理。 缓存预热
我们可以对热点数据进行预热热点数据就是指那些被秒杀的商品的一些信息。可以在秒杀开始之前将这些热点数据提前加载在缓存中。 对于提前并不能得知哪些数据是热点的情况我们可以考虑进行一些动态的数据分析来获取热key比如京东开源的hotkey框架。 流量限制
在秒杀场景中我们最有可能出现性能瓶颈的地方是用于控制库存的DB因此需要尽量控制进入DB中的并发量。
可以从两个角度考虑非后端角度降低并发量 后端角度降低并发量。
非后端角度限制并发
非后端角度降低并发量指的是在流量打到后端处理秒杀的服务器之前就降低并发量常见的角度为
1.人为增加流程比如说答题系统。答题系统的增加一方面来说由于人的答题速度不一致一定程度上是分散了并发数量另一方面来说也可以一定程度上防止用户使用作弊器的行为又比如说前端通过限频降低并发数量让用户点击的时候实际上不是每次点击都真正有效。
2.分层过滤通过分层的措施每一层减少一部分流量。如下图所示真正访问到DB中的并发量相对于用户访问量来说已经是一个很少的比例了。
后端角度限制并发
后端限制并发就是一些通用的手段了常见的有
使用mq进行异步削峰使用线程池限制并发数量使用缓存使用缓存当然要考虑一致性问题在秒杀场景就是“超卖问题文章后面关于超卖|库存如何扣减会讨论
补充
库存何时扣减
库存的扣减一般来说有3种时机
下单时扣减库存买家只要完成下单立即减扣商品库存这种方式实现是最简单而且也是最精准的通常可以在下单时利用数据库事务能力即可保证减扣库存的准确性但需要考虑买家下单后不付款的情况。付款时扣减库存卖家下单的时候不扣减库存付款的时候才扣减库存。好处是不需要考虑下单不付款的库存回填的情况坏处则是并发量大会出现大量用户能下单但是付款无法完成显示库存不足 。结合前2种方案下单时保留一定时间的库存下单的时候扣减库存如果用户30min时间内没有完成付款那么就释放库存其它用户可以继续抢购。
可以结合平时网上下单的步骤想一下我们下单需要哪几个步骤1.点击下单2.填写地址并付款。 根据在淘宝购买商品的经验综合用户体验和实际架构一般来说选择方案3。
关于超卖|库存如何扣减
库存是放在MySQL中进行处理的因此库存扣减判断的最终参考指标是利用数据库的本地事务机制进行对库存的减扣比如使用 where 库存 0不满足就回滚。
但是在实际的秒杀场景架构中肯定是会引入 Redis这样的缓存。 在引入缓存之后我们就必须考虑缓存的一致性问题一个很有意思的一点是在秒杀场景中一般来说我们不需要强保证缓存和数据库中关于库存数据的一致性。 即我们可以允许一定量的在Redis这一层的“超卖”Redis“超卖”后超卖的请求的数量不会太大这些数量可以交给MySQL进行处理。 上面一段中提到“这些数量可以交给MySQL进行处理”那么究竟多少数据可以交给MySQL处理呢 实际上这就体现出压测的重要性了这些请求究竟并发量由多少MySQL可以承载多少理论分析只能有个指导值具体有多少必须跑一跑压测才知道 planB
前面我们提到了很多关于秒杀场景的设计包括如何减少后端压力、如何设计库存扣减等等来保证系统的高性能。 然而无论再精细的设计也只能保证系统尽可能健壮因此我们在设计的时候必须考虑高可用方案。
关于如何设计高可用的方案就是一个比较复杂的话题了而且需要根据不同的系统和性能指标要求有不同的取舍这里大概列出需要考虑的方面 防止单点问题 防止影响扩大隔离 如何降级、熔断
总结
秒杀场景是一个高可用场景中的典型类型其拥有高并发、读多写少、严格数据保证不能超卖的特点。 首先的思路是降低直接打入DB的并发量可以考虑分层降低流量和增加步骤等操作降低并发。 其次库存扣减时机和超卖问题也有很多值得讨论的地方。 最后再复杂的设计也有可能发生意外因此我们必须考虑高可用的方案planb。
此外在实际的场景中除了正常的请求之外往往我们还要考虑一些其他东西比如说灰产、用户恶意锁单等情况。
主要参考
geektime专栏06 | 秒杀系统“减库存”设计的核心逻辑-如何设计一个秒杀系统-极客时间后端进阶面试官问我如何设计一个秒杀场景-阿里云开发者社区面试必备秒杀场景九个细节-腾讯云开发者社区-腾讯云 这个方案很详细但是讲的很乱想了解细节可以看看
