Rails сканирует ActiveRecord на предмет изменения атрибутов

Question

Я создаю систему знакомств в своем приложении rails, где пользователи могут публиковать матчи в течение определенного времени.Если время, за которое проводится сопоставление, достигнуто без принятия, мне нужно аннулировать это совпадение, установив для его активного флага значение false.

Каков наилучший подход для этого?Я читал плохие вещи о загромождении моделей слишком большим количеством обратных вызовов, и я не уверен, является ли ActiveModel Dirty лучшим решением здесь.У кого-нибудь есть предложение, которое согласуется с лучшими практиками и не требует тонны запросов к БД?

Answer 1

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

• сразу после сохранения, сохраните совпадение 'id в Redis с использованием предварительно определенного TTL.Например, используя ключ в форме matches:open:1234.Всякий раз, когда вам нужен список открытых совпадений, просто запрашивайте ключи в matches:open:*, и вы можете использовать их для выполнения целевого запроса в вашей базе данных ActiveRecord.Истечение срока будет полностью из ваших волос.Вы также можете легко «дотронуться» до записи, если хотите, чтобы матч оставался открытым дольше.Просто обратите внимание на транзакции вашей базы данных и возможность отката: вы не хотите записывать недопустимые идентификаторы базы данных в Redis:)

• при создании соответствия, также ставьте в очередь задание (либочерез ActiveJob или более конкретный фреймворк, такой как Sidekiq), который извлекает запись и проверяет, была ли она принята за это время.Вы можете оптимизировать это, используя что-то вроде where(id: match_id, accepted_at: nil).first, и если возвращается nil, вы можете предположить, что совпадение было принято за это время без необходимости создания экземпляра записи.Если вам нужна функциональность, чтобы держать матч открытым дольше, чем начальная задержка, вам нужно будет найти и отменить уже поставленную в очередь задачу и поставить новую в очередь.

Что касаетсяПериодически запрашивая все ожидающие совпадения в повторяющейся работе, это усложняет защиту от условий гонки в отношении блокировок на уровне строк, а также значительно затрудняет масштабирование, поэтому я лично рекомендовал бы против этого.