消息中台异步通信重试策略规范

消息中台异步通信重试策略规范一、总则（一）目的规范。为明确消息中台异步通信重试策略，提升系统稳定性与消息传递可靠性，特制定本规范。1.适用范围本规范适用于公司所有消息中台异步通信场景，包括但不限于服务间调用、消息队列推送、事件通知等。所有涉及异步通信的业务系统、中间件及客户端均需遵循本规范执行重试策略。2.基本原则（1）最小干扰原则。重试操作不得对源系统及下游系统造成额外负载，需严格控制重试频率与并发量。（2）幂等性保障原则。所有可重试操作必须具备幂等性设计，防止因重试引发数据重复处理。（3）优先级区分原则。不同级别的业务请求需设置差异化重试策略，确保核心业务优先处理。（4）可观测性原则。重试行为需具备完整日志记录与监控指标，便于故障排查与性能分析。二、重试策略设计（一）重试触发条件1.网络异常触发（1）连接超时：客户端与消息中台建立连接超时（默认30秒）后，自动触发首次重试。（2）通信中断：消息发送过程中检测到网络中断（如TCPRST包），立即触发重试。（3）服务不可达：通过健康检查确认消息中台服务不可达时，按预设间隔重试。2.服务器响应触发（1）非200状态码：收到消息中台返回4xx/5xx状态码时，根据状态码类型决定重试策略。（2）超时响应：服务器响应时间超过阈值（默认5秒）且未返回有效结果，触发重试。（3）业务拒绝：收到业务层拒绝码（如订单重复提交码）时，需结合业务逻辑判断是否重试。3.客户端状态触发（1）资源不足：客户端内存/连接池耗尽时，暂停重试并上报告警。（2）配置变更：消息体中配置参数发生变更（如重试次数调整），需重新计算重试策略。（二）重试参数配置1.基本参数配置（1）最大重试次数：单个消息允许重试的最大次数，默认值5次，业务可按需调整。（2）重试间隔策略：采用指数退避算法，首次间隔默认1秒，后续每次间隔乘以2。（3）重试时间窗口：单个消息允许的总重试时长，超过则标记为失败并上报。2.动态调整机制（1）基于优先级：高优先级消息可设置更短的重试间隔与更多重试次数。（2）自适应调整：系统可根据历史重试成功率动态调整默认重试参数。（3）手动干预：运维可通过控制台临时调整特定业务的重试策略。三、幂等性设计要求（一）唯一标识生成1.消息ID生成规则（1）必须包含业务系统名称、请求时间戳、唯一序列号三部分。（2）格式规范：＜系统名＞-＜时间戳＞-＜序列号＞，如order-sys-2023031512-001。（2）时间戳要求：精确到毫秒，与消息中台时区同步。2.幂等键计算方法（1）请求参数哈希：将请求关键参数进行SHA256加密，取前32位作为幂等键。（2）存储方式：幂等键需缓存（有效期5分钟）并写入分布式存储，避免重复处理。（二）幂等校验实现1.消息中台校验（1）接收消息时自动比对幂等键，若存在则拒绝处理。（2）校验失败时返回特定状态码（如412PreconditionFailed），客户端需识别后重试。2.客户端主动校验（1）发送消息前先查询幂等键状态，避免网络重试导致重复提交。（2）校验逻辑需与消息中台保持一致，防止因算法差异产生漏校验。（三）异常处理机制1.幂等键过期处理（1）校验失败时需返回具体过期时间，客户端需在重试前确认键有效性。（2）系统需提供幂等键续期机制，防止因网络延迟导致键过期。2.校验接口超时处理（1）幂等键查询接口超时（默认2秒）后，客户端需执行本地幂等缓存校验。（2）校验失败时需记录详细日志，便于后续人工核查。四、重试执行流程（一）标准重试流程1.首次发送（1）客户端发送消息至消息中台，等待响应超时（默认5秒）。（2）收到响应后立即校验结果，成功则结束，失败则进入重试。2.重试执行（1）根据重试次数计算当前间隔：interval=base*2^（n-1）。（2）每次重试前检查是否超过最大重试次数与时间窗口。（3）重试失败后需记录失败原因，并触发告警机制。3.失败处理（1）连续3次重试失败后，消息转为死信队列，由专门流程处理。（2）死信消息需包含完整日志链路，便于根因分析。（二）特殊场景处理1.服务降级场景（1）检测到消息中台服务降级时，自动切换至备用通道。（2）降级期间需限制重试频率，避免压垮备用系统。2.节点故障场景（1）客户端发现目标节点不可达时，自动切换至集群其他节点。（2）切换失败后需按原策略重试，但需增加间隔。3.网络抖动场景（1）连续2次超时重试成功后，恢复正常发送策略。（2）网络抖动期间可临时降低重试频率，防止误判。五、监控与告警（一）核心监控指标1.消息发送指标（1）成功率：成功接收/发送消息量占比。（2）延迟率：消息处理时间超过阈值（默认2秒）的比例。（3）重试率：需要重试的消息占比。2.重试行为指标（1）平均重试间隔：各重试次数对应的平均间隔时长。（2）失败重试次数分布：各失败场景的重试次数统计。（3）幂等冲突率：因幂等校验拦截的比例。（二）告警规则1.告警触发条件（1）连续5分钟重试率超过阈值（如3%）。（2）单条消息重试次数超过阈值（如10次）。（3）幂等冲突数量超过阈值（如100条/小时）。（4）消息中台响应时间持续超过阈值（如10秒）。2.告警级别划分（1）一级告警：系统不可用、幂等冲突。（2）二级告警：重试率异常、响应超时。（3）三级告警：指标接近阈值。（三）监控实现要求1.指标采集（1）客户端需每秒上报重试状态，消息中台需每分钟聚合指标。（2）监控数据需接入统一监控平台，支持多维查询。2.告警配置（1）各阈值需配置在监控平台，支持动态调整。（2）告警通知需覆盖技术团队、业务方、运维方。六、测试与验证（一）单元测试要求1.重试逻辑测试（1）模拟不同状态码（200/412/500）验证重试行为。（2）测试重试间隔计算准确性，误差需控制在±50ms内。2.幂等性测试（1）连续发送相同消息验证重复处理拦截。（2）测试幂等键过期场景下的重试行为。（二）集成测试要求1.环境模拟（1）模拟网络中断、服务不可达等异常场景。（2）测试重试行为对下游系统的影响。2.性能测试（1）压力测试：验证高并发场景下的重试性能。（2）稳定性测试：连续运行24小时无内存泄漏。（三）验收标准1.功能验收（1）所有重试场景需覆盖100%测试用例。（2）幂等冲突率需低于0.01%。2.性能验收（1）重试响应时间需小于阈值（如3秒）。（2）重试资源消耗需低于系统容量的5%。七、运维管理（一）配置管理1.配置变更流程（1）重试参数变更需经过评审，并记录变更日志。（2）变更需在非业务高峰期执行，变更后需验证指标。2.配置版本控制（1）所有配置需使用配置中心管理，支持回滚。（2）变更历史需可追溯，便于问题排查。（二）故障处理1.重试风暴处理（1）检测到重试风暴时，自动触发熔断机制。（2）熔断期间需记录失败消息，恢复后重新发送。2.幂等冲突处理（1）发现幂等冲突时，需根据业务规则决定处理方式。（2）处理结果需记录在日志中，并通知相关方。（三）定期维护1.指标分析（1）每周分析重试趋势，识别潜在问题。（2）每月评估重试策略有效性，优化参数。2.系统健康检查（1）每日检查重试组件状态，确保可用性。（2）定期校验幂等键算法一致性。八、附则（一）责任划分1.技术团队责任（1）负责重试