26字节-支付业务-二面面经

在分布式系统中，事务需要跨多个服务或数据库执行，传统的ACID事务（单机数据库事务）无法直接适用，因此需要**分布式事务**机制来保证数据一致性。以下是分布式事务的核心概念、挑战及主流解决方案。---##**# deepseek#1. 什么是分布式事务？****定义**：分布式事务是指事务的参与者（如多个微服务、数据库、消息队列等）分布在不同的节点上，需要协调这些节点共同完成一个全局事务，保证所有操作要么全部成功，要么全部失败。### **典型场景**- **跨行转账**：A银行扣款，B银行加款。- **订单支付**：扣减库存 + 创建订单 + 支付。- **跨服务调用**：用户注册（用户服务 + 积分服务）。---## **2. 分布式事务的挑战（CAP理论）**在分布式系统中，无法同时满足 **CAP**（一致性 Consistency、可用性 Availability、分区容错性 Partition Tolerance）三个特性，必须权衡取舍：| **特性**       | **说明**                                                                 ||----------------|-------------------------------------------------------------------------|| **一致性 (C)** | 所有节点在同一时间的数据完全一致（强一致性）。                           || **可用性 (A)** | 每个请求都能得到响应（不保证最新数据）。                                 || **分区容错 (P)** | 系统在部分节点故障时仍能继续运行（分布式系统必须满足）。                 |**结论**：- **CP系统**（如ZooKeeper）：保证一致性，牺牲可用性（如选举期间不可用）。- **AP系统**（如Cassandra）：保证可用性，牺牲强一致性（最终一致性）。- **CA系统**（如单机MySQL）：不适用于分布式环境（无法容忍网络分区）。---## **3.1 2PC（两阶段提交）****原理**：1. **准备阶段（Prepare）**：协调者询问所有参与者是否可以提交。2. **提交阶段（Commit/Rollback）**：如果所有参与者都同意，则提交；否则回滚。**优点**：- 强一致性（所有节点要么全部提交，要么全部回滚）。  **缺点**：- **同步阻塞**：参与者必须等待协调者决策，性能低。- **单点故障**：协调者宕机会导致事务阻塞。- **数据不一致风险**：第二阶段部分参与者可能未收到提交指令。**适用场景**：- 传统数据库（如XA协议），适用于短事务、低并发场景。---### **3.2 3PC（三阶段提交）****改进点**：1. **CanCommit**（询问阶段）：检查参与者是否可执行事务。2. **PreCommit**（预提交）：锁定资源，但不提交。3. **DoCommit**（最终提交）：确认提交或回滚。**优点**：- 减少阻塞时间（相比2PC）。  **缺点**：- 仍然存在单点故障问题。- 实现复杂，实际应用较少。---### **3.3 TCC（Try-Confirm-Cancel）****原理**：- **Try**：预留资源（如冻结库存）。- **Confirm**：确认执行（如扣减库存）。- **Cancel**：失败时回滚（如解冻库存）。**优点**：- 无阻塞，适用于高并发。- 最终一致性较好。**缺点**：- 业务侵入性强（需手动实现Try/Confirm/Cancel）。- 需处理空回滚、幂等性问题。**适用场景**：- 金融支付、电商订单等高一致性要求的业务。---### **3.4 Saga模式****原理**：- 将长事务拆分为多个本地事务，每个事务提交后触发下一个事务。- 失败时执行补偿事务（反向操作）。**优点**：- 适用于长事务（如跨服务业务流程）。- 无全局锁，性能较高。**缺点**：- 不保证强一致性（可能出现脏数据）。- 补偿逻辑复杂。**适用场景**：- 订单流程、物流跟踪等最终一致性场景。---### **3.5 本地消息表（异步确保）****原理**：1. 业务数据 + 消息表（同库事务）。2. 定时任务轮询消息表，发送MQ。3. 消费者处理消息，失败重试。**优点**：- 实现简单，无额外组件依赖。- 保证最终一致性。**缺点**：- 依赖数据库（可能成为瓶颈）。- 延迟较高。**适用场景**：- 订单状态同步、日志处理等低延迟容忍场景。---### **3.6 最大努力通知****原理**：- 系统A执行本地事务后，异步通知系统B。- 系统B收到后处理，失败则重试（可设置最大重试次数）。**优点**：- 实现简单，适合跨系统调用。**缺点**：- 不保证100%一致性（最终可能人工介入）。**适用场景**：- 支付结果通知、第三方回调等。---## **4. 如何选择合适的方案？**| **方案**       | **一致性** | **性能** | **复杂度** | **适用场景**                     ||----------------|-----------|----------|------------|----------------------------------|| **2PC**        | 强一致    | 低       | 中         | 传统数据库（XA）                 || **TCC**        | 最终一致  | 高       | 高         | 金融、电商支付                   || **Saga**       | 最终一致  | 高       | 中         | 长事务（订单、物流）             || **本地消息表** | 最终一致  | 中       | 低         | 异步任务（库存扣减、日志）       || **最大努力通知**| 弱一致    | 高       | 低         | 跨系统通知（支付回调）           |--- ## **Q1：2PC和TCC的区别？**- **2PC**：数据库层实现，强一致，阻塞式，性能低。- **TCC**：业务层实现，最终一致，非阻塞，性能高。### **Q2：如何避免Saga模式的脏读？**- 采用**业务锁**或**版本号控制**，确保补偿事务正确执行。### **Q3：本地消息表如何保证消息不丢失？**- 消息表和业务数据在同一个事务中插入，确保原子性。- 定时任务 + 重试机制保证消息最终投递。---## **6. 总结**- **强一致性**：2PC（牺牲性能）。- **高并发+最终一致**：TCC、Saga、本地消息表。- **简单可靠**：最大努力通知。**实际应用**：电商系统通常组合使用：- **库存扣减**：TCC/Saga。- **订单支付**：本地消息表 + 异步通知。- **物流跟踪**：Saga模式。 理解这些方案的优缺点，能帮助你在架构设计时做出合理选择。

HC是广告投放那边的，最后的结果应该是挂了。六个问题，两道很基础和技术相关的，四道open的。很基础的问题但却精准打击到了知识盲区。一、纵向排列的两个<img/>标签，中间为什么会有1px的间隙？之前确实没注意过这个问题，下来做了验证，确实是这样，横向的时候没有，纵向的时候莫名其妙的多了缝隙，但不止1px。查了下资料，我的理解是：<img/>作为行内元素，它的真实行内对齐方式与展示出来的并不一致。不知我的理解是否正确，几个有效的解决方案都是围绕修改或重置其行内对齐行为来实现的：<img/>设置dispaly: block父容器设置font-size: 0父容...

1. 介绍一下你项目中做的最满意的部分，怎么做的？2. 数据指标有提升多少？怎么统计的？3. 用到了redis什么数据结构4. 你提到了redis实现排行榜，会有什么问题吗5. redis作为缓存，双写时会有什么问题？6. kafka了解吗7. rocketmq分布式事务，事务消息怎么做的8. mysql的隔离机制？默认是什么？9. 可重复读和读已提交的read view有什么区别10. 为什么有的大厂放弃可重复读选择读已提交11. mysql深度分页问题优化12. 有什么ai的使用经验相关吗13. ai在实际开发的时候你的感觉14. 自己设计一个rpc框架的话，你会涉及哪些核心模块15. 例如为什么需要服务注册机制16. redis分布式锁17. redis集群模式，还有哪些高可用模式18. 哨兵模式有哪些组成部分19. redis的热key问题20. spring框架涉及到的设计模式21. bean的创建过程，生命周期22. bean初始化阶段赋值会出现什么问题23. 循环依赖的三级缓存过程24. netty知道吗？还有NIO BIO25. IO多路复用机制27. 怎么保证消息不被重复消费28. Java怎么确保可见性29. synchronized和ReentrantLock区别？30. reentrantlock基于什么框架实现？解释一下31. 设计一个电商场景下的商品信息中心，类似主流的购物网站，如首页类目，以及各个类目下的商品详情，这么多数据该怎么设计这个系统？没写算法，问了一小时，盛宴

📍面试公司：京东-达达👜面试岗位：Java后端开发📖面试问题：自我介绍+项目介绍代码上线导致jvm重启，缓存中数据丢失时怎么处理数据版本号有冲突怎么解决jdk1.8对hashmap有什么优化hashmap中put的原理hashmap源码什么时候会索引失效联合索引最左匹配原则ES中分页查询，页数过多如何处理搜索优化的措施用过线程池吗🙌面试体验：面试官人很好