Мы должны иметь возможность информировать приложение Delphi в случае изменений в некоторых наших таблицах в MySQL.

Клиенты Delphi находятся в Интернете за брандмауэром, и они должны пройти проверку подлинности перед подключением к серверу уведомлений, который нам необходимо внедрить. Сервер может быть запрограммирован с использованием, например, Java, PHP или Python, и он должен поддерживать тысячи клиентов.

Обычно об одном изменении в базе данных нужно сообщать только одному клиенту, и я не думаю, что производительность будет узким местом. Просто необходимо иметь возможность информировать любого из этих тысяч клиентов, когда происходит изменение, затрагивающее конкретного клиента.

Я думал о решении, где:

  1. MySQL триггер будет информировать сервер уведомлений
  2. Клиент Delphi подключается к очереди сообщений и получает уведомление, используя ее

Мои вопросы:

  1. Что лучше всего сделать из триггера, чтобы сообщить внешнему серверу об изменении
  2. Какое решение очереди сообщений выбрать?
4
tputkonen 15 Июл 2010 в 16:02

3 ответа

Лучший ответ

Ответ на первый вопрос:

Проверьте этот вопрос и ответы на переполнение стека:

Когда добавляется новая строка в базе данных, должна вызываться внешняя программа командной строки

Теоретически, простая пользовательская функция может использоваться для запуска сообщения «измененная строка» посреднику / очереди сообщений. Но это касается внешних систем (по крайней мере, сетевой подсистемы), которые могут выйти из строя - и могут случиться плохие вещи.

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


Я написал соответствующую статью в блоге на эту тему здесь: События базы данных Firebird и промежуточное ПО, ориентированное на сообщения

Ответ на второй вопрос:

Создатели Second Life оценили несколько брокеров сообщений и опубликовали свои результаты - для некоторых продуктов, Клиентские библиотеки Delphi существуют или могут быть реализованы с использованием стандартных протоколов: Замечания по оценке очереди сообщений

С тех пор были выпущены другие продукты, некоторые из которых также могут быть интегрированы с клиентами Delphi через протоколы не-Java, например:

  • Открыть очередь сообщений (OpenMQ) 4.4 , которая используется по умолчанию < a href = "http://en.wikipedia.org/wiki/Java_Message_Service" rel = "nofollow noreferrer"> JMS провайдер на сервере приложений Sun GlassFish v3
  • JBoss HornetQ 2.1 , который будет поставщиком JMS по умолчанию на сервере приложений JBoss 6. HornetQ 2.0.GA получил оценки на 307% выше, чем ранее опубликованные результаты теста SPECjms2007, на том же оборудовании сервера и операционной системы.

Очень популярный брокер сообщений с открытым исходным кодом, который можно использовать в клиентах Delphi, Java, PHP, C # (и других):

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

Если скорость не так важна, но вам нужна высокая доступность (даже если ваша внутренняя система не работает), Amazon Simple Queue Сервис (Amazon SQS) - облачный сервис, доступ к которому можно получить с помощью интерфейсов в стиле REST и Soap.

5
Community 23 Май 2017 в 11:48

Существует интеграция Apache Camel и Spring, которая предоставляет несколько способов передачи сообщений.

1
Saky 15 Июл 2010 в 12:13

Почему бы не использовать протокол XMPP (он же Jabber)?

0
Riduidel 15 Июл 2010 в 12:04