秒杀项目常见面试题

秒杀项目常见面试题

0、介绍一下你的项目?

为什么做这个项目?

希望将过去所学的一些知识做一个系统的深入理解。秒杀项目运用场景多,涉及的问题与中间件较为复杂,更有利于对web服务的深入学习。

详细过程?

本项目主要是为了模拟一种高并发的场景,请求到达nginx后首先经由负载轮询策略到达某一台服务器中(后端部署了两台服务器)。为了解决秒杀场景下的入口大流量、瞬时高并发问题。引入了redis作为缓存中间件,主要作用是缓存预热、预减库存等等。引入秒杀令牌与秒杀大闸机制来解决了入口大流量问题。引入线程池技术来解决了浪涌(高并发)问题。

1、秒杀中如何处理超卖问题?(网易)(百度)(美团)(滴滴)(字节)

直接由数据库操作库存的sql语句如下所示。依靠MySQL中的排他锁实现

 update table_prmo set num = num - 1 WHERE id = 1001 and num > 0

利用redis的单线程特性预减库存处理秒杀超卖问题!!!

  1. 在系统初始化时,将商品以及对应的库存数量预先加载到Redis缓存中;(缓存预热)
  2. 接收到秒杀请求时,在Redis中进行预减库存(decrement),当Redis中的库存不足时,直接返回秒杀失败,否则继续进行第3步;
  3. 将请求放入异步队列中,返回正在排队中;
  4. 服务端异步队列(MQ)将请求出队,出队成功的请求可以生成秒杀订单,减少数据库库存,返回秒杀订单详情。

2、秒杀中如何解决重复下单问题?(网易)

mysql唯一索引(商品索引)+ 分布式锁

3、热点数据失效(缓存击穿)问题如何解决?(网易)(美团)

设置热点数据永远不过期。

4、缓存和数据库数据一致性如何保证?(shopee)(美团)(网易)

  • 使用canal组件实现(canal的原理,模拟MySQL的主从复制机制)

  • 更新数据库后立即删缓存,然后下一次查缓存找不到数据后会再次从数据库同步到缓存。

5、减库存成功了,但是生成订单失败了,该怎办?(shopee)(美团)(华为)

非分布式的系统中使用Spring提供的事务功能即可。

**分布式事务:**将减库存与生成订单操作组合为一个事务。要么一起成功,要么一起失败。

CAP理论(只能保证 CP、AP)、BASE理论(最终一致性,基本可用性、柔性事务)。

分布式事务的两个协议以及几种解决方案:

  1. 全局消息
  2. 基于可靠消息(MQ)的分布式事务
  3. TCC
  4. 最大努力通知
<think>好的,用户想准备分布式事务相关的面试问题,需要常见面试题及答案解析。首先,我需要整理分布式事务的核心知识点,然后根据常见面试问题来组织答案。 首先,分布式事务的定义和挑战。用户可能被问到什么是分布式事务,为什么需要它。需要解释ACID特性在分布式环境中的困难,比如网络分区、节点故障等。这里可以引用参考中的可靠消息最终一致性[^2]。 接下来,常见解决方案。两阶段提交(2PC)是经典方法,需要解释准备阶段和提交阶段,以及优缺点。比如同步阻塞、单点故障的问题。然后是TCC(Try-Confirm-Cancel),补偿事务,适用于高并发场景。还有本地消息表,通过消息队列实现最终一致性,比如引用[2]提到的最终一致性。 可能的问题还包括CAP理论的应用,如何选择一致性和可用性。这里需要区分CP和AP系统的不同。另外,BASE理论作为ACID的补充,强调基本可用和最终一致。 面试题还可能涉及实际场景,比如电商下单如何保证库存和订单的一致性,这时候可以用TCC或消息队列的例子。此外,如何处理分布式事务中的异常情况,比如悬挂问题,需要解释TCC中的空回滚和业务设计上的预防措施。 还要注意引用用户提供的资料,比如可靠消息最终一致性,以及结合大厂面经和实战项目[^3]的内容,让答案更权威。需要确保LaTeX格式正确,数学公式用$...$,独立公式用$$...$$,比如提到事务的ACID属性时,可以用$ACID$。 最后,生成相关问题时要覆盖理论、实现、优缺点和实际应用,确保全面性。检查是否有遗漏的重要点,比如Seata框架、最大努力通知等方案。确保每个答案部分结构清晰,逐步解释,帮助用户理解。</think>### 分布式事务常见面试题及答案解析 #### 1. **什么是分布式事务?为什么需要分布式事务?** 分布式事务指跨越多个数据库或服务的事务操作,要求所有参与节点要么全部提交成功,要么全部回滚。其核心挑战在于满足$ACID$(原子性、一致性、隔离性、持久性)特性在分布式环境中的实现[^1]。 **答案解析**: - **场景示例**:电商系统中,用户下单需同时扣减库存、生成订单、支付扣款,这些操作可能分布在不同的服务中。若某一步失败,需保证所有操作回滚。 - **技术难点**:网络延迟、节点故障、数据不一致性等问题需通过分布式事务协议解决。例如,通过最终一致性模型实现跨服务协同。 --- #### 2. **分布式事务的常见解决方案有哪些?** **答案解析**: 1. **两阶段提交(2PC)** - **流程**: 1. **准备阶段**:协调者询问所有参与者是否可以提交,参与者锁定资源并返回响应。 2. **提交阶段**:若所有参与者同意,协调者发送提交命令;否则发送回滚命令。 - **缺点**:同步阻塞(资源锁定时间长)、单点故障(协调者宕机导致阻塞)。 2. **TCC(Try-Confirm-Cancel)** - **流程**: 1. **Try**:预留资源(如冻结库存)。 2. **Confirm**:确认提交(实际扣减库存)。 3. **Cancel**:失败时释放资源。 - **适用场景**:高并发业务(如秒杀),需业务代码实现补偿逻辑。 3. **本地消息表(可靠消息最终一致性)** - **流程**: 1. 事务发起方将消息写入本地数据库,完成业务操作后发送消息到MQ。 2. 消费者消费消息并执行业务,失败时重试。 - **优点**:去中心化,适用于异步场景[^2]。 4. **Seata框架** - **原理**:通过全局事务ID管理分支事务,支持AT(自动补偿)、TCC等模式。 --- #### 3. **CAP理论如何影响分布式事务设计?** **答案解析**: - **CAP定理**:分布式系统最多同时满足一致性(Consistency)、可用性(Availability)、分区容错性(Partition Tolerance)中的两项。 - **应用场景**: - **CP系统**:如银行转账,优先保证一致性(如2PC)。 - **AP系统**:如电商库存,允许短暂不一致(如最终一致性模型)。 --- #### 4. **如何解决TCC模式中的“悬挂”问题?** **答案解析**: - **问题描述**:网络异常可能导致Try未执行,但Cancel先被触发(空回滚)。 - **解决方案**: 1. 在Try阶段记录事务日志,Cancel执行前检查Try是否完成。 2. 使用唯一事务ID标记操作,确保幂等性。 --- #### 5. **BASE理论的核心思想是什么?** **答案解析**: - **基本可用(Basically Available)**:系统故障时允许部分功能降级。 - **软状态(Soft State)**:允许中间状态存在(如订单“处理中”)。 - **最终一致性(Eventually Consistent)**:数据经过一段时间后达成一致。 --- #### 6. **如何设计一个可靠消息队列实现最终一致性?** **答案解析**: 1. **消息生产端**: - 业务操作与消息写入本地数据库在同一个事务中完成。 - 后台任务轮询本地消息表,将未发送的消息投递到MQ。 2. **消息消费端**: - 保证消费幂等性(如通过唯一ID去重)。 - 失败时重试,超过阈值则人工介入。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值