У меня есть многоуровневая архитектура приложений, которая состоит из 4 частей:
- Уровень сетевого сервера / клиента
- Промежуточный уровень данных для взаимодействия междупроцессы
- Уровень мониторинга
- Клиентский уровень, состоящий из n экземпляров
Уровень клиент / сервер:
Уровень клиент / сервер обрабатывает асинхронную сетевую связь с другим компьютером, реализованную с использованием пользовательского протокола уровня 2.Из-за конструктивных ограничений, встроенных в коммуникации, он должен оставаться независимым и иметь возможность асинхронно опрашивать / передавать данные на уровень данных.
Промежуточный уровень:
Промежуточныйслой в настоящее время реализован с использованием базы данных.В одной таблице хранятся все возможные метки, которые могут быть вызваны (около 120 000).Вторая таблица содержит промежуточный кеш первой таблицы, содержащий только используемые значения, это требует постоянных обновлений и сбрасывается при запросе новой коллекции элементов.В третьей таблице отправляются обновления коллекции, и они содержат данные только при ожидании запроса.
Уровень монитора:
Уровень монитора является многопоточным монолитнымприложение.Он порождает n клиентских экземпляров в зависимости от того, сколько мониторов подключено.Он управляет глобальным состоянием между всеми клиентскими экземплярами, поскольку один или несколько из них могут иметь одинаковое / идентичное состояние.Он создает уникальный список необходимых значений, управляет отправкой запросов на обновление, когда клиентам требуется другой набор меток, и управляет повторяющимися обновлениями.
Очевидно, это не идеально.Если один экземпляр выйдет из строя, он может уничтожить остальные.То, что я хотел бы сделать, это удалить промежуточный слой, заменить его слоем монитора и сделать все как подпроцессы процесса монитора, чтобы их можно было вызывать по желанию, если что-то пойдет не так (например, остановка пульса связи, сбой клиентаи т. д.)
База данных кажется слишком тяжелой и недостаточно специализированной для обработки IPC (межпроцессное взаимодействие).Программа была написана в условиях экстремальных временных ограничений, поэтому использование базы данных было «простым решением» с надеждой на то, что оно изменится в будущем.Я большой поклонник надежности многопроцессной архитектуры Google Chrome , но я мало знаю о том, как они связывают все процессы вместе (pipe, tcp,?).
Итак:
Можно ли ожидать значительного улучшения производительности от использования IPC над базой данных для промежуточного уровня?
В какой формеIPC был бы идеален для системы Windows?
Существует ли кроссплатформенное (читай Linux) альтернативное решение, которое можно было бы использовать вместо него, если разработка была перенесена в Mono?
Где я могу найти ресурсы / примеры, чтобы помочь начать?
Примечание: я понимаю, что архитектура этой системы кажется излишнейсложный, но он существует в качестве внешнего интерфейса для гораздо большей системы.Это приложение также критически важно, так что стабильность важнее эффективности.
Обновление:
Я забыл упомянуть в первом вопросе.Данные / индекс базы данных загружаются непосредственно с виртуального диска при загрузке.Сама база данных была проиндексирована для оптимальной производительности.Таблицы или значения, которые требуют частых записей, не индексируются, но остальные данные.
Я ищу альтернативу для сравнения, потому что оптимизация базы данных была принята для еепредел, и я думаю, что есть еще много возможностей для улучшения.
Я выложу некоторые диаграммы архитектуры, как только у меня будет время, чтобы их составить.