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。同时分片内部要分页处理避免一次查太多数据任务也要保证幂等失败数据可以记录下来后续补偿。
微服务拷打最后一讲!!!
发布时间:2026/6/2 19:07:52
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。同时分片内部要分页处理避免一次查太多数据任务也要保证幂等失败数据可以记录下来后续补偿。