Skip to content

Add bounded backpressure across ingress, MQ, and Push #75

Description

@ULookup

Target Version

3.0-dev。复核基于 origin/3.0-dev 提交 a75fc8721b99e5c0b4421d0c58b5618bbe71ff31(PR #57)。Redis 限流故障已有本地有界兜底,但 MQ、入口与慢 WebSocket 的全链路容量边界仍缺失。

Evidence

  • common/utils/local_rate_limiter.hpp 已实现有容量上限的本地 token bucket;common/dao/data_redis.hpp:1594-1665 在 Redis breaker/异常时使用本地 fallback,并记录 fallback/rejected 指标。
  • tests/reliability/redis_failover_test.go 已验证 Redis 停止期间仍出现受控 rate limited 响应。
  • common/mq/rabbitmq.hpp:303-320,378 仍使用无界 std::queue<std::function<void()>>post_task 始终入队。
  • Reliable publisher 仍无明确 in-flight confirm 上限;consumer 固定 prefetch=64,未与 DB pool、处理延迟或积压联动。
  • transmite/source/transmite_server.h 只有用户/会话限流,没有基于 MQ/DB/Push 饱和度的 admission control。
  • push/source/push_server.h:721 后的 _local_send 没有每连接待发送消息/字节预算和慢客户端隔离契约。

Problem or Goal

让过载以有界队列、明确拒绝和可恢复退避表现,保护已承诺工作,避免内存增长、尾延迟雪崩、连接池耗尽和级联故障。PR #57 已完成 Redis 限流故障兜底,本 Issue 聚焦跨阶段容量边界。

Scope

  • 为 Gateway/Transmite admission、MQ task/in-flight、consumer work、Outbox dispatch 和 Push per-connection 队列设置硬上限与高低水位。
  • 定义 overload 信号传播、稳定错误码、Retry-After/jitter 与恢复 hysteresis。
  • 隔离慢 WebSocket 与热点 conversation。
  • 将 prefetch、DB/Redis pool、batch 与实例容量建立可校验预算。
  • 暴露 depth、in-flight、shed、timeout、slow consumer 与恢复指标。
  • 保留并回归 PR feat(cache): harden Redis resilience and multilevel caching #57 的本地限流 fallback,不重复实现 Redis breaker。

Non-goals

  • 不修改消息持久化、DLX 或 Outbox 可靠性语义。
  • 不依赖无限扩容代替容量边界。
  • 不把所有通知提升为相同优先级。
  • 不重做 Redis 熔断和本地 token bucket。

Acceptance Criteria

  • Redis 限流不可用时存在本地有界 token bucket,并有 fallback/rejected 指标与故障测试。
  • 每个内存队列与 publisher confirm 集合有显式硬上限,超过后不继续无界分配。
  • 新请求在可靠接收前快速拒绝并返回稳定错误/退避;已 confirmed/committed 工作不静默丢弃。
  • 慢 WebSocket 达到每连接消息/字节预算后被隔离,不阻塞其他用户。
  • consumer/dispatcher 并发与 DB/Redis pool 有可解释预算,非法配置启动失败。
  • overload 进入/退出有 hysteresis,指标区分入口、MQ、DB 与 Push 饱和。
  • 压测中内存保持在预算内,成功请求延迟有界,恢复后自动接流。

Test-first Plan

先增加 BenchmarkMessagePipelineOverload 和慢连接 Scenario,运行:

cd tests && go test -tags=perf ./perf/... -run '^$' -bench BenchmarkMessagePipelineOverload -benchmem -count=1 -benchtime=30s

预期 RED 是 MQ task/in-flight 或 Push 慢连接状态无上限,内存/延迟持续增长且无受控拒绝。最小 GREEN 先覆盖入口、publisher 与 per-connection 三个关键边界;随后运行 RL-Redis fallback、正确性 Scenario、完整 Performance 与 BVT。

Risk and Security

上限过紧降低可用吞吐,过松无法保护资源,必须用 #76 容量基线校准。热点会话和慢连接可被用于 DoS;隔离状态本身也需有界,错误响应不得泄露内部容量细节。

Architecture Impact

Yes。新增跨 Gateway、Transmite、MQ、Message 与 Push 的 overload/admission contract,不改变业务所有权。

Core-flow Impact

Yes。改变请求接受、发布排队、消费并发、慢客户端处理和过载恢复。

Required Skill Updates

  • 更新 technology stack,登记容量配置与 overload 信号。
  • 更新 repository map,登记各阶段预算和配置所有权。
  • 更新 core flows,补充 admission、shed、已承诺工作保护和恢复。
  • 更新 testing case catalog,登记 Performance/Reliability 过载用例。
  • 更新运维容量调优、告警、扩容和回滚文档。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions