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

Question

Я разрабатываю систему, которая получает сообщения, связанные с деятельностью пациента в больнице, анализирует и сохраняет эти данные (сообщения HL7 2.x).Некоторые сообщения могут содержать основную информацию о пациенте, другие сообщения могут содержать результаты лабораторных исследований, расшифрованные документы и т. Д.

Я хотел бы использовать для этого асинхронную надежную систему обмена сообщениями (например, WCF + MSMQ или Apache Camel +).ActiveMQ. Похоже, что эти технологии подойдут.

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

Я не хочу останавливать обработку сообщений для всех пациентов, если возникает проблема, только сообщения для одного пациентау меня есть проблема.

Есть ли какой-то шаблон проектирования или какой-то метод обработки подобных ситуаций, которые я пропускаю?

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

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

Answer 1

Это очень похоже на недавнее требование от клиента, вот как мы решили это в Camel / ActiveMQ ...

• использовал ActiveMQ группы сообщений для однопоточной обработки (сохранение порядка и т. Д.) Для данного пациента и все еще допускает многопоточную обработку
• настройка Camel обработка исключений для добавления пациентов в список исключений (хранится в Hazelcast или Cache ) при возникновении ошибок обработки
• использовал фильтр Camel для маршрутизации сообщений для пациентов из списка исключений в очередь исключений
• установить таймер для периодической повторной отправки сообщений из очереди исключений
• настройка уведомлений по электронной почте при возникновении исключений (используйте агрегатор , если это большой объем, чтобы группировать сообщения в меньшее количество писем и т. Д.)
• используется ActiveMQ JMX , чтобы вручную просматривать / повторять / перемещать / удалять сообщения, чтобы сортировать их соответствующим образом (встроенная веб-консоль для поддержки этого)

Answer 2

Вы можете использовать Content Based Router http://camel.apache.org/content-based-router.html

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

Затем, когда пациент «исправлен», вы можете использовать селектор JMS, чтобы забрать сообщения для этого пациента из «очереди проблем» и снова включитьобычная очередь, поэтому они повторно обрабатываются.

Answer 3

http://ignaciosuay.com/unit-testing-hl7-messages-with-apache-camel/I предложит вам использовать activemq и верблюда с включенной опцией redelivery. Таким образом, если что-то пойдет не так, вы получите сообщение до тех пор, пока оно не будет обработано. Кроме того, Вы можете указать количество раз, которое может быть повторно доставлено. Пожалуйста, ознакомьтесь с политикой верблюдов:

http://camel.apache.org/redeliverypolicy.html

Кроме того, я написал простой тестовый пример, который использует camel и hl7, который, возможно, поможет вам:

http://ignaciosuay.com/unit-testing-hl7-messages-with-apache-camel/

Answer 4

Как обрабатывать сбои для конкретного идентификатора пациента.

Хорошо наличие очереди сообщений для каждого пациента не масштабируется вообще. У вас может быть 1000 пациентов, поэтому вам нужно поддерживать одинаковое количество очередей. Кошмарный сон.

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

Я имею в виду, что если служба не может обработать сообщение из очереди (возможно, из-за проблем с данными в сообщении или из-за недоступности нижестоящих зависимостей), служба может выполнить одно или несколько из следующих действий:

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

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

Надеюсь, это поможет.

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