Одновременное обсуждение дизайна обработки сообщений - PullRequest
0 голосов
/ 10 мая 2019

Недавно я разработал систему для обработки данных о работоспособности с использованием JMS с использованием Oracle Advanced Queuing (AQ). Сообщение должно содержать информацию о пациенте, такую ​​как имя, номер медицинской карты и т. Д. Кроме того, сообщение может содержать записи (записи) иммунизации пациента. Я использую Spring Boot и смог обработать эти сообщения одновременно, настроив несколько прослушивателей сообщений (до 30). Таким образом, я смог получить представление. Однако эти сообщения обрабатываются в хронологической последовательности, что приводит к несогласованности данных. Например, Сообщение A представляет новую запись Пациента, а сообщение B представляет обновление для Пациента, созданное с помощью сообщения A. При последующей обработке (Сообщение A, а затем Сообщение B) результат согласуется с вышестоящей системой. Однако при одновременной обработке результаты не синхронизируются с реальностью (сообщение B может обрабатываться до сообщения A). Ясно, что я не начну обрабатывать Сообщение B, если есть Сообщение A. Скажем, у меня есть средства для его определения (каждое сообщение имеет метку времени и статус). Но как это практически реализовать? Буду признателен, если кто-нибудь поделится своим опытом. Реальная технология не имеет значения, я ищу какой-то шаблон проектирования

Ответы [ 3 ]

1 голос
/ 10 мая 2019

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

Сериализация всей обработки сообщений

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

Повторить сообщения об отсутствии заказа

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

0 голосов
/ 24 июня 2019

Просто чтобы закрыть обсуждение.Мое окончательное решение было предложено @Justin Bertram просто отправить сообщение обратно в очередь с опцией задержки.Oracle Advance Queuing позволяет помещать в очередь сообщения с опцией задержки.

0 голосов
/ 14 мая 2019

Один из способов повысить производительность без ущерба для порядка - это распределить ваши данные по нескольким непересекающимся темам .Таким образом, пациент A и пациент B могут использовать разные темы, но обновление для пациента A будет относиться только к теме пациента A.

Как?Один из способов начать - использовать в качестве темы первую букву фамилии пациента.Таким образом, все сообщения пациента Миллера идут на тему M, а Джон Доу - на тему D. Конечно, этот дистрибутив не идеален (не так много работы для подписчика 'X'), но вы также можете использовать хеш-код полного имени по модулю30, например.Или, если у вас есть идентификатор, используйте последние 2 цифры идентификатора для публикации и подписки на темы с 00 по 99.

В случае, если вас беспокоит потеря сообщений, используйте долговременную подписку JMS или настройте X числоочереди вместо.

...