shreemaan-abhishek opened a new pull request, #13574:
URL: https://github.com/apache/apisix/pull/13574
### Description
The `limit-count` sliding-window limiter read the current counter, evaluated
the limit (including the smoothed carry-over from the previous window), and
only then incremented, as three separate steps. With the redis stores the `get`
and `incr` are separate round trips, so under concurrency multiple requests can
all pass the check before any increment is observed and exceed the configured
rate.
This folds the accept/reject decision and the increment into a single atomic
store operation, `check_and_incr`:
- **redis / redis-cluster / redis-sentinel**: a Lua script that reads both
windows, decides, and increments only on accept, in one server-side step.
- **local (shared dict)**: a single non-yielding `get`/decide/`incr`
sequence.
The existing contract is preserved: `incoming()` still never increments on
reject (verified by the delayed-sync regression test), while `commit()` keeps
flushing already-permitted deltas. The previous reactive post-increment
re-check is no longer needed and is removed.
Because the redis script now touches two keys (current and previous window),
the counter key carries a `{...}` hash tag so both windows hash to the same
redis-cluster slot.
#### Which issue(s) this PR fixes:
N/A (hardening; reported internally against the API7 fork)
### Checklist
- [x] I have explained the need for this PR and the problem it solves
- [x] I have explained the changes or the new features added to this PR
- [x] I have added tests corresponding to this change
- [x] I have updated the documentation to reflect this change (internal
correctness fix; no API/behavior change)
- [x] I have verified that this change is backward compatible
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
