Стартуем новый сервис на Rails 8.0, в генераторе теперь по умолчанию Solid Queue. До этого у меня везде был Sidekiq с Redis, и он ни разу не подводил. Нагрузка ожидается скромная, тысяч 50 джоб в сутки: письма, вебхуки, пересчёт остатков. Есть смысл тащить Redis только ради очереди или Solid Queue уже можно брать?
На 50 тысячах в сутки Solid Queue справится без вопросов, это меньше одной джобы в секунду. Плюс для меня такой: если положить очередь в основную базу, джоба ставится в той же транзакции, что и запись, и не бывает, что запись откатилась, а джоба ушла. В Rails 8 по умолчанию очередь живёт в отдельной базе, тогда этого плюса нет, зато основную базу опрос не грузит. У Sidekiq взрослее экосистема и интерфейс, больше готовых решений для уникальности и ограничения частоты. Для нового сервиса на такой нагрузке я бы Redis не заводила.
Мы на Solid Queue с прошлой весны, сервис на 300 тысяч джоб в сутки, PostgreSQL. Работает. Из граблей: сначала все воркеры опрашивали базу каждые 0,1 секунды, и база это чувствовала. Для неспешных очередей подняли polling_interval до секунды, нагрузка ушла.
Там, где Sidekiq уже стоит, я его не трогаю, переезд ради переезда не нужен. Для нового проекта с такой нагрузкой взял бы Solid Queue: на один сервис в инфраструктуре меньше, на одну вещь, которая может упасть ночью, тоже. Только сразу поставьте mission_control-jobs, без интерфейса к очередям жить тяжело.
А GoodJob почему никто не вспоминает? Тоже в базе, интерфейс и крон из коробки. Правда, только PostgreSQL.
artem_67, на 50 тысячах в сутки это как раз нормально. Решили так: Solid Queue в отдельной базе на том же сервере MySQL, как делает генератор, Redis не заводим. Неделю гоняли на стейдже нагрузку в три раза больше ожидаемой: потерянных джоб ноль, задержка до старта в среднем 0,4 секунды, нам хватает. Если упрёмся, вернёмся к вопросу. За GoodJob спасибо, но у нас MySQL.
Ретраи только настройте явно через retry_on: у Active Job по умолчанию их нет, раньше это за вас делал Sidekiq.