分布式高频面试题

一、基础理论CAP 定理是什么分别解释一致性、可用性、分区容错性。CAP 定理是分布式系统的核心理论它指出一个分布式系统无法同时满足一致性、可用性和分区容错性由于网络分区无法完全避免P 是客观存在的系统必须在CP牺牲可用性和AP牺牲一致性之间做出选择。C - 一致性Consistency所有节点在同一时间看到的数据是相同的。即一个客户端写入数据后后续的读操作必须能读到这个最新值强一致性。对应到分布式系统要求数据副本保持同步。A - 可用性Availability每个请求都能在有限时间内收到非错误的响应但不保证返回的是最新数据。即系统一直可用不会超时或拒绝服务。P - 分区容错性Partition Tolerance当集群中部分节点之间网络通信中断出现网络分区时系统仍能继续对外提供服务。由于网络不可靠分布式系统必须考虑分区容错因此实际中往往在 CP 和 AP 之间做权衡。对资金、库存等核心数据优先保证一致性CP在分区时宁可返回错误也不允许脏数据对于商品浏览、点赞计数等非核心场景优先保证可用性AP为什么分布式系统中无法同时满足 CAP举例说明。分布式系统无法同时满足 CAP是因为网络分区P是客观存在的当分区发生时必须在**一致性C和可用性A**之间二选一。核心原因假设一个系统有两个节点 A 和 B中间网络断开发生分区。此时客户端向 A 写入一个新值x1。由于网络不通A 无法将更新同步给 BB 上的x仍然是旧值比如x0。为了保证一致性C系统必须拒绝 B 节点的读请求因为 B 的数据不是最新的或者直接报错这就牺牲了可用性A。为了保证可用性A系统必须让 B 节点继续返回数据哪怕数据是旧的这就牺牲了一致性C。所以只要分区存在CA 两者就无法兼得。举例说明CP 系统放弃 AZooKeeper。当发生网络分区时ZooKeeper 会暂停服务不可用直到分区恢复、数据达成一致。保证数据一致但牺牲了部分可用性。AP 系统放弃 CEureka。当分区发生时Eureka 优先保证服务注册和发现功能可用即使各节点数据不一致比如有的节点还保留已下线的服务也继续对外服务牺牲强一致性保证最终一致即可。BASE 理论是什么与 ACID 的区别BABasically Available基本可用系统出现故障时允许损失部分功能如响应变慢、部分服务降级但整体仍可用。SSoft State软状态允许系统中存在中间状态如数据同步延迟不要求实时强一致。EEventually Consistent最终一致性经过一段时间后所有数据最终会达到一致状态。在分布式系统设计中ACID 追求强一致性而 BASE 则是通过牺牲短期的强一致性来换取系统的高可用性和最终一致性什么是最终一致性常见实现方案有哪些最终一致性是指在分布式系统中数据更新后不要求立即在所有节点上保持一致而是允许一段时间的“不一致窗口”但保证经过一段时间后所有副本最终会达到一致状态。它是 BASE 理论中 EEventually Consistent的核心。1. 旁路缓存Cache-Aside模式先更新数据库再删除缓存”策略保证最终一致性。2. 异步复制机制在 Redis 主从架构中主节点处理完写请求后会立即响应客户端并异步转发命令给从节点。但在主从同步完成前数据存在短暂的不一致窗口。**2.本地消息表 **业务系统在同一个本地事务中同时写入业务数据和消息记录再由独立的服务轮询消息表并将消息投递到 MQ如 Kafka、RocketMQ。下游服务消费消息并执行对应逻辑从而保证跨服务数据的最终一致。4. Saga 模式补偿事务针对长流程的分布式事务Saga 模式将其拆分为多个独立的本地事务。每个正向操作都有对应的反向补偿操作。如果某一环节失败系统会按反向顺序调用补偿事务来回滚已提交的动作确保整体业务流程的最终正确性。二、分布式事务什么是 2PC两阶段提交有什么优缺点原理引入一个协调者Coordinator将事务分为“准备阶段”和“提交阶段”。所有参与者先锁定资源并执行操作但不提交等协调者确认所有参与者都准备就绪后再统一发起提交。优点实现了强一致性逻辑相对简单对业务代码侵入性较低数据库层面支持。缺点性能极差准备阶段会长时间锁定数据库资源导致高并发下系统吞吐量骤降且协调者存在单点故障风险。什么是 3PC与 2PC 的区别是什么3PC三阶段提交是为了解决 2PC 的阻塞和单点故障问题而提出的改进协议。它将流程拆分为三个阶段CanCommit询问仅检查节点状态不锁定资源。PreCommit预提交执行事务并锁定资源但不真正提交。DoCommit正式提交完成最终提交或回滚。与 2PC 的核心区别拆分阶段比 2PC 多了一个CanCommit纯询问阶段提前过滤异常减少了不必要的资源锁定浪费。引入超时机制核心2PC 只有协调者有超时机制而 3PC 在协调者和参与者中双向引入了超时机制。若长时间未收到指令参与者可自动决策中断或提交有效缓解了单点故障导致的死锁问题。TCCTry-Confirm-Cancel是什么适用于什么场景TCC是一种柔性分布式事务解决方案。将一个事务拆分为三个阶段Try预留资源如冻结库存、Confirm确认执行真正扣减、Cancel取消执行释放预留资源适用于对一致性要求较高、且核心链路较短的场景比如金融支付、核心交易系统等。什么是本地消息表如何保证最终一致性本地消息表是一种基于数据库本地事务的最终一致性方案。核心思想是业务系统在同一个本地事务中同时写入业务数据和消息记录再由独立的服务轮询消息表并将消息投递到 MQ如 Kafka、RocketMQ。下游服务消费消息并执行对应逻辑再配合异步轮询重试 幂等消费从而保证跨服务数据的最终一致。分布式场景下如何保证跨服务的事务一致性有哪些常见方案“目前业界主流的分布式事务解决方案主要有以下四种它们分别适用于不同的业务场景”1. 两阶段提交2PC / XA原理引入一个协调者Coordinator将事务分为“准备阶段”和“提交阶段”。所有参与者先锁定资源并执行操作但不提交等协调者确认所有参与者都准备就绪后再统一发起提交。优点实现了强一致性逻辑相对简单对业务代码侵入性较低数据库层面支持。缺点性能极差准备阶段会长时间锁定数据库资源导致高并发下系统吞吐量骤降且协调者存在单点故障风险。结论由于严重的性能问题在互联网高并发业务中极少使用通常只出现在对一致性要求极高、并发量不大的传统金融或银行核心系统中。2. TCCTry-Confirm-Cancel原理TCC是一种柔性分布式事务解决方案。将一个事务拆分为三个阶段Try预留资源如冻结库存、Confirm确认执行真正扣减、Cancel取消执行释放预留资源。优点性能较好资源锁定粒度细只在 Try 阶段锁定能够实现准实时的一致性。缺点业务侵入性极强每个服务都需要开发 Try、Confirm、Cancel 三个接口且需要手动处理幂等性、空回滚、资源悬挂等复杂的边界问题。结论适用于对一致性要求较高、且核心链路较短的场景比如金融支付、核心交易系统等。3. 异步消息机制原理业务系统在同一个本地事务中同时写入业务数据和消息记录再由独立的服务轮询消息表并将消息投递到 MQ如 Kafka、RocketMQ。下游服务消费消息并执行对应逻辑再配合异步轮询重试 幂等消费从而保证事务的最终一致。通过本地事务表或 MQ 的半消息机制保证“本地操作”与“消息发送”的原子性优点彻底解耦系统吞吐量极高不阻塞主流程业务侵入性相对较低。缺点只能保证最终一致性存在秒级甚至分钟级的数据延迟且消费端必须做好幂等处理。结论这是互联网高并发场景下最常用的方案非常适合非核心链路或允许短暂延迟的业务比如下单成功后异步扣减积分、异步发送通知等。4. Saga/ˈsɑːɡə/ 模式原理适用于长事务。将一个长事务拆分为多个本地短事务每个短事务都有一个对应的补偿操作。如果某一步失败则依次反向调用前面所有步骤的补偿操作把数据“补”回去。优点适合流程极长、跨服务极多的业务并发性能好。缺点补偿逻辑编写复杂且缺乏隔离性其他事务可能会看到中间状态的数据。结论适用于业务流程极长的场景比如复杂的物流履约流程、跨多个部门的审批流程等。压轴环节生产环境如何选择“在实际的生产环境选型中我不会盲目追求强一致性而是会根据业务容忍度来做决策如果是高并发的核心交易链路如电商下单扣库存、支付为了保证性能和用户体验我会优先选择TCC 模式通常会借助 Seata 等成熟框架来降低开发复杂度或者结合可靠消息队列来异步处理非核心步骤。如果是对实时性要求不高、追求极致解耦的场景如订单完成后发优惠券、发短信我会毫不犹豫地选择基于 MQ 的可靠消息最终一致性方案。至于2PC由于其严重的性能瓶颈我通常不会在分布式微服务架构中推荐使用。什么是事务消息如 RocketMQ 的事务消息事务消息如 RocketMQ 的事务消息是一种通过“半消息Half Message 二阶段提交 事务状态回查”机制将本地数据库操作与 MQ 消息发送绑定从而保障分布式场景下数据最终一致性的方案 阶段一发送半消息 (Prepare/Half Phase)生产者向 Broker即RocketMQ服务端发送一条对消费者暂不可见的消息即“半消息”Half Message。并持久化到RMQ_SYS_TRANS_HALF_TOPIC主题中。️ 阶段二执行本地事务二次确认生产者接收到半消息的成功确认后立即开始执行本地业务逻辑如扣减库存、更新订单状态。本地事务成功生产者通知Broker提交半消息消费者最终能消费到该消息。本地事务失败生产者通知Broker回滚半消息消息被删除消费者不会收到。事务回查(Check Mechanism) —— 可靠性保障如果生产者因故障、网络等原因未及时发送二次确认或因Unknow状态而等待超时Broker会在一定时间后如默认1分钟主动向生产者发起回查请求询问该消息对应的本地事务状态。生产者实现TransactionListener接口由checkLocalTransaction方法负责回复当前本地事务的最终状态。Seata 支持哪些分布式事务模式AT 模式的原理是什么Seata 支持 AT、TCC、SAGA、XA 四种模式AT 模式通过本地事务和undo_log快照实现自动补偿一阶段提交业务数据和回滚日志二阶段全局回滚时利用快照反向生成 SQL 恢复数据。三、分布式锁分布式锁需要满足哪些条件互斥性任意时刻只有一个客户端能持有锁。防死锁自动释放锁需设置过期时间TTL防止客户端崩溃导致锁永不释放。原子性与安全性防误删加解锁操作须原子化且严格校验身份确保“谁加的锁谁来解”。高可用与容错性锁服务自身需高可用即使部分节点故障不影响加锁和解锁。可重入性同一客户端可重复获取已持有的锁。自动续期能力看门狗机制在业务未完成时后台定时延长锁的有效期防止因执行超时导致锁提前释放。Redis 实现分布式锁如何保证原子性SET NX EX 是否足够Redlock 算法的原理是什么它有什么问题ZooKeeper 如何实现分布式锁与 Redis 锁的优缺点对比客户端在锁路径下创建临时顺序节点序号最小的节点获得锁其他客户端监听前一个节点释放锁时删除自己的临时节点触发下一个节点获取锁。ZooKeeper 锁强一致、防死锁、公平但性能较低适合金融级强一致性场景Redis 锁高性能、低延迟但极端场景可能失效如主从切换瞬间适合高并发且能容忍小概率异常的业务。分布式锁中如何防止锁超时导致业务未完成而释放实现自动续期当我们成功拿到Redis分布式锁后同时也异步启动一个线程这个就是看门狗线程它会判断对应key是否到过期时间的1/3如果到了则对key进行续期直到任务完成。当然实现看门狗的任务通过lua脚本来完成。看门狗主要解决自动续期问题确保锁过期时间大于业务执行时间的问题。四、分布式 ID 生成分布式ID有哪些优点和缺点有哪些如何选择常见方案及优缺点UUID / GUID优点本地生成全球唯一。缺点无序且过长结论不适合作为数据库主键仅适用于非核心链路如请求追踪ID。数据库自增ID优点实现简单严格递增对索引友好。缺点单库性能受限分库分表则扩展性差结论适用于单机或小规模系统大型分布式系统不建议直接使用。Redis 自增INCR优点严格递增性能较高。缺点持久化可能导致数据丢失导致ID重复。结论可接受一定丢失风险的场景可以使用。雪花算法Snowflake优点性能极强本地生成单机可达几十万甚至百万QPS。趋势递增64位整数紧凑且对索引友好。缺点时钟回拨若机器时钟被回调可能产生重复ID。机器ID分配需要在分布式环境中为每个节点分配唯一的WorkerID。解决方案通过ZooKeeper自动分配WorkerID并实现时钟回拨容错如等待或告警降级。结论适合超高并发、对性能极致要求的场景但需要解决时钟问题。号段模式Segment Mode代表实现美团Leaf、滴滴Tinyid。原理从数据库批量获取ID号段例如一次获取1000个在本地内存中递增用完后重新获取。优点性能高且稳定减少数据库访问压力QPS可达数万。严格递增ID对数据库友好。缺点依赖数据库如果数据库宕机且本地号段耗尽则无法生成ID。结论适合中小型分布式系统。选择策略绝对避免直接使用UUID作为数据库主键它的无序性和长度会严重拖垮数据库性能。个人项目 / 初期单体应用直接用数据库自增ID简单够用。中小型分布式系统优先选用号段模式的开源实现比如美团Leaf-segment或滴滴Tinyid。它们稳定可靠运维成本低能覆盖绝大多数业务。超高并发如秒杀、订单ID生成采用雪花算法并配套ZooKeeper管理机器ID实现时钟回拨容错机制。例如美团的Leaf-snowflake/ˈsnəʊfleɪk/。分布式 ID 需要满足哪些特性分布式 ID 必须满足全局唯一性、趋势递增性、高性能、高可用性、安全性五大核心特性雪花算法Snowflake的原理是什么如何解决时钟回拨问题雪花算法通过将64位ID划分为时间戳41位、机器ID10位和序列号12位利用位移运算生成全局唯一且趋势递增的ID雪花算法解决时钟回拨的核心方法是对轻微回拨通常≤5ms采用等待策略使时钟自然追平对严重回拨则通过切换机器ID、启用逻辑时钟或直接拒绝服务来保障ID唯一性避免因时间倒退导致ID重复。数据库自增 ID 在分布式下有什么缺陷单库性能受限所有ID请求都落到同一台数据库成为写入瓶颈无法支撑高并发。分库分表则扩展性差虽然通过设置不同步长和偏移量可以保证全局唯一但扩缩容时需要重新计算所有实例的步长、迁移数据、调整配置过程复杂且易出错缺乏弹性。美团 Leaf 和百度 UidGenerator 的核心思想是什么五、服务治理与 RPC服务注册与发现的核心组件有哪些工作原理是什么服务注册与发现的核心组件包括服务提供者、服务消费者和注册中心。工作原理服务注册服务提供者启动时将自己的网络地址IP端口及元数据注册到注册中心。服务发现服务消费者从注册中心获取所需服务的提供者地址列表并缓存到本地。健康检查注册中心通过心跳机制定期检测服务提供者的健康状态若检测失败则将其从列表中移除。变更通知当服务提供者列表发生变化新增、删除或故障注册中心会通知服务消费者更新本地缓存。典型实现ZooKeeper、Eureka、Nacos、Consul 等。ZooKeeper、Eureka、Nacos、Consul 作为注册中心的区别特性ZooKeeperEurekaConsulNacosCAP 模型CP(一致性优先)AP(可用性优先)CP(一致性优先)CP/AP 可切换数据一致性强一致性(ZAB 协议)最终一致性强一致性(Raft 协议)CP 模式强一致AP 模式最终一致高可用特性Leader 选举期间短暂不可用高可用任意节点故障不影响服务有自我保护机制Leader 选举期间短暂不可用CP 模式 Leader 选举期间不可用AP 模式高可用健康检查基于 Session 心跳基于 Client 心跳续约丰富的检查(TCP/HTTP/Script)支持多种检查方式TCP/HTTP/MySQL功能范围分布式协调服务服务注册发现服务发现 KV 健康检查 多数据中心服务发现 配置管理主流版本状态活跃2.0 版本已停止维护活跃活跃生态与趋势老牌方案生态成熟多用于 Hadoop/Spark 等大数据组件Spring Cloud Netflix 早期标配已被替代HashiCorp 出品云原生友好多用于 K8s 或非 Java 生态阿里开源云原生主力Spring Cloud Alibaba 核心组件CAP 视角下ZooKeeper 和 Eureka 分别偏向哪个ZooKeeper 偏向CP一致性 分区容错性Eureka 偏向AP可用性 分区容错性。RPC 和 HTTP 调用的区别为什么 RPC 更高效Dubbo 的核心架构包含哪些角色Provider、Consumer、Registry、MonitorDubbo 支持哪些负载均衡策略默认是哪种什么是服务熔断、降级、限流分别如何实现服务熔断、降级、限流是分布式系统保障稳定性的三大手段。1、服务熔断Circuit Breaker定义当某个下游服务持续超时或失败调用方主动切断对其的调用快速失败。实现熔断器通过“关闭→开启→半开”状态机实现关闭时统计失败率达阈值则开启熔断直接失败窗口期后进入半开放行试探请求成功则恢复关闭失败则继续熔断。主流实现用滑动窗口计数框架有 Hystrix、Resilience4j、Sentinel。服务降级Fallback / Degradation定义当系统压力过大或依赖服务不可用时自动关闭非核心功能或返回兜底数据保证核心功能可用。实现触发条件熔断、超时、资源不足线程池/连接池满时触发。降级逻辑返回缓存数据、静态默认值、错误提示或调用备用逻辑。代码示例SentinelSentinelResource(valuegetOrder,fallbackorderFallback)publicOrdergetOrder(Longid){...}publicOrderorderFallback(Longid,Throwableex){returnnewOrder(-1L,降级订单);}服务限流Rate Limiting定义控制访问 QPS 或并发数超过阈值的请求直接拒绝或排队防止系统过载。实现算法令牌桶允许突发、漏桶平滑、计数器简单滑动窗口。维度接口级、IP级、用户级、集群级。主流实现Guava RateLimiter单机、Sentinel分布式限流、Nginx网关限流、Redis Lua分布式计数器。一句话总结限流是“挡住多余请求”熔断是“关掉故障通道”降级是“简化服务内容”。三者常配合使用如 Sentinel 或 Hystrix 可同时支持熔断与降级。Sentinel 和 Hystrix 的区别是什么Sentinel 比 Hystrix 功能更全面支持流量控制、性能更好、支持动态规则热更新且项目处于活跃维护状态而 Hystrix 已停止开发六、负载均衡常见负载均衡算法有哪些轮询、加权轮询、最少连接、一致性哈希等轮询Round Robin按顺序将请求依次分配给后端服务器循环往复。简单公平适合服务器性能相近的场景。加权轮询Weighted Round Robin为每台服务器设置权重权重高的服务器被分配更多请求。适用于服务器性能不均的情况。最少连接Least Connections将请求分配给当前活动连接数最少的服务器。适用于长连接或请求处理时间差异大的场景能动态避免负载倾斜。随机Random随机选择一台服务器。实现简单在大流量下近似均匀但可能存在不均匀分布。源地址哈希IP Hash根据客户端 IP 的哈希值分配固定服务器保证同一客户端始终访问同一台后端常用于会话保持。服务器编号 hash(客户端IP) mod 服务器总数缺点源地址哈希在节点增减时会导致绝大部分请求的映射关系发生改变导致请求重新分配缓存命中率骤降。一致性哈希Consistent Hashing一致性哈希是一种分布式哈希算法将服务器和客户端IP映射到一个哈希环上按顺时针找最近的服务器。在增减服务器时只影响环上小部分请求从而最小化数据迁移量。非常适合分布式缓存等需要高扩展性的场景。什么是一致性哈希解决了什么问题虚拟节点的作用是什么一致性哈希是一种分布式哈希算法将服务器和客户端IP映射到一个哈希环上按顺时针找最近的服务器。在增减服务器时只影响环上小部分请求从而最小化数据迁移量。非常适合分布式缓存等需要高扩展性的场景。虚拟节点通过让每个物理节点在环上“出现多次”使数据分布更均匀、节点增减影响更平滑。七、消息队列为什么使用消息队列有哪些优缺点解耦、削峰、异步如何保证消息不丢失生产端、Broker、消费端分别考虑如何保证消息不被重复消费幂等性如何设计如何保证消息的顺序性Kafka、RocketMQ、RabbitMQ 的适用场景有什么区别八、分布式会话与缓存分布式会话如何管理Session 共享方案集中式存储最常用、推荐原理将用户的 Session 数据从各服务实例中抽离统一存放在一个外部的高性能缓存中间件中通常是Redis集群。所有服务实例在需要 Session 时都去这个共享缓存中读取。优点支持水平扩展节点增减无感知性能高Redis 内存操作服务无状态便于容器化部署如 Docker、K8s缺点引入额外组件Redis 集群需保证其高可用一次网络开销但通常可接受实现方式Spring Boot Redis Session// 引入依赖 spring-session-data-redisEnableRedisHttpSession// 启用 Redis 托管 SessionpublicclassConfig{...}用户请求的JSESSIONID不变但 Session 数据实际存储在 Redis 中。客户端存储如 JWT原理服务器不存储 Session而是将用户状态信息如用户 ID、权限加密后写入一个令牌如 JWT直接返回给客户端。客户端在后续请求中携带该令牌服务器解密验证后直接使用。优点完全无状态无需共享存储适合移动端、跨域场景避免 Session 同步问题缺点令牌体积较大每次请求都携带无法主动失效除非配合黑名单敏感信息不应存入 JWT适用RESTful API、前后端分离、对实时注销要求不高的场景。方案是否无状态扩展性性能实现复杂度适用场景Redis 集中存储✅ 是高高中等主流推荐绝大多数分布式 Web 应用JWT 客户端存储✅ 是高高但令牌体积大低前后端分离、移动端 APISession 粘滞❌ 否低高低小规模、非关键、可容忍宕机丢失Session 复制❌ 否极低低低已弃用不推荐缓存穿透、缓存击穿、缓存雪崩分别是什么如何解决如何保证缓存与数据库的双写一致性九、分布式幂等性什么是幂等性如何设计幂等接口接口幂等性是指同一个请求执行 1 次和执行 N 次对业务产生的副作用和结果完全一样。在分布式系统中由于网络波动重试、用户重复点击、消息队列重复消费等原因重复请求非常常见。常见的幂等实现方案有哪些Token、去重表、乐观锁等Token 令牌机制最常用这是目前分布式系统中最通用的方案适用于表单提交、下单、支付等场景。实现原理前端在进入页面或点击提交前先调用后端接口获取一个全局唯一的 Token如 UUID。后端将 Token 存入 Redis 并设置过期时间。前端提交业务请求时在请求头或参数中携带该 Token。后端接口通过拦截器或 AOP 拦截请求利用 Redis 的原子操作如del或 Lua 脚本校验并删除 Token。如果删除成功说明是第一次请求放行执行业务如果删除失败Token 不存在则判定为重复请求并直接拒绝。优缺点能完全防住重放请求适合分布式环境但需要额外增加一次获取 Token 的网络请求。数据库唯一索引兜底方案利用数据库的唯一约束来防止重复插入是最简单可靠的兜底方案。实现原理在业务表的特定字段如订单号order_no、支付流水号上建立唯一索引Unique Index。当重复请求尝试插入相同数据时数据库会抛出唯一键冲突异常业务层捕获该异常后返回“请勿重复操作”。优缺点实现简单强一致性但仅适用于插入场景且高并发下频繁触发异常会对数据库性能造成一定影响。状态机控制适合有状态流转的业务适用于订单状态流转、审批流程等具有明确状态变更的业务。实现原理在更新数据时将旧状态作为更新条件。例如支付接口SQL 语句写为UPDATE order SET status PAID WHERE order_id 1001 AND status UNPAID。优缺点天然幂等无需额外存储但如果重复请求到达时状态已变更后续请求会因影响行数为 0 而失败。Redis 分布式锁适用于高并发下的更新操作或防重复执行。实现原理在执行业务逻辑前先尝试获取一个以业务唯一标识如订单ID为 Key 的分布式锁。获取锁成功则执行业务执行完毕后释放锁获取失败则直接返回“重复请求”。优缺点性能高适合分布式但需要合理设置锁的过期时间以防死锁且锁的粒度要控制精细。防重表独立去重记录实现原理建立一张独立的去重表表中包含请求的唯一标识幂等键并设置唯一索引。业务执行前先向防重表插入一条记录插入成功则继续执行业务失败则说明是重复请求。优缺点对业务表无侵入灵活可控但增加了一次数据库写操作。前端防重辅助手段实现原理用户点击提交按钮后立即将按钮置灰或禁用并显示“提交中”防止用户短时间内多次点击。优缺点实现简单提升用户体验但只能防住前端的误操作无法防御恶意攻击、网络重放或后端重试必须配合后端方案使用。方案对比与选型建议方案核心原理适用场景优缺点Token 令牌请求前获取令牌执行时原子删除表单提交、下单、支付适合分布式防重效果好需额外网络开销唯一索引数据库唯一约束阻止重复插入插入操作创建订单、流水简单可靠强一致仅限插入性能受限状态机控制更新时带上前置状态条件订单状态流转、审批天然幂等仅限有状态流转的业务分布式锁业务唯一键加锁防并发执行更新操作、防重复执行性能高需处理锁超时与释放问题前端防重按钮置灰、防抖所有提交场景体验好治标不治本仅作辅助在生产环境中通常不会单一依赖某一种方案而是采用组合拳前端通过按钮置灰/防抖拦截大部分用户误操作。高并发层使用 Redis Token 或分布式锁作为第一道防线拦截绝大部分重复请求。数据层通过数据库唯一索引或状态机作为最终的兜底保障确保数据的绝对安全。十、分布式链路追踪什么是分布式链路追踪Trace、Span 的含义OpenTracing 规范是什么SkyWalking、Zipkin 等如何工作