Атомарные операции в нескольких внешних системах без транзакции
Скажите, что у Вас есть приложение, соединяющее 3 различных внешних системы. Необходимо обновить что-то во всех 3. В случае отказа необходимо откатывать операции. Это не твердая вещь реализовать, но сказать операцию 3 сбоя, и при откате, откат для операции 1 сбой! Теперь первая внешняя система находится в недопустимом состоянии...
Я думаю, что возможное решение состоит в том, чтобы закрыть приложение и принуждение ручной фиксации внешней системы, но с другой стороны... Это, возможно, уже использовало эту информацию (и возможно вот почему это перестало работать), или у нас не могло бы быть достаточного доступа. Или это даже не мог бы быть хороший способ откатывать действие!
Есть ли некоторые хорошие способы обработать такие случаи?
Править: Некоторые детали приложения..
Это - многопользовательское веб-приложение. Большая часть работы сделана с запланированными заданиями (через Кварц. Сеть), так большинство операций выполняется в своем собственном потоке. Некоторые пользовательские действия должны инициировать задания то обновление несколько систем все же. Внешние системы несколько нестабильны.
Я думал об изменении приложения для использования шаблона Команды и Единицы работы
4 ответа
Двухфазная фиксация ( 2PC ) здесь может быть подходящей.
Первый этап - это согласование различных баз данных с тем, что они готовы продолжить коммит. В вашем примере база данных 1 не будет продолжать запись, пока не будет уверенности, что все три базы данных сообщили, что транзакция возможна.
Это сравнивается с процессом, который вы описываете, который является «оптимистическим» подходом - база данных 1 предполагает, что транзакция должна пройти, пока не узнает об обратном, и будет вынуждена откатиться.
В зависимости от размера приложения (однопользовательский или корпоративный) закрытие приложения может быть плохой идеей.
Прежде всего, я бы посоветовал сохранить исходное состояние информации, изменяемой в трех внешних приложениях, в локальном хранилище вашего собственного приложения. Это означает, что вы можете по крайней мере определить, каким должно быть состояние отката в случае сбоя приложения / сбоя отката и т. Д. После успешного подтверждения транзакции вы можете удалить эти данные.
Что делать в случае сбоя одной из операций, зависит от функциональности трех внешних систем. Предположим, что одна из этих систем хранит данные о сотрудниках. Завершение работы приложения просто потому, что адрес одного сотрудника неверен из-за неудачной транзакции, - это излишне. Гораздо лучше просто проверять журнал неудачных транзакций (т. Е. Локальное хранилище, в которое вы сохранили начальные состояния трех внешних приложений) всякий раз, когда осуществляется доступ к данным сотрудника. Если данные этого сотрудника помечены как недопустимые, выдает ошибку, указывающую, что запись находится в недопустимом состоянии и не может быть получена.
Однако, если вся внешняя система будет приведена в беспорядок из-за неудачной транзакции, тогда да - здесь вы ничего не можете сделать, кроме как закрыть приложение, пока проблема не будет устранена.
Не могли бы вы объяснить, почему откат операции 1 может завершиться неудачей?
Состояние, в которое он стремится попасть, - это то, в котором он находился раньше, поэтому оно должно быть логически последовательным. Могут быть временные проблемы, такие как сбой сети, но может случиться так, что лучший способ справиться с этим - повторить попытку, пока проблема не исчезнет.
Если проблема в том, что последующие транзакции тем временем заблокировали или изменили данные, то у вас гораздо более серьезная проблема - ваши транзакции не являются атомарными, и их откат может привести к тому, что вывод других транзакций станет недействительным.
Ответ Oddthinking - хороший, но ограниченный, потому что на самом деле надежно сделать 2PC очень сложно. Это было известно в сообществе распределенных вычислений уже довольно давно, хотя многие люди изо всех сил стараются просто игнорировать это.
Если вы хотите углубиться в эту область, можно начать с алгоритма консенсуса Paxos . И имейте в виду, что это на удивление сложная проблема именно из-за проблем, на которые вы ссылаетесь, и из-за того факта, что на самом деле невозможно построить действительно надежную систему обмена сообщениями, которая может доставить сообщение за ограниченный промежуток времени. (Чтобы понять, почему это так, примите во внимание, что кто-то с обратной лопатой может уничтожить все сетевые соединения между различными взаимодействующими сторонами…)
Я подозреваю, что реальное решение - это спроектировать архитектуру всей системы и как вы вносите в него изменения, чтобы потеря связи в одной области не была катастрофической. Это может быть или не может быть легко сделать, в зависимости от точных деталей.