JMS сообщение Модель для включения данных или указателей на данные? - PullRequest
3 голосов
/ 07 мая 2010

Я пытаюсь разрешить расхождение во мнениях, когда ни у кого из нас нет опыта работы с JMS.

Мы хотим использовать JMS для связи между приложением j2ee и автономным приложением, когда происходит новое событие. Мы будем использовать одну очередь точка-точка. Обе стороны основаны на Java. Вопрос заключается в том, отправлять ли сами данные события в теле сообщения JMS или отправлять указатель на данные, чтобы автономная программа могла получить их. Подробности ниже.

У меня есть приложение j2ee, которое поддерживает ввод данных о новых и обновленных людях и связанных с ними событиях. Записи о персонале и связанные события записываются в базу данных Oracle. Существуют также отдельные, отдельные программы, которые вносят новые записи о людях и событиях в базу данных. Когда новое событие происходит через любую из 5-10 различных функций приложения, мне нужно уведомить удаленные системы через исходящий интерфейс, используя стандартный отраслевой протокол обмена сообщениями. Исходящий интерфейс был разработан как отдельное приложение для поддержки масштабируемости за счет асинхронной работы и перемещения его на отдельный сервер.

В настоящий момент приложение j2ee хранит большую часть данных в памяти на момент ввода события. Данные будут состоять из приблизительно 6 различных объектов; объект person и некоторые с несколькими экземплярами для среднего размера в диапазоне от 3000 до 20000 байт. В некоторых особых случаях эта сумма может быть во много раз больше.

С точки зрения производительности и надежности, должен ли я смоделировать сообщение JMS для передачи всех данных, необходимых для создания сообщения интерфейса, или смоделировать сообщение JMS, содержащее ключи записи для данных и заставить автономное приложение Java получать данные для создания сообщения интерфейса?

Ответы [ 4 ]

0 голосов
/ 12 мая 2010

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

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

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

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

При сериализации java-объектов в сообщения необходимо синхронизировать формат класса между отправителем и потребителем, а также очистить очередь, прежде чем можно будет обновить ее до новой версии класса на сайте-потребителе. Конечно, то же самое относится к обновлениям базы данных, когда вы просто передаете идентификатор.

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

0 голосов
/ 07 мая 2010

Для очереди не составит труда обработать данные, сообщения в очереди все равно сохраняются (постоянство памяти, файла или базы данных, что лучше подходит для размера вашей очереди).

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

0 голосов
/ 07 мая 2010

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

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

  • Размер данных : мы будем хранить данные в BLOB, потому что они могут быть очень большими. В вашем случае размер данных, вероятно, вписывается в сообщение в любом случае.
  • Потеря сообщения : мы планировали худшее. Если сообщения были потеряны, мы могли бы восстановить данные, и у нас была процедура восстановления для повторной отправки сообщений. Выглядит, может быть, параноидально, но вот два сценария, которые могут привести к потере некоторых сообщений: (1) очередь очищается по ошибке (2) происходит ошибка и сообщения не могут быть доставлены в течение длительного времени Они попадают в очередь мертвых сообщений (DMQ), которая в конечном итоге достигает своего предела, и начинают отбрасывать сообщения, если они настроены неправильно.
  • Мониторинг : разные сообщения / команды могут обновлять одну и ту же строку в базе данных. Это было легко отслеживать и устранять неисправности.

Использование базы данных JMS +, однако, немного усложняет дизайн:

  • распределенные транзакции : это добавляет сложности, а иногда некоторые проблемы . Распределенные транзакции имеют небольшие различия с «обычными» транзакциями, такими как распределенное время ожидания.
  • настойчивость : код менее интуитивно понятен. Сначала необходимо сохранить данные, чтобы иметь PK, что приводит к некоторой сложности в коде, если используется ORM.

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

0 голосов
/ 07 мая 2010

Отправляйте данные, а не указатель. Я бы не подумал, что ваши сообщения имеют необычный размер, который не может быть обработан.

...