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