В чем суть распределенных систем реального времени?

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

До сих пор в моей карьере я работал в почтовых операциях, где в реальном времени никогда не было необходимости. Поскольку у меня осталось всего несколько дней, какие темы необходимы для покрытия? Во-первых, чтобы ответить на его вопрос и в целом восприниматься как адекватное в распределенных системах?

Вопрос заключается в том, как показывать данные в реальном времени в пользовательском интерфейсе? Что нужно сделать на бэкэнд? Я упомянул образец производителя/потребителя для фида данных в реальном времени. Ему понравилось, но он сказал, что ему нужно больше на втором интервью.

Любая помощь будет действительно оценена,

Ответ 1

В чем суть распределенных систем реального времени?

Распределенная система реального времени состоит из двух сложных наборов свойств, которые налагаются предметной областью или областью решения (или и тем и другим).

Распределенные

A распределенная система связывает ряд независимых вычислительных объектов с локальными свойствами посредством механизма связи. Как следствие, алгоритмы и другие компоненты дизайна должны учитывать модель синхронизация и . Полезное резюме (не полностью объективное) проблем с распределенными вычислениями включено в Deutsch Восемь ошибок в распределенных вычислениях. (См. это полезное изложение.) Все это полезно рассмотреть в распределенном проекте (в режиме реального времени); каждая из них является отправной точкой для существенных проблем проектирования и реализации:

Сеть надежна
Задержка равна нулю
Полоса пропускания бесконечна
Сеть защищена
Топология не изменяется
Существует один администратор
Стоимость транспортировки равна нулю
Сеть является однородной.

Real-Time

A система реального времени - это система, в которой своевременность завершения операции является частью функциональных требований и мера корректности системы. (Я открыл здесь SO вопрос, чтобы попытаться это прояснить.) На самом деле почти все системы можно считать "мягкими" в режиме реального времени, так как обычно нет невысказанных требования/ожидания для своевременности операций. Мы резервируем термин в режиме реального времени, иногда квалифицируемый мягким или жестким, для систем, которые являются неправильными, когда ограничения по времени не выполняются. Обратите внимание, что многие из проблем, суммированных в заблуждениях выше, пересекаются с своевременностью. (См. Также вики-метки в реальном времени)

Полезно отметить, что системы RT (и DRT) существуют в континууме требований с "детерминированным" (или условно, жестким реальным временем) с одной стороны. Однако множество систем имеют очень важные временные ограничения, которые, тем не менее, не детерминированы. Особенно в контексте DRT-систем также полезно отделить концепцию активности срочность от приоритета . В больших системах, где задержка и отказ являются реальными и нетривиальными факторами, явное управление вычислительными и коммуникационными ресурсами для обеспечения своевременности и других требований к проектированию становится более важным, и разделение этих двух измерений становится важным.

Композиция, распределенная с помощью реального времени

Явные требования к срочности -— Каковы требования, как они сопоставляются с действиями, являются ли они истинными требованиями к своевременности, как будут отображаться временные ограничения явно в дизайне и реализации, и как выявить, сообщить и восстановить ошибки?
Синхронизация времени — Каковы требования и механизмы для синхронизации часов? Wiki на синхронизация часов; для многих приложений требуется только NTP; более жесткие требования могут потребовать специального оборудования (например, IRIG-B) или подходов.
Требования к синхронности — Каковы ограничения синхронных допущений и требования к системной синхронизации? Это связано с синхронизацией часов, но не идентично. Некоторые мысли о формальных моделях от Doug Jensen; wikipedia on Асинхронная система и Synchronous; SO вопрос о частичном упорядочении событий;
Дизайн шаблонов — Каковы движущиеся части и как они связаны с транспортом? (В частности, как эти отношения влияют на своевременность?)
Middleware — Как вы собираетесь кодировать распределенные аспекты системы? Примеры включают CORBA реального времени (здесь хорошая страница из OIS) или ДДС.
Ограничения времени — Как вы собираетесь документировать, измерять и применять ограничения по времени в системе?
Частичная ошибка /mdash; Система реального времени обычно имеет требования к надежности. Один из уникальных аспектов распределенных систем - это потенциал для целых классов отказов, называемых "частичными" отказами, из-за истинных сбоев при сбоях/сбоях или ошибок времени, которые должны рассматриваться как сбои. SO вопрос об отказоустойчивых подходах;
RTOS — Какие операционные системы в режиме реального времени будут использоваться?

Несколько ссылок

Для довольно традиционной презентации DRT-систем взгляните на книгу Kopetz. Для более динамичного просмотра работа Дженсена и рекомендуется его веб-сайт. В области Java я предлагаю прочитать отличный "Введение в надежное распределенное программирование" . Он не затрагивает все вопросы, связанные с своевременностью, но особенно четко указывает на частичный сбой.

В последнее время концепция (ненадежных) детекторов отказа появилась как полезная синхронная конструкция, позволяющая использовать полезные теоретические рассуждения и практические методы разработки/проектирования/построения систем DRT. Основная статья по теме О влиянии быстрых детекторов отказов на отказоустойчивые системы в режиме реального времени, Агилера, Ле Ланн и Toueg. Эта статья - тяжелые санки, но вознаграждает каждую унцию интеллектуальных инвестиций.

Ответ 2

На высоком уровне доступны два основных способа получения данных в реальном времени из внутреннего интерфейса:

Push: вы можете "нажимать" данные клиенту, отправляя сообщения. Я использовал это в прошлом для отправки межпроцессных сообщений клиенту, чтобы предупредить пользовательский интерфейс о том, что обновление произошло. Это самый быстрый способ передачи информации, но есть осложнения. Например, вы не можете (пока) отправлять сообщения IPC в веб-приложение, если не используете Flash, Silverlight и т.д. Кроме того, вам необходимо отключить эти сообщения, потому что если вы отправляете слишком много, это может сделать ваш интерфейс менее отзывчивым. Некоторые технологии для изучения здесь - это MSMQ, TCP/IP и эквиваленты WCF.
Pull: ваш пользовательский интерфейс может периодически запрашивать данные из внешнего сервера. Преимущество этого метода состоит в том, что его легко кодировать в пользовательском интерфейсе: просто опросите источник данных каждый X. Но, конечно, очевидным недостатком является то, что существует отставание между тем, когда происходит обновление, и когда ваше приложение получает это обновление. Это может быть неприемлемо для обработки в реальном времени. Во всяком случае, в этой модели вы можете позвонить в веб-службу или позвонить в базу данных.

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