SOA客户端发送数据受限场景下保障全量记录提交的方案咨询

1. 流量削峰与速率控制 #

• 全局滑动窗口限流器：单机部署可以用JUC的AtomicLong结合定时任务重置计数器，分布式部署用Redis的INCR指令加过期时间实现跨线程/跨实例的全局速率统计，精确控制每小时总提交量不超过100万阈值，避免超量请求被接口拒绝。
• 令牌桶算法限流：按每小时100万的速率匀速生成令牌，每次发送前需要先获取令牌，拿不到令牌的请求直接进入待处理队列，不会触发接口限流报错，相比固定窗口计数器的方案流量更平滑，避免整点集中提交的流量尖峰。

2. 待处理任务持久化与顺延机制 #

• 数据库状态标记：给每条待发送记录新增发送状态字段（0=待发送、1=发送中、2=发送成功、3=发送失败）、下次重试时间字段。触发限流或发送失败时，将记录状态回改为待发送，设置下次重试时间为下一个提交周期的起始时间，后台调度任务自动扫描符合条件的待发送记录。
• 持久化消息队列兜底：所有待发送数据先写入RabbitMQ、RocketMQ等支持持久化的消息队列，消费者进程按限流速率拉取消息发送。达到限流阈值时消费者暂停拉取，消息持久化存储在队列中不会丢失，下一个周期自动恢复消费，同时配置死信队列承接多次发送失败的记录，避免阻塞正常任务。

3. 异常兜底与一致性校验 #

• 分级重试机制：区分异常类型，限流触发的异常直接顺延到下一个周期重试；网络波动、接口超时等非业务异常配置指数退避重试，最多重试3次仍失败的转入人工处理队列，避免无效重试占用配额。
• 周期对账校验：每个提交周期结束后，统计本周期实际成功提交条数、数据库待发送条数、SOA接口返回的接收量三方数据做对账，出现数据不一致时自动触发补推任务，避免漏发、错发。

4. 并行任务优化 #

• 动态线程池调整：根据当前周期剩余可用配额动态调整发送线程数，配额充足时开启全量线程发送，配额不足时缩小线程数甚至暂停发送，避免大量线程空转浪费系统资源。
• 批量提交优化：如果SOA接口支持批量提交，将多条记录合并为一次请求发送，既降低接口调用频次，也更容易精准控制总提交条数，减少限流触发概率。

内容的提问来源于stack exchange，提问作者Renan