Надежная асинхронная обработка в SQL Server

Этот ответ действителен, только если я правильно понял ситуацию:

• Сторонний сервер, используемый для предоставления веб-метода для обновления клиентов по одному
• теперь они ожидают получить эту информацию из доступной вам таблицы SQL Server для INSERT/UPDATE/DELETE
• вы можете просто запихнуть в эту таблицу свои запросы, связанные с клиентами, и через некоторое время они будут обработаны
• когда информация, связанная с клиентом, обновляется, вам необходимо выполнить некоторые дополнительные локальные действия (поставить SMS в очередь, зарегистрировать активность)

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

1. Выберите все совпадающие аккаунты в #TempTable

   Это может быть необязательно, потому что у вас уже есть таблица для заполнения ваших запросов - сторонняя таблица. Единственная проблема будет заключаться в синхронизации запросов, но для этого для анализа вам необходимо предоставить более подробную информацию (разрешены несколько запросов для одного и того же клиента? защита от повторной отправки одного и того же запроса?)

2. для каждой записи клиента...

   Это должно быть единственным изменением в вашей реализации. Теперь он имеет значение - для каждой записи о клиенте, которая асинхронно обрабатывается на сторонней стороне. Конечно, ваша третья сторона должна дать вам некоторое представление о том, что они действительно обработали ваш запрос клиента, иначе вы понятия не имеете, с чем работать. Итак, когда они проверяют и обрабатывают данные, они могут предоставить, например. Обнуляемые столбцы «success_time» и «error_time», чтобы оставить вам сообщение о том, что было сделано и когда. Если есть успех, вы продолжаете обработку. Если нет, вы, вероятно, можете что-то сделать и с этим.

   Но как реагировать, когда вы получаете обратно асинхронную информацию (например, sucess_time IS NOT NULL)? Ну, есть несколько способов сделать это. Лично я стараюсь избегать триггеров, потому что они могут усложнить вам жизнь (отстойная их видимость, могут вызвать проблемы с репликацией, могут вызвать проблемы с транзакциями...) Я использую их, если мне действительно нужно первоклассное немедленная отзывчивость. Другая возможность — использование асинхронных очередей с настраиваемой активацией, что означает Service Broker. Тем не менее, многие люди избегают использования технологии SB - она ​​отличается от остальной части SQL-сервера, у нее есть свои особенности, отладка не так проста, как с простыми старыми операторами SQL и т. д. Другой возможностью может быть пакетная обработка асинхронных ответов на вашей стороне. используя задание агента. Так как вы уже используете работу, вы должны быть в порядке с ней. По сути, таблица должна действовать как точка синхронизации — вы заполняете свои запросы (INSERT), третья сторона их обрабатывает (SELECT). После обработки запросов они помечают их как таковые (UPDATE Success_time или error_time), и в конце вы обрабатываете этот ответ (SELECT) с помощью задачи задания агента. И ваша обработка включает в себя SMS-сообщение и регистрацию, возможно, даже УДАЛЕНИЕ из сторонней таблицы.

   Еще одна вещь, которую следует упомянуть, это то, что вам нужны методы синхронизации здесь. Во-первых, ничего не делайте без транзакций, иначе вы можете в конечном итоге обработать фантомные ответы и/или пропустить действительные ожидающие ответы. Во-вторых, когда вы ВЫБИРАЕТЕ ответы (строки, которые обрабатываются сторонней стороной), вы можете получить некоторое улучшение, используя подсказку READPAST (пропустить то, что заблокировано). Однако, если вам нужно обновить/удалить из вашей сторонней таблицы после обработки ответа, вы можете использовать SELECT с UPDLOCK, чтобы заблокировать другую сторону темперирования с данными между вашими INSERT и UPDATE. Или вы не используете какие-либо подсказки блокировки, если вы не совсем уверены, что происходит с рассматриваемой таблицей.

Надеюсь, поможет.