Как спроектировать отказоустойчивое решение для приложения при нестабильной БД?

Question

[newalex]

Всем доброго дня.

Имею следующий кейс:
есть приложение, в котором пользователь производит определенные действия, приводящие к изменениям в БД.
База данных может быть недоступна в течение нескольких секунд (2-3 с) несколько раз в день, при этом действия пользователя должны обрабатываться в это время так же корректно.

Приложение на ASP.NET MVC + EF, БД MSSQL

Ищу красивые практики работы с подобным кейсом.

Answer 1

[Пума Тайланд]

складывать в локальный кеш и потом деплоить в бд, или выдавать пользователю что не удалось соединиться с бд и спрашивать повторить попытку?

Comments

[newalex]

Я как раз и хочу, чтобы пользователю не выдавались сообщения о такой проблеме. То, что его изменения попадут в базу не прямо сейчас, а через несколько секунд(в случае проблем с базой) в моем случае на логику работы никак не повлияет.

Локальный кеш... если только в памяти. Изменения в базе очень примитивны - смена статуса заявки например, комментарий в пару строк. Пока не могу придумать, как мой репозиторий будет складывать неудачные транзакции в кеш и потом их деплоить.

Answer 2

[raiboon]

Ваш подход неправилен. Если вы показали пользователю, что данные сохранены, то они должны быть сохранены. А то потом вас будут долго ругать "Я сохранил, потом закрыл, а оно не обновилось!".
По-хорошему, удостовериться, что запрос обернут в тразанкцию и повторят его до тех пор, пока она не завершится успешно, показывая состояния ожидания. МОжно не блокировать приложение, а изменения накапливать какой-нибудь очереди

Comments

[newalex]

Выше я написал: "То, что его изменения попадут в базу не прямо сейчас, а через несколько секунд(в случае проблем с базой) в моем случае на логику работы и на пользователя никак не повлияет". В таком случае я не считаю, что пользователю вообще надо что то показывать, беспокоить его какими то дополнительными сообщениями. Да и такое требование в ТЗ описано.

С точки зрения реализации видимо самый простой вариант - проапдейтить EF до 6ой версии и использовать DbExecutionStrategy (https://msdn.microsoft.com/ru-ru/library/system.da...(v=vs.113).aspx)