Обеспечение согласованности при кэшировании данных в байтах after_commit

Question

Для конкретной таблицы базы данных нам нужен кеш в памяти этих данных, который всегда синхронизируется с базой данных. Моя текущая попытка состоит в том, чтобы записать изменения в кеш в крюке after_commit - таким образом мы не будем писать никаких изменений в кеш, которые могут быть возвращены позже.

Однако эта стратегия уязвима к следующему сценарию:

1. замки Пронизывайте и обновляет записи, хранит дорожим 1
2. Поток А совершает Изменение
3. Thread B замки и обновления записей, магазины Значение 2
4. Резьба B совершает замену
5. Резьба B запускает крючок after_commit, поэтому кэш теперь имеет значение 2
6. Поток А запускает after_commit крюк, поэтому кэш теперь имеет значение 1 но должно иметь значение 2

Правильно ли я об этой проблеме и как бы один решить эту проблему?

Answer 1

Решение, которое мы разработали, состоит в том, чтобы заблокировать кеш для чтения/записи before_commit и разблокировать его в after_commit. Кажется, это трюк.

Answer 2

Вы правы в этой проблеме.

Существует обратный вызов after_save, который выполняется в рамках одной и той же транзакции. Возможно, вы захотите использовать этот вариант вместо крюка after_commit, который запускается после транзакции.

Но вам придется иметь дело с откатной транзакцией самостоятельно.

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

Но даже при этом: многопоточные системы сложно синхронизировать. И вы даже не можете гарантировать, будет ли сохранено первое или второе обновление в вашем кеше, потому что система кэширования может быть также многопоточной.

Возможно, вы захотите прочитать о different consistency models.