Я разрабатываю API (веб-сервис для внутренней сети WCF nettcp, а не общедоступный веб-API), который будет нацелен на «Группы доступности AlwaysOn» базу данных.AlwaysOn установлен в режиме синхронной фиксации.Мне было предложено использовать вторичную реплику для повышения производительности.Существует способ нацеливаться на только для чтения дБ (строка подключения клиента должна указывать намерение приложения как «только для чтения») для выгрузки рабочих нагрузок из основной реплики.Так что я подумал ... действительно ли шаблон дизайна справился с этой ситуацией?
Мы говорим о двух строках соединения ( чтение-запись и только чтение ) для теоретически одной базы данных.Простое правило: API должен targtet первичный для записи и вторичный для чтения, но жизнь не так проста.
Например: если клиент вызывает DeleteItem и сразу после GetAllItems, даже в режиме синхронизации, он может получить все элементы, включая удаленный, поскольку только для чтения дБне было достаточно времени для обновления (иногда данные еще не доступны для чтения, мы говорим о миллисекундах. Я проверял это ).Поскольку API решает, какую строку подключения использовать, он будет использовать чтение-запись для операции DeleteItem, а затем только для чтения для операции GetAllItems.
Итак, мой вопрос: как мне обращаться с активной вторичной базой данных?
Должен ли я позволить API решать, использовать ли базу данных только для чтения для разгрузки worload?
Должны ли клиенты API иметь возможность принимать явное решение?Например, «Привет API, я хочу все элементы, но использую строку подключения только для чтения!» ?
Существует ли схема проектирования, как справиться с этой ситуацией?
Спасибо за помощь,