Сетевое программирование абстракция, декомпозиция

Question

У меня проблема в следующем:

Серверный процесс 1

• Постоянно отправляет обновления, которые происходят в хранилище данных

Серверный процесс 2

• Клиенты связываются с сервером, который запрашивает хранилище данных и возвращает результат

Дело в том, что результаты, которые процесс 1 и процесс 2 отправляют обратно клиенту, совершенно разные и не имеют отношения.

Как можно разложить это? У вас есть только один процесс, постоянно отправляющий данные и определяющий протокол, который имеет бит, который соответствует типу возвращаемого значения 1 или 2?

У вас есть два процесса? Как они совместно используют хранилище данных (это просто структура, а не база данных)?

Спасибо!

Answer 1

Если вы можете ограничиться Twisted, я рекомендую использовать Perspective Broker . По сути, это система RPC, и она не особо заботится о понятии «клиент» и «сервер» - либо инициатор TCP-соединения, либо респондент может начать вызовы RPC в PB.

Таким образом, сервер 1 будет принимать регистрационные вызовы с объектом обратного вызова и вызывать обратный вызов всякий раз, когда будут доступны новые данные. Сервер 2 обеспечивает различные операции RPC, когда клиенты требуют их. Если бы они работали с одними и теми же данными, я бы поместил оба сервера в один процесс.

Answer 2

Звучит так, будто вы хотите передавать свои серии целых чисел "куда-то", а также собирать их в хранилище данных. В моей системе я передаю показания датчиков в базу данных, а также позволяю им напрямую обращаться к веб-клиентам, давая им показания в реальном времени. Я написал запись в блоге о том, почему база данных не подходит для оперативных данных - хотя она идеально подходит для сохранения данных для последующего анализа.

Я бы хотел, чтобы первым серверным процессом был витой сервер, который использует txamp для потоковой передачи целых чисел в RabbitMQ . Любые клиенты, которым нужны живые данные, могут подписаться на поток в RabbitMQ, также используя Txamp. Клиенты веб-браузера могут использовать Orbited , вот рабочий пример .

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

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

Answer 3

Почему бы не использовать базу данных вместо "просто структура"? Как реляционные, так и нереляционные БД обладают многими практическими преимуществами (их используют отдельные процессы, заботятся о репликации [[и / или моментальные снимки, резервные копии, ...]], широкие функциональные возможности, если они необходимы для «запросов», и т. Д. и т. д.).

В худшем случае «просто структура» может быть обработана третьим процессом, который полностью посвящен ей (в основном, имитируя то, что предлагал бы любой движок БД - хотя движок, вероятно, делал бы это лучше и быстрее ;-), позволяя по крайней мере, вы должны поддерживать хорошую декомпозицию (так как два серверных процесса взаимодействуют с «процессом хранилища данных»).