Uh oh!
There was an error while loading. Please reload this page.
docs: document the shared-Redis cluster rate-limit backend - #612
Conversation
Follow-up docs for the cluster-level rate limiting shipped in #607. - bootstrap-config: add the `ratelimit` root section (memory|redis, redis block, concurrency_ttl_secs) with field table, env overrides, and the same-Redis-as-cache / fail-open notes; list it in Root Sections + the minimal example. - production-deployment: add a "Rate-Limit Backend Choice" section steering multi-replica deployments to `backend: redis`. - architecture/two-phase-rate-limit: add a "Counter storage: local vs shared" section (RateStore backends, Redis key layout, redis TIME, ZSET concurrency semaphore, fail-open) and correct the now-stale "no shared store / no Redis / not on the v1 path" claims.
Warning Review limit reached
More reviews will be available in 1 hour, 21 minutes, and 8 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
Comment |
Uh oh!
There was an error while loading. Please reload this page.
Documentation for the cluster-level rate limiting shipped in #607 (issue api7/AISIX-Cloud#798). Docs-only — no code changes.
The feature added a pluggable rate-limit counter backend (
ratelimit.backend: memory | redis); this PR makes it discoverable in the docs and corrects statements the change made stale.Changes
docs/configuration/bootstrap-config.md— new## ratelimitsection: what it does (per-process vs shared), the field table (backend,redis,concurrency_ttl_secs), a config + env-override example, and the same-Redis-as-cache / fail-open notes. Also listedratelimitin Root Sections and the minimal example.docs/operations/production-deployment.md— new Rate-Limit Backend Choice section (mirroring Cache Backend Choice) steering multi-replica deployments tobackend: redisso configured caps hold cluster-wide.docs/architecture/two-phase-rate-limit.md— new Counter storage: local vs shared section explaining theRateStorebackends, the Redis key layout,redis.call('TIME')for cross-replica window consistency, the crash-safe ZSET concurrency semaphore, and fail-open. Corrected the previously-true-now-false claims ("no shared store", "There is no Redis dependency", "distributed counter backend ... not on the v1 path").The
docs/configuration/rate-limits.md"Counter Storage" section was already added with #607; this PR adds the config reference, operations guidance, and architecture detail around it.Notes
data-plane/docs/**tree has no build/lint step in CI, and the feature's behavior is already covered by the tests in feat(ratelimit): cluster-level rate limiting via shared Redis #607.