База данных хорошая система развязки?

Question

У нас есть две системы, в которых система A отправляет данные в систему B. Требуется, чтобы каждая система могла работать независимо от другой и ни одна из них не взорвалась, если другая вышла из строя. Вопрос в том, как лучше всего взаимодействовать системе A с системой B при выполнении требования разделения.

Система B в настоящее время имеет процесс, который опрашивает данные в таблице базы данных и обрабатывает все новые строки, которые были вставлены.

Один из предложенных вариантов заключается в том, чтобы система A просто вставляла данные в таблицу db системы b, а система B обрабатывала новые строки существующим процессом. Вопрос в том, отвечает ли это решение требованию разделения двух систем? Считается ли база данных частью системы B, которая может стать недоступной и привести к взрыву системы A?

Другое решение состоит в том, чтобы система A помещала данные в очередь MQ и имела процесс, который считывал бы из MQ и затем вставлял в базу данных системы B. Но это только дополнительные расходы? В конечном итоге очередь MQ более отказоустойчива, чем таблица в БД?

Answer 1

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

Существует четыре общих уровня интеграции:

1. Совместное использование базы данных
2. Обмен файлами
3. Удаленный вызов процедуры
4. Передача сообщений

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

Как и любая инфраструктура центральной интеграции, MQ следует размещать в среде с высокой доступностью, полным отказоустойчивостью и т. Д. Существуют и другие решения для очередей, которые позволяют распределять координацию очередей.

Answer 2

Использование очередей для общения. Не «передавайте» данные из системы A в систему B через базу данных. Вы используете базу данных как гигантскую, дорогую, сложную очередь сообщений.

Использовать очередь сообщений в качестве очереди сообщений.

Это не «дополнительные» накладные расходы. Это лучший способ развязать системы. Она называется Service-Oriented Architecture (SOA), и использование сообщений абсолютно необходимо для проектирования.

Очередь MQ намного проще, чем таблица БД.

Не сравнивайте «отказоустойчивость», поскольку СУБД использует огромные (почти невообразимые) накладные расходы для достижения разумного уровня гарантии того, что ваша транзакция завершена правильно. Запирание. Буферизация. Пишите очереди. Управление хранением. И т.д. И т.д.

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

Answer 3

В SQL Server я делал бы это через пакет служб SSIS или задание (в зависимости от количества записей и сложности того, что я перемещал). Другие базы данных также имеют решения ETL. Мне нравится решение ETL, потому что я могу вести журналы того, что было изменено и какие ошибки были обработаны, я могу отправлять записи, которые по какой-то причине не переходят в другую систему (структуры данных редко бывают одинаковыми между двумя базами данных), в холдинг стол, не убивая остальную часть процесса. Я также могу вносить изменения в данные по мере их поступления для корректировки различий в базе данных (например, значения таблицы поиска, скажем, заполненный статус в db1 равен 5, и 7 в db2, или, скажем, db2 имеет обязательное поле, которого нет в db1, и вы необходимо добавить значение по умолчанию в поле, если оно равно нулю). Если один или другой сервер не работает, работа пакета SSIS завершится сбоем, и ни одна из систем не будет затронута, поэтому он поддерживает разъединенные базы данных, как при использовании триггеров, так и репликация не будет.