Заявка на апрельскую встречу, 15 минут. Осенью мы перевели фоновые задачи с Sidekiq на Solid Queue: Rails 8.0, PostgreSQL, около 300 тысяч джоб в сутки. Главной причиной была не скорость, а желание убрать Redis, он у нас жил только ради очереди. Расскажу честно, что получилось и где споткнулись. Сначала держали очередь в основной базе, радовались, что джоба ставится в той же транзакции, что и запись. Потом поллинг начал заметно грузить базу, вынесли очередь в отдельную, как по умолчанию в Rails 8, и это преимущество потеряли. Пара задач так и осталась бы на Sidekiq, если бы не limits_concurrency. Конфиг сейчас такой:
production:
dispatchers:
- polling_interval: 1
batch_size: 500
workers:
- queues: [critical, default]
threads: 5
processes: 3
polling_interval: 0.1
- queues: [reports]
threads: 2
processes: 1Какие вопросы задать себе заранее, чтобы закрыть их в докладе?
Спрошу сейчас то же, что спрошу в зале: как у вас с уникальностью джоб и ретраями платёжных задач? В Sidekiq это у многих держится на сторонних gem'ах, и при переезде это теряют первым. И сколько стало соединений к базе очереди.
Ретраи через retry_on в Active Job с растущей задержкой, уникальность частично через limits_concurrency, частично ключом идемпотентности внутри задачи:
class ChargeJob < ApplicationJob
limits_concurrency to: 1, key: ->(payment) { payment.id }
retry_on Payments::GatewayError, wait: :polynomially_longer, attempts: 8
def perform(payment)
Payments::Charge.call(payment)
end
endСоединений к базе очереди в пике около 40, у неё свой пул.
Принеси график нагрузки на базу до и после выноса очереди. Без него разговор про поллинг будет на ощущениях
Записал на 23 апреля, первым докладом