你们系统的秒杀是如何设计的(面试题)

总结:上分布式架构、上各种缓存技术、搞一搞负载均衡之类的。提高并发的处理能力。防止超卖等问题,就需要使用分布式锁机制。事先将库存同步到redis里面,直接规避了数据库的操作。咱们可以在扣除库存成功之后,很多后续处理都可以基于mq这种异步的形式来完成。这个时候rocketmq的消息确认机制就是蛮合适的。为了公平性,需要对用户的请求。做一些防刷措施。做一些验证码或者做一些ip的限制等等来规避刷单的这种行为。同时,秒杀活动中可能会出现各种异常,比如:网络延迟、系统故障等等,这种不可控的一种情况,需要在系统中进行一些异常处理,比如说我搞搞重试、做做降级等保证系统可以稳定的运行。再有就是安全方面了,可以防止一些恶意的攻击、数据泄露,可以上个https,对请求传递过来的数据做一个加密的处理等。再有就是一个前端的优化,比方说做一些页面的静态化、搞搞cdn加速来提高系统的访问速度。差不多就这些,不过具体的设计方案还是要根据具体的业务场景、系统规模进行一些细微的调整。秒杀这个东西并没有什么固定的答案。

https://www.bilibili.com/video/BV1Mf421B74D/?p=3&spm_id_from=pageDriver&vd_source=273847a809b909b44923e3af1a7ef0b1

秒杀业务场景如何去设计?

需求:12306抢票。大明星的演唱会。300万人 -> 1万张票。0.5s就空了。

难点在哪里?

1、限流:nginx上做限制(nginx限流主要能够保证我们的网关不被冲垮)、服务层做限制(redis做计数器、使用gateway网关提供的限流的方法)。

2.抗住高并发的TPS,瓶颈就在MySQL定义一张订单表、座位表(1W条数据)

3.安全机制(锁机制确保不能重复抢票)

秒杀的业务流程如何设计

1)管理后台,提前维护秒杀活动-》设计到一些表,进行CURD。

2)运用redis把秒杀的活动上线:数据写入到redis(活动信息(string)+商品信息(hash)+库存信息(string))

image

image

image

rokcetmq不是一次消费一条消息,是一次消费多条消息。说白了就是消费者消费到消息之后,会先进行同类商品的一个汇总,而不是一条一条的更新库存表,减少库存。是分批次更新的,这样效率也就提高了,同时也减轻了数据库的压力。

面试官:如何不重复消费消息,如何保证消息的不丢失?

我们可以借助redis来做,将我们需要校验的信息放到redis里面,再次消费的时候看看redis里面有没有就可以了。

消息不丢失:我们在往mq中发送消息的时候要采用这种可靠的消息发送机制,比如,我们采用同步刷盘的机制来保证生产者发送消息到broker中,当然,rocketmq底层他也有这种重试机制,比方说我第一次没有发送成功会默认进行重试。也就是说,我将消息推送给rocketmq的时候一定要收到rocketmq的ack确认。

当然rocketmq一般情况下是集群部署,我们可以采用同步复制的机制来保证消息最起码同步到一个从节点上。

当我们消费者消费rocketmq集群中的消息的时候,也要先消费,消费成功后在手动提交ack确认。

千万级别的并发,那都是QQ、微信才会有的规模,也就是说在给面试官吹的时候,不要太过了。

redis单机QPS能够达到10万。就说自己的秒杀项目qps是QPS万左右。

秒杀系统是我们电商系统中常见的一种业务模式,用于吸引用户,刺激留存及消费所做的一种活动。秒杀系统的例子:整点秒杀、商品秒杀秒杀系统的特点:
1、瞬时流量极大,过了秒杀时间点流量结束。所以不能用机器堆qps。
2、秒杀商品库存极少,例如1w个用户去抢10瓶茅台。
3、秒杀时间点未到的时候,刷新量极大,静态资源被访问剧增

如果秒杀系统采用堆机器的方式来增加qps那么就太浪费资源了,成本太高。

秒杀系统一般流程:
1、运营策划秒杀活动,选品,在秒杀中台建立秒杀活动,需要距秒杀开始提前一段时间。同时将秒杀数据,库存等信息写入缓存
2、业务方研发根据实际情况来看自身机器是否可以扛得住
3、用户进行秒杀。

针对于以上秒杀系统的特点,我们映射到技术层面上,就有如下一些要考虑的点。
1、高并发,快响应:秒杀一般是C端产品吸引用户的点,需要考虑用户体验。并发量极高,对服务有要求,要抗住并发

2、防止超卖:商品数量有限,不能因为大用户量高并发扣减库存,导致商品超卖,库存变负。

3、防刷子:防止机器人,恶意刷子,去抢占订单,导致正常用户抢不到商品。

4、页面资源访问多:需要考虑静态化,CDN,静态资源缓存及压缩。
5、秒杀按钮:通过前端的按钮进行限制一些请求打到后端。按钮置灰。
6、秒杀真链接隐藏:防止后台交互链接,非秒杀期间漏出

7、异步处理订单后续:秒杀成功后,订单必理交于异步服务

8、订单失败补偿:遇到订单后续处理失败,必须补偿

9、服务降级:遇到紧急情况,可以快速必理

针对于请求和用户的高并发。我们需要在上线之前,首先要做好压测,知道服务qps瓶颈点。针对我们的日常业务秒杀的预估进行服务器的准备。测量tps,寻找薄弱点进行代码优化,服务支撑优化,
一般采用redis+热数据+mg。前端辅以静态化,cdn加速。带宽扩展。集群负载均衡。

image

image

posted on 2024-09-27 17:06  ~码铃薯~  阅读(4)  评论(0编辑  收藏  举报

导航