Развертывание в режиме распределенного кэша Siddhi

Согласно документам (https://docs.wso2.org/display/CEP310/Clustered+Deployment), вы можете запускать Siddhi в распределенном режиме.

Насколько я понимаю, все узлы будут совместно использовать определения потоков и работать в общем контексте (потоки, запросы, события ...).

Но я не могу заставить его работать:

  1. Работа с версией 2.0.0-wso2v4
  2. Я написал простую программу, которая запускает два siddhiManager с включенной распределенной обработкой.
  3. Программа создает поток и запрос в siddhiManager1
  4. Добавляет обратный вызов потока, который распечатывает события в двух менеджерах (предыдущий поток)
  5. Отправить событие в siddhiManager1
  6. Печатает потоки в siddhiManager1 и siddhiManager2

Результат:

  • Я вижу, как работает Hazelcast, каждый менеджер видит другого.
  • siddhiManager1 имеет один поток, один запрос и выводит одно событие.
  • у siddhiManager2 ничего нет.

Я тестировал с использованием siddhi-distribution (fat-jar), но также с использованием jar-файлов siddhi-api, siddhi-core и siddhi-query.

Siddhi-distribution fat-jar имеет внутри некоторый xml, связанный с Hazelcast, но насколько я могу видеть, эти конфигурации не загружаются, и в исходном коде (github) я не вижу ничего особенного в этих файлах (siddhiManager).

Есть идеи о том, как запустить siddhi в режиме распределенного кеширования? Что я делаю неправильно?


person user2451444    schedule 04.04.2014    source источник


Ответы (1)


Siddhi не копирует артефакты (запросы, определения потоков) через Hazelcast. Он делится только событиями / состоянием двигателя. Итак, чтобы это заработало, вам сначала нужно отдельно синхронизировать эти запросы / определения потоков для всех экземпляров Siddhi в вашей распределенной установке. Как только они у вас будут, вы сможете заставить его работать в распределенном режиме.

Обратите внимание, что в приведенном выше объяснении предполагается, что вы используете только библиотеку Siddhi без продукта WSO2 CEP. В WSO2 CEP есть механизм для синхронизации этих артефактов развертывания между узлами в распределенной установке.

person Rajeev Sampath    schedule 05.04.2014
comment
Спасибо за ответ Раджив, но тогда я не понимаю распределенного режима развертывания в сиддхи. Позвольте мне задать вам несколько вопросов: - person user2451444; 07.04.2014
comment
1) При распределении передаются только события / состояние движка ... Итак, какие преимущества дает это решение? какова настоящая цель распределенного режима? или, другими словами, почему и когда я должен использовать этот тип развертывания? - person user2451444; 07.04.2014
comment
2) Под событиями вы подразумеваете стримовые события? В моих тестах ни потоки, ни запросы, ни события потока не видны и не разделяются между движками. - person user2451444; 07.04.2014
comment
3) Я могу синхронизировать запросы / определения потоков, но если у меня есть временное окно, как оно будет работать в распределенном режиме? у каждого двигателя было бы свое окно? или есть глобальное окно? - person user2451444; 07.04.2014
comment
1. Я думаю, что модифицированный ответ отвечает на этот вопрос. Вы можете синхронизировать артефакты в wso2 cep. - person Rajeev Sampath; 07.04.2014
comment
2. Состояние движка будет воспроизведено, если вы правильно настроите систему, т.е. если узел A и узел B имеют одинаковое состояние, вам понадобится, чтобы они имели одинаковый набор артефактов. - person Rajeev Sampath; 07.04.2014
comment
3. Узлы будут иметь синхронизированные копии временного окна, синхронизированные с помощью hazelcast. Таким образом, для пользователя это выглядит как глобальное окно. - person Rajeev Sampath; 07.04.2014