- 博客(6)
- 收藏
- 关注
RSS订阅原创 电商秒杀平台项目记录 Day6
对于秒杀系统来说，秒杀时请求瞬间的秒杀流量是不可控的，没办法准确预估多少，但是秒杀系统的处理能力是有限的，当流量过大时服务器会被打挂流量控制（flow control），其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，保护系统不会被压垮，从而保障应用的高可用。紧接着，服务A也变为不可用，整个调用链路被拖垮。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。
2024-05-29 13:01:02
118
原创 电商秒杀平台项目记录 Day5
缓存预热指的是当我们在秒杀活动开始之前，把热门商品的信息和活动信息写入redis中，这样当秒杀活动开始时，访问请求就会先去访问redis缓存，如果缓存中没有这个信息再去访问数据库。静态化是指把动态生成的HTML页面变为静态内容保存，以后用户的请求到来，直接访问静态页面，不再经过服务的渲染。而静态的HTML页面可以部署在nginx中，从而大大提高并发能力，减小tomcat压力。当活动还没开始时，显示倒计时，并且抢购按钮是灰色的按不了的，这样子就可以避免在活动开始前的1个小时大家不断刷新 不断请求这样的行为。
2024-05-29 12:49:34
162
原创 电商秒杀平台项目记录 Day4
这样的好处就是，当用户创建订单时，我们只是将redis中缓存的库存数据给进行锁定，然后同步调用付款接口，接着当消费者真正付款之后，我们才去数据库里将库存减1，如果付款失败的话，我们就将原先的锁定的库存解锁返还，而真正库存的数量其实并没有变化。最后还添加了一个代码块用来把购买者从限购名单里移出去的代码块（如果未付款，则购买失败，移出限购名单），利用redis中的srem来把购买者从限购名单里移出去。首先先完善了“添加限购名单”的代码块，利用redis中的sadd的功能把购买者加入redis数据库里去。
2024-05-29 12:28:56
228
原创 电商秒杀平台项目记录 Day3
可以把消息队列理解成为一个上面宽，下面窄的漏勺，比如原本经过redis处理过后的剩下1000/s的请求，还是很多，因为我们Mysql一次最多只能处理200/s的订单创建，那么消息队列就会通过缩口以固定合适的流速流出给consumer也就是数据库。-可以把它理解为平常我们取快递用的丰巢，有了丰巢，快递员（也就是producer）不需要等我们（也就是consumer）取了快递才能送下一单，他们一天可以送很多单，效率和产出都高很多，这也就是异步解耦的思想。-趋势递增：ID按时间顺序递增，适合需要排序的场景。
2024-05-27 12:07:44
1839
原创 电商秒杀平台记录 Day2
接着尝试了简单处理：如果库存stock > 0, 就抢购成功，available stock - 1，然后secKill ActivityDao调用update方法把库存更新。Lua脚本方案解决思路：首先用户先发出秒杀请求，Lua脚本读Redis库存并扣减，根据扣减成功分为2种情况，1.扣减失败，说明秒杀活动结束。首先先思考了秒杀为什么会导致库存超卖的原因：每个秒杀的用户都去数据库查询库存，校验库存，然后扣减库存，当用户量一大便容易导致数据库崩溃。-秒杀的活动表单应该有哪些对应的字段。
2024-05-26 14:34:55
729
原创 电商秒杀平台记录 Day1
再者，RocketMQ的数量支持几百几千的Topic，而kafaka只支持几百上千的topic，也是不如RocketMQ。-限流（Ratelimit），流量控制（flow control）也就是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮。-服务熔断（Circuit-breaker），也就是当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。-流程短，立即购买，下订单，减库存。
2024-05-26 13:03:54
1796
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人