面试题答案
一键面试1. 熔断机制优化
- 熔断阈值设定：
- 在实际电商项目中，依据商品服务过往业务高峰期每秒请求数（例如平均 1000 次/秒）、失败率（如 5%）等数据，结合不同业务时段流量特点，动态调整熔断阈值。比如业务高峰期，将失败请求率阈值适当提高到 10%，以避免因短暂流量冲击触发不必要熔断。
- 对于订单服务，考虑其对业务的关键程度，若订单创建失败影响较大，可将失败请求数阈值设为较高值（如 50 次/10 秒），防止偶尔的网络抖动引发熔断。
- 熔断恢复策略：
- 采用渐进式恢复策略，当熔断触发一段时间后（如 5 分钟），进入半熔断状态。此时允许少量请求（如正常流量的 10%）尝试通过，若一定比例（如 80%）请求成功，逐步增加通过请求量，直至完全恢复。
- 例如支付服务熔断后，先以每分钟 10 笔的速度允许支付请求尝试，若成功率达到 80%，下一分钟提高到 20 笔，依此逐步恢复。
2. 降级机制优化
- 降级策略制定：
- 商品服务：在高峰期流量过大时，对商品详情页中一些非关键信息（如商品评价的图片展示、长文本描述等）进行降级处理，只展示关键的商品名称、价格、基本属性等信息，以减少响应时间和资源消耗。
- 订单服务：若支付服务不可用，将订单状态标记为“待支付（支付服务异常）”，并提供用户后续手动重试支付入口，同时向用户推送通知告知支付异常情况，保障订单数据一致性。
- 支付服务：当自身资源紧张时，对一些复杂的支付方式（如分期付款、组合支付等）进行降级，仅支持简单的全额支付方式，优先保证核心支付功能可用。
- 数据一致性保障：
- 订单与支付：在支付服务降级时，通过消息队列（如 Kafka）记录支付请求信息，待支付服务恢复后，按照队列顺序处理支付，确保订单支付状态准确更新。
- 商品与库存：商品服务降级展示时，库存数据仍保持实时更新。通过分布式锁（如 Redis 锁）保证库存扣减的原子性，防止超卖情况，确保数据一致性。
3. 监控与预警
- 实时监控指标：
- 对各微服务设置关键监控指标，如商品服务的请求响应时间、失败率、吞吐量；订单服务的订单创建成功率、处理时长；支付服务的支付成功率、支付处理量等。
- 通过 Prometheus + Grafana 搭建监控系统，实时展示这些指标数据，以便及时发现服务异常。
- 预警机制：
- 基于监控数据设定预警规则，例如当商品服务失败率超过 8%、订单服务处理时长超过 5 秒、支付服务支付成功率低于 90% 时，通过短信、邮件或即时通讯工具（如钉钉）向运维和开发团队发送预警信息，以便快速响应处理。