Лучший способ реализовать проверку правил при общении с устройством GPS

Question

Мы разрабатываем систему слежения за автотранспортными средствами.Как и все VTS, у нас есть GPS-устройства, которые отправляют информацию о местоположении на сервер.На сервере наш процесс TCP-коммуникатора продолжает считывать эти данные и сохраняет их в базе данных. Теперь нам нужно проверить некоторый набор правил для запуска оповещений для транспортных средств, например, нам нужно оповещение, когда транспортное средство достигает определенного места, если транспортное средство пересекаетконкретное ограничение скорости и т. д.Можете ли вы предложить лучший способ его реализации?Мы подумали о некоторых способах его реализации: 1. Наш TCP-коммуникатор, когда получает местоположение, должен проверить наличие предупреждений.2. Будет процесс, который будет продолжаться каждые 15 минут и проверять детали местоположения в течение этих 15 минут на наличие предупреждений.

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

Answer 1

Кто-то из FedEx фактически представил что-то подобное на конференции JavaOne, которую я посетил пару лет назад.

По сути, идея заключалась в том, чтобы использовать Drools Expert + Fusion для выполнения CEP (обработки сложных событий)на данные о местонахождении транспортного средства.

Насколько я помню, транспортное средство будет периодически (даже каждые несколько секунд) отправлять свои GPS-координаты в двигатель (событие), которое затем будет перевариваться механизмом правил,и в зависимости от правил может вызвать определенные действия, такие как оповещение («транспортное средство остановлено» или «вне курса») или отправка уведомлений («транспортное средство прибудет в пункт назначения через ~ 15 минут»).

(Google для «отслеживание движения drools fusion cep» раскрывает эту презентацию, которая должна дать вам немного больше информации или хотя бы немного понять.)

Answer 2

способ работы Drools заключается в том, что вы заполняете множество объектов в «Рабочей памяти» Drools. Пока вы заполняете объекты, Drools выяснит, какие правила «стреляют» по объектам, и сохраняет объекты в дереве ретей. Когда вы закончите помещать объекты в память и запустите все правила, Drools обработает код, который вы написали, в соответствии с правилом.

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

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

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

Answer 3

Нет причин бегать каждые 15 минут. Это приведет к задержке в триггерах, а также приведет к выбросам нагрузки каждые 15 минут, за которыми следуют периоды без нагрузки.

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

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

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

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

Я думаю, что все подходы, которые вы рассматриваете, будут работать нормально.