Самый быстрый способ отслеживать доступ к API

Question

Я создаю API для моего приложения на Rails и хочу отслеживать, сколько раз пользователь вызывает определенный метод API, и ограничивать его, скажем, 1000 запросами в день. Я ожидаю очень большие объемы запросов для нескольких пользователей.

У вас есть предложение, как я могу отслеживать что-то подобное для каждого пользователя? Я хочу избежать повторной записи в базу данных и устранения блокировок.

Я в порядке выполнения отложенной записи (лимит API не должен быть сверхточным), но есть ли стандартный способ сделать это?

Answer 1

Если вы согласны с размещенным решением, взгляните на мою компанию WebServius (http://www.webservius.com), которая занимается управлением API (выдача ключей, обеспечение квот и т. Д.). У нас также есть поддержка биллинга, чтобы вы могли устанавливать цены за звонок и т. Д.

Answer 2

Вы можете попробовать Apigee . Похоже, это «бесплатно до 10000 сообщений в час».

Отказ от ответственности: я никогда не использовал Apigee.

Answer 3

Вот способ сделать это, используя кеш rails

call_count_key = "api_calls_#{params[:api_key]}_#{Time.now.strftime('%Y-%m-%d-%Hh')}"
call_count = Rails.cache.read(call_count_key) || 0
call_count += 1
Rails.cache.write call_count_key, call_count

# here is our limit
raise "too many calls" if call_count > 100

Это не идеальное решение, так как оно не обрабатывает параллелизм должным образом, и если вы используете кэш в памяти (по умолчанию для rails), то это будет счетчик на процесс

Answer 4

Это действительно зависит от количества серверов, набора данных, количества пользователей и т. Д.

Один из подходов состоит в том, чтобы сохранить структуру данных квоты в памяти на сервере и обновлять ее для каждого вызова. Если у вас есть несколько серверов, вы можете сохранить memcache квоты. Очевидно, что реализация на основе памяти не выдержит перезагрузки или перезапуска, поэтому для ее поддержки потребуется какая-то сериализация.

Если точность квот критична, то лучше всего сделать это в БД. Вы можете сделать это в файле, но тогда вы столкнетесь с теми же проблемами, которые пытаетесь избежать / w в базе данных.

EDIT: Вы также можете использовать смешанный подход - поддерживать кэш на основе памяти счетчиков вызовов user | api | и периодически записывать их в базу данных.

Немного больше информации о требованиях поможет сократить параметры ..