Каковы основы распределенных систем реального времени?
Я получаю свою ногу в контракте и сегодня у меня было мое первое собеседование на должность подрядчика. Я прошел его, однако мне сказали-будучи в основном разработчиком пользовательского интерфейса - я только охватил основы того, что им нужно для их бэкэнда, и я должен прочитать о распределенных системах до второго раунда.
до сих пор в моей карьере я работал в почтовых операциях, где в реальном времени никогда не было необходимости. Поскольку у меня осталось всего несколько дней, какие темы мне нужны для покрытия? Во-первых, чтобы иметь возможность ответить на его вопрос и в целом рассматриваться как адекватный в распределенных системах?
вопрос был в том, как показать данные в реальном времени на вашем пользовательском интерфейсе? Что нужно сделать на бэкэнде? Я упомянул шаблон производителя / потребителя для подачи данных в реальном времени. Ему понравилось, но он сказал, что ему нужно больше на втором интервью.
любая помощь будет действительно оценили,
2 ответов
каковы основы распределенных систем реального времени?
распределенная система реального времени состоит из двух сложных наборов свойств, которые накладываются доменом задачи или доменом решения (или оба.)
распределенные
A распределенные система связывает ряд независимых вычислительных объектов с локальными свойствами посредством механизма связи. Как следствие, алгоритмы и другие компоненты конструкции должны взять с учетом синхронность и модели неисправности. Полезное резюме (не совсем объективное) проблем распределенных вычислений включено в Deutsch восемь ошибок распределенных вычислений. (См.это полезная экспозиция.) Все они полезны для рассмотрения в распределенном дизайне (в режиме реального времени); каждый из них является отправной точкой для основных проблем проектирования и реализации:
- сеть надежный
- задержка равна нулю
- пропускная способность бесконечна
- сеть защищена
- топология не меняется
- есть один администратор
- транспортные расходы равны нулю
- сеть однородна
В Режиме Реального Времени
A в режиме реального времени система-это система, в которой своевременность завершения операции является частью функциональных требований и мера корректности системы. (Я открыл так вот вопрос чтобы попытаться прояснить это.) В действительности почти все системы можно считать "мягкими" в режиме реального времени, поскольку обычно существуют невысказанные требования/ожидания в отношении своевременности операций. Мы резервируем в режиме реального времени термин, иногда квалифицированы софт или жесткий, для систем неправильно когда ограничения по времени не выполнены. Обратите внимание, что многие из проблемы, обобщенные в приведенных выше заблуждениях, пересекаются со своевременностью. (См. также в режиме реального времени тег wiki)
полезно отметить, что системы RT (и DRT) существуют на континууме требований, с "детерминированным" (или условно,жесткий в режиме реального времени) на одном полюсе. Однако многие системы имеют очень важные временные ограничения, которые, тем не менее, недетерминированы. Особенно в контексте систем DRT, также полезно отделить понятие деятельности актуальность активность приоритет. В крупных системах, где задержки и сбои являются реальными и нетривиальными факторами, явное управление вычислительными и коммуникационными ресурсами для обеспечения своевременности и выполнения других требований к проектированию становится более важным, и разделение этих двух измерений становится важным.
сочинение распространяется в режиме реального времени
- явные требования к своевременности-каковы требования, как они сопоставляются с действиями, являются ли они истинными требованиями к своевременности перехода через узел, как ограничения по времени будут явно представлены в дизайне и реализациях и как будут обнаружены, сообщены и восстановлены сбои?
- синхронизация времени - каковы требования и механизмы для достижения синхронности часов? Wiki on синхронизация; многие приложения требуют только NTP; подробнее строгие требования могут потребовать специального оборудования (например, IRIG-B) или подходов.
- требования к синхронизации - каковы ограничивающие допущения синхронизации и требования к системной синхронизации? Это связано с синхронизацией часов, но не идентично. Некоторые мысли о формальных моделях от Дуга Дженсена; Википедия о Асинхронная Система и синхронно; поэтому вопрос о частичной заказ событий;
- шаблоны проектирования - каковы движущиеся части и как они связаны с транспортом? (В частности, как эти взаимосвязи влияют на своевременность?)
- промежуточное ПО - как вы собираетесь кодировать распределенные аспекты системы? Примеры включают в себя в режиме реального времени CORBA (вот хорошая страница из OIS) или DDS.
- Ограничения По Времени - Как вы собираетесь документировать, измерять и применять временные ограничения в системе?
- Частичный Отказ - система реального времени обычно имеет требования к надежности. Одним из уникальных аспектов распределенных систем является потенциал для целых классов сбоев, называемых "частичными" сбоями, из-за истинных сбоев сбоев/сбоев связи или ошибок своевременности, которые должны рассматриваться как сбои. Итак, вопрос об отказоустойчивости подходы;
- RTOS - какая операционная система(ы) в реальном времени будет использоваться?
несколько ссылок
для довольно традиционной презентации систем DRT взгляните на Kopetz книги. Для более динамичного просмотра, работа Дженсена и его веб-сайт рекомендуется. В области Java, я предлагаю прочитать отличную "введение в надежное распределенное Программирование". В нем не рассматривается в полной мере проблема своевременности, но особенно четко рассматриваются частичные сбои.
в последнее время концепция (ненадежных) детекторов отказов появилась как полезная конструкция синхронизации, позволяющая полезные теоретические рассуждения и практические методы формулирования/проектирования/строительства для систем DRT. Основополагающим документом по этой теме является о влиянии быстрых детекторов отказа на отказоустойчивых системах в реальном времени, на Орбакайте, Ле Ланн и Toueg. Эта статья-тяжелая работа, но она вознаграждает каждую унцию интеллектуальных инвестиций.
на высоком уровне есть два основных способа получения данных в режиме реального времени от бэк-энда до фронт-энда:
Push: вы можете "толкать" данные клиенту, отправляя сообщения. Я использовал это в прошлом для отправки сообщений между процессами клиенту, чтобы предупредить пользовательский интерфейс о возникновении обновления. Это самый быстрый способ передачи информации, но есть осложнения. Например, вы не можете (пока) отправлять сообщения IPC в веб-приложение, если не используете Flash, Silverlight, etc. А также, вам нужно дросселировать эти сообщения, потому что если вы отправляете слишком много, это может сделать ваш пользовательский интерфейс менее отзывчивым. Некоторые технологии для изучения здесь-MSMQ, TCP / IP и эквиваленты WCF.
Pull: ваш пользовательский интерфейс может периодически запрашивать данные из бэк-энда. Преимущество этого метода заключается в том, что его легко закодировать в пользовательском интерфейсе: просто опросите источник данных каждый X. Но, конечно, очевидный недостаток заключается в том, что существует задержка между обновлением и когда ваше приложение получит это обновление. Это может быть неприемлемо для обработки в реальном времени. В любом случае, в этой модели вы можете позвонить в веб-службу или сделать вызов в базу данных.
Это только отправная точка, конечно. Оба метода могут быть использованы, данные могут быть кэшированы на клиенте, и т. д. Все зависит от потребностей приложения.