7. 什么是服务雪崩，怎么解决这个问题？
服务雪崩就是下游服务异常后，上游请求一直等待，导致线程池、连接池资源被占满，最终故障在调用链中扩散。
解决上一般会做超时控制、熔断、降级、限流和资源隔离。比如依赖服务失败率过高时熔断，直接走兜底逻辑，避免继续拖垮系统。
8. 你们的微服务是怎么监控的？
我们项目用 SkyWalking 做微服务监控，主要看服务拓扑、接口耗时、QPS、错误率、实例状态和 Trace 调用链。它一般通过 Java Agent 接入，对业务代码侵入比较小。
如果接口变慢，可以通过调用链看到请求经过哪些服务、每一段耗时多少，再定位是数据库、远程调用还是本服务逻辑的问题。
同时也会配置错误率、响应时间、服务异常等告警。
9. 你们项目中有没有做过限流？怎么做的？
我们项目做过限流，主要放在入口层。
简单场景用 Nginx 按 IP 限制访问频率，微服务场景下用 Spring Cloud Gateway 的RequestRateLimiter做网关限流。
Gateway 里一般通过KeyResolver决定按 IP、用户 ID 还是路径限流，底层常用 Redis 令牌桶。超过阈值的请求直接快速失败，返回系统繁忙，避免流量继续打到后端服务。
10. 限流常见的算法有哪些？
限流常见算法主要有四类。
比较简单的是固定窗口计数器，比如一分钟最多允许 1000 次请求，但它的问题是窗口边界可能出现流量突刺。
滑动窗口是在固定窗口基础上做优化，把时间窗口切得更细，统计最近一段时间内的请求数，限流会更平滑。
另外两个比较常见的是漏桶和令牌桶。漏桶可以理解成请求先进桶里，再按固定速率处理，多出来的请求排队或者被拒绝，所以它更强调平滑流量。令牌桶是系统按固定速率生成令牌，请求拿到令牌才能通过，因为令牌可以积累一部分，所以它能允许一定的突发流量。实际项目里 Gateway 的限流一般就是令牌桶思想。
11. 什么是CAP理论？
CAP理论是分布式系统设计的基础理论，包含一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)。
12. 为什么分布式系统中无法同时保证一致性和可用性?
因为发生网络分区时，节点之间无法通信，也就无法确认彼此的数据是否最新。比如 A 节点已经更新了数据，但 B 节点因为网络断开不知道这个更新。
如果 B 继续响应请求，就可能返回旧数据，牺牲一致性；如果 B 为了保证数据一定最新而拒绝请求或等待同步，就牺牲可用性。所以 CAP 在网络分区发生时，C 和 A 不能同时完全保证。
13. 什么是BASE理论?
BASE 是 CAP 中 AP 思路的延伸，核心是牺牲强一致性，换取系统可用性和扩展性。
它包括基本可用、软状态和最终一致性。简单说，就是系统在高压或故障时可以降级、限流，数据允许短时间不一致，但最终要通过 MQ、重试、补偿等机制达到一致。
14. 你们采用哪种分布式事务解决方案？
我们项目用 Seata 的 AT 模式来做分布式事务，主要用于订单、库存、账户这类跨服务、跨数据库的一致性场景。
AT 模式业务侵入比较低，一阶段会执行本地事务并写undo_log，记录修改前后的数据镜像；二阶段如果全局事务成功就删除日志，失败就根据undo_log自动回滚。
15. 分布式服务的接口幂等性如何设计？
幂等就是同一个请求执行多次，最终结果和执行一次一样。
我们项目里常用 Token + Redis 防重复提交，比如提交前生成 Token 存 Redis，提交时校验 Token，校验通过后删除，保证一个 Token 只能用一次。这里校验和删除要用 Lua 或GETDEL保证原子性。
除了 Token，还会用业务唯一号和数据库唯一索引兜底，比如订单号、支付流水号唯一；更新类接口可以用乐观锁或状态机，MQ 消费可以用消息 ID 做去重。
16. xxl-job路由策略有哪些？
XXL-JOB （XXL-JOB 是一个分布式任务调度平台，就是用来管理和执行定时任务的）的路由策略就是多个执行器在线时，调度中心选择哪台执行器来跑任务。
常见策略有轮询、随机、第一个、最后一个、一致性 Hash、故障转移、忙碌转移、最不经常使用、最近最久未使用和分片广播。普通任务可以用轮询，执行器异常时可以用故障转移；如果是大批量数据处理，可以用分片广播，让所有执行器都执行，各自处理一部分数据。
17. xxl-job任务执行失败怎么解决？
原因->排查XXL-JOB 任务失败后，首先要看失败原因。
如果是执行器不可用，可以用故障转移，让任务切到其他健康实例执行；
如果是临时异常，可以配置失败重试次数，但重试前要保证任务幂等，避免重复执行造成重复发券、重复扣库存。
排查时主要看 XXL-JOB 调度日志和执行器业务日志，同时配置告警。如果多次重试还失败，可以记录失败数据，通过补偿任务或人工触发重跑。
18. 如果有大数据量的任务同时都需要执行，怎么解决?
大数据量任务一般不会让单台机器一次性处理。我们可以部署多个执行器实例，用 XXL-JOB 的分片广播，让所有实例都执行任务，但每台只处理自己的分片。
代码里通过shardIndex和shardTotal分数据，比如按业务 ID 取模：id % shardTotal == shardIndex。同时分片内部要分页处理，避免一次查太多数据；任务也要保证幂等，失败数据可以记录下来后续补偿。
