Conversation
vladefr97
left a comment
There was a problem hiding this comment.
Не очень понял что в данном pull request реализовано? Просто какие-то пустые классы
| @@ -2,4 +2,5 @@ venv/ | |||
| __pycache__/ | |||
There was a problem hiding this comment.
Нужно добавить в проект:
- Readme.md c описанием структуры и функциональности проекта, списком команд для работы с проектом (запуск, настройка и тд)
- env.example со списком необходимых .env переменных
- docker-compose с необходимым окружением для запуска проекта (как минимум redis). В идеале и сам сервис запаковать в Dockerfile и добавить в docker-compose, чтобы весь проект можно было поднять одной командой, но достаточно хотя бы окружение
| global_key = f"rate_limit:global:{resource}:{current_window}" | ||
| ip_key = f"rate_limit:ip:{resource}:{client_ip}:{current_window}" | ||
| ttl = window_seconds + 10 | ||
| lua_script = """ |
There was a problem hiding this comment.
Зачем lua скрипт используете? Можно просто redis клиента использовать
There was a problem hiding this comment.
В отчете я аргументировала выбор такого решения следующим образом.
"Redis выполняет Lua-скрипты атомарно — во время выполнения скрипта сервер не обрабатывает другие команды. Это исключает race condition между проверкой лимитов и увеличением счетчиков, что критически важно для корректной работы системы ограничения трафика при высокой нагрузке".
В более ранней версии я делала через пайплайны Redis (отдельно брала счётчики, проверяла и потом их увеличивала). Но при таком подходе возникала проблема. Если два запроса приходят в одно и то же время, они могут оба увидеть одинаковое значение счётчика, оба решить что лимит не превышен, и оба его увеличить.
Поэтому я переделала на Lua-скрипт. Он выполняется прямо в Redis и делает операции проверки и увеличения как одно целое. Пока скрипт работает, другие запросы ждут. Это полностью убирает race condition и гарантирует, что лимит никогда не будет превышен.
No description provided.