P0-5: Distributed (Redis-backed) rate limiting

Problem

crates/aisix-ratelimit/src/limiter.rs keeps state in a DashMap — process-local. The moment a deployment runs more than one DP replica (which is the default for any non-trivial setup), each replica enforces its own counter. Effective rate limit becomes N × configured limit where N = replica count. Hard blocker for prod multi-replica deployment.

Scope

DP (moonming/ai-gateway)

• New RedisLimiter impl behind the same Limiter trait (already abstracted at limiter.rs:1-2).
• Use atomic Redis Lua scripts for fixed-window counter (RPM/RPD/TPM/TPD) — single round-trip per check + commit. Same SipHash-fingerprinted key shape used today.
• Concurrency limiter: probably keep local (cluster-wide concurrency tracking is complex; per-replica concurrency cap is usually fine).
• Add rate_limit: config: backend: memory | redis + redis URL/auth (reuse aisix-cache/src/redis.rs connection logic).
• Algorithm: keep fixed-window for v1 to mirror existing semantics; sliding-window can be a follow-up.

CP (api7/api7ee-3-control-plane)

• No CRUD changes (rate_limit is per-api_key field on ai_api_key, #2625 already lists it as env-scoped).
• Optional: expose Redis backend choice in DP config push.

Dashboard UI (api7/AISIX-Cloud)

• Environment Settings page: "Rate limit backend" toggle (memory / Redis) + Redis URL field.

e2e

• Spin two DP replicas in compose, hit them round-robin, assert combined RPM cap is enforced (not 2×).

Estimate

DP 3d, CP 0d, UI 0.5d, e2e 1d

Start with crates/aisix-ratelimit/src/limiter.rs and the Redis connection logic in aisix-cache/src/redis.rs, then review the DP configuration and existing rate-limit behavior. Check the Environment Settings page and the compose-based e2e setup for the UI and multi-replica requirements. Done means Redis-backed fixed-window limits enforce the combined cap across replicas, with configuration and coverage for the requested paths.