Russian Qt Forum

Имеется распределенная система. Каждый узел - рабочее место оператора. Связь между узлами осуществляется посредством ЛВС, в этой же сети находится концентратор, который присылает и получает информацию для управления устройствами.
(http://scheme.gif)

1. Система должна быть масштабируемой по количеству узлов. (Среднее количество узлов 3-5).
2. От системы не требуется никаких грандиозных распределенных вычислений.
3. Входящая информация от устройств должна быть преобработана модулем non-trivial. Ожидается, что такой модуль должен быть только на одном из узлов (назовем это singleton). Несмотря на то, что от устройств приходит все броадкастом, выполнение non-trivial на каждом узле может внести диссонанс, поскольку в этом модуле происходит накопление, а также учитывается порядок поступления.
4. Данные от устройств формируются в массивы данных.
5. Есть auto-control процесс. Он тоже singleton. Он анализирует уже готовые данные и формирует автоматические команды управления (подкрутить температуру и т.п.)
6. На каждом узле есть графический модуль, который отображает данные для оператора и формирует пользовательские команды.
7. В каждый момент времени графика показывает почти все данные массивов, и обновляется по мере поступления данных, скорее всего данные должны быть полностью реплицированы для каждого узла.

Мысли:
1. Систему пишут несколько человек, хотелось бы уменьшить количество людей, занятых синхронизацией, до одного.
2. auto-control модули, графика и non-trivial скорее всего отдельные процессы, работающие через QSharedMemory, чтобы их было легко двигать между узлами.
3. Для процессов система должна быть прозрачна, для объектов с данными - сильно упрощена.

Как бы вы спроектировали эту систему? Как организовать синхронизацию данных?  C++, Qt.

Слишком у вас всё сложно.

На деле разбиваем всё проще.

Концентратор данных (non-trivial)- получает данные с устройств, обрабатывает данные и заносит в БД, при изменении поступлении команд в БД, отправляет их устройствам.

БД - хранит данные об устройствах, массивов данных с них, количестве узлов и командах.
auto-control - анализирует уже готовые данные и формирует автоматические команды управления (заносит их в таблицу в БД).
Клиент - Запрашивает данные с БД, отображает пользователю и позволяет формировать пользовательские команды управления (заносит их в таблицу в БД).


Что тут получаем - монополизируем данные, монополизируем доступ к устройствам. Таким образом всё что идёт к устройствам должно пройти через нашу БД.

Получаем в итоге систему устройства<->контроллер<->бд<->читатели/писатели.

Масштабируемость по клиентам ограничивается лишь выбранной вами СУБД. (200-4000 пользователей)


PS

Мысли:
1. Систему пишут несколько человек, хотелось бы уменьшить количество людей, занятых синхронизацией, до одного.
Синхронизация тут не нужна, ибо имеем БД. Каждый узел не хранит информацию, он её лишь запрашивает.
2. auto-control модули, графика и non-trivial скорее всего отдельные процессы, работающие через QSharedMemory, чтобы их было легко двигать между узлами.
Нормальное решение, вот только нахрена SharedMemory если они могут быть запущены на разных машинах????
3. Для процессов система должна быть прозрачна, для объектов с данными - сильно упрощена.
Этого я вообще не понял. Для каких процессов, что значит прозрачна, что за объекты с данными? Ниччего не понимаю :D Система стандартная получается, простая как болт с гайкой.

Вариант с БД рассматривал и вот, что меня останавливает:
1. Система что-то вроде мягкого реального времени, сообщения терять не хорошо, отвечать на запросы своевременно. Локальная сеть помимо этой системы используется еще и для других целей, поэтому сеть - узкое место. Если БД на одном узле, то сеть будет перегружена, распределенная БД - не знаю как работает.
2. Некоторые данные будут меняться редко, поэтому их выгодно кешировать, а не делать запросы к БД каждый раз, с другой стороны, у кеша нет возможности получить сигнал об изменении в БД - нужно регулярно делать запросы.
3. Данных очень много, они разнообразны, их проще описать в виде классов, составлять таблицы будет затруднительно.
4. Большинство данных используются "однократно". В понятии классов - это просто синглтоны, в понятиях БД это будет таблица с одной строкой. Т.е. мало ситуаций, когда нужен график температур, обычно просто показывается текущая.

Короче беспокоит скорость и загруженность сети. Боюсь что "общее" решение не подойдет.


Это я уже мои мысли по реализации:
1. Все данные, которые нужно синхронизировать представляются в виде объектов, у которых есть интерфейсы.
2. Объекты полностью реплицированы, на каждом узле и у каждого процесса есть полная копия. Если процессы на одном узле, возможно для хранения данных используется QSharedMemory, чтобы не делать лишних копий.
3. Графика и одиночные процессы пользуются интерфейсами объектов, для них распределенная система "прозрачна", т.е. им кажется, что выполняются на одном узле.
4. Внутри объектов реализуется изменение и синхронизация данных.
5. Чтобы каждый объект (а их много) не занимался полностью работой с сетью, должен быть какой-то предок, который упрощает синхронизацию.
6. Поддерживать непротиворечивость реплик предлагается с помощью маркера. Каждый процесс, который хочет внести изменения должен получить маркер. Маркер один на все процессы. После окончания процесс рассылает всем изменения, и отпускает маркер. Передача осуществляется через UDP-сокет, а для процессов, которые располагаются на одном узле, передача может происходить через QSharedMemory или через QLocalSocket, если он не очень будет замедлять.
7. На каждом из узлов одна реплика является главной, она заведует маркером и осуществляет контроль над синхронизацией своих подопечных. (т.е. реплики составляют граф)

Преимущества:
1. Объекты могут отслеживать изменения и испускать qt-сигналы например для графики.
2. По сети передается минимум - сериализованные различия
3. Для локальных процессов активно используется другой транспорт

Ммм... Ладно небольшой урок логики.

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

Взгляните чистым взглядом - где больше будет нагружена сеть?

Ну а по делу.
1) Работа с БД быстрее, чем работа с ЛВС. Узел в сети НЕ БУДЕТ перегружен до тех пор, пока пропускная способность сети позволяет. Т.е. если вы сумеете достигнуть такого момента - у вас ляжет сеть. И если это случится - вам нужно будет однозначно проводить оптоволокно. Ибо запрос к бд даёт мизерную нагрузку.
2) А что мешает возвращать только изменённые данные? Простейшее поле в таблице "время последнего изменения" позволит вам убрать мусор. Ну а если точнее то это проблемы протокола и кеширования. И они никак не связаны с тем, где будет хранится информация. Пусть даже у вас там будет процесс с массивом данных - вам придётся тогда вместо бд запрашивать его. Шило на мыло, только мыло самодельное будет и не тестированное.
3) Это смешно... Таблица проще класса. Да, вы потратите 1 день на описание, но оно того стоит. К тому же видимо вы уже забыли о пункте 1.
4) бред. Заведите таблицу синглтонов и будет у вас всё хорошо.

Возьмите себя в руки и сделайте тестовый примерчик по моей архитектуре. Займёт это у вас ну пару дней. Зато увидите плюсы и минусы. А потом сделайте тестовый примерчик по вашей архитектуре. Займет это у вас нууу неделю, хотя мне кажется в разы больше.


На мой взгляд у вас сейчас фонтанирование идеями. Маркерный цикл поверх TCP протокола это конечно гениально, но бессмысленно. Такой подход был бы уместен на шине данных аля RS232 RS485.

PS если и это не заставит вас задуматься, я опускаю руки. :)

PPS ну и извечная истина - клиенту не нужны все массивы данных. Человек не сможет их воспринять. Потому запрашиваться будет только необходимое.

Спасибо,  попробую
Впервые проектирую крупную систему, хочется собрать все грабли

1. Попробуйте NoSQL БД - для слабо структурированных данных они замечательно подходят
2. Ну или если взглянуть на это с другой стороны - система похожа на распределенную очередь. Гляньте на ZMQ.

а бы на место "агрегатор" поставил субд + свой сервер
клиенты подключаются к "агрегатор" за данными и командами

Разбираю систему Вереса, возникло пару вопросов:
1. Как в данном случае можно получить сигнал об изменении. Т.е. если один из auto-control сгенерирует ошибку, ее тут же нужно высветить на экранах всех пользователей. Здесь придется заводить таблицу ошибок и опрашивать ее каждые 200мс? А если не через БД, то здесь возникает необходимость в дополнительном механизме типа MPI. Что-то типа CORBA, есть RMI, а есть и просто invoke событий.
2. Не планировалось заводить отдельный узел под сервер - это повысит стоимость системы. Поэтому сервер БД может быть только на одном из узлов пользователя. Пользователь может выключить узел или произойдет отказ и система не сможет работать.

Агрегатор - простенький блок с QNX, который умеет работать с устройствами + смотри 2.

ZeroMQ - очень интересная либа, спасибо, читаю.

И вновь к вопросу ZMQ. Там есть подписка на события.

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

ух ты. Очень похоже на мою схему =)) Весь топик не почитал, потому что лениво. Но у меня все на RPC построено. Есть сущность service, которая состоит из вызовов, есть конфиг, который указывает откуда брать какой сервис....хм. собственно все. А БД, не БД ... это  просто средство.

Кстати у меня тоже датчики. и тоже коллекторы и тоже узлы обработки и, наконец, финальный дата центр.