31

我开始涉足承包工作，今天我进行了承包商职位的第一轮面试。我已经通过了，但有人告诉我——主要是一名 UI 开发人员——我只介绍了他们后端所需的基础知识，我应该在第二轮之前阅读分布式系统。

到目前为止，在我的职业生涯中，我一直从事后期操作，从不需要实时。由于我只剩下几天了，我需要涵盖哪些主题？首先能够回答他的问题并且通常被认为在分布式系统中就足够了？

问题是如何在您的 UI 上近乎实时地显示数据？后端需要做什么？我已经提到了实时数据馈送的生产者/消费者模式。他喜欢它，但他说他在第二次采访时需要更多。

任何帮助将非常感激，

4

2 回答 2

44

分布式实时系统的本质是什么？

分布式实时系统由问题域或解决方案域（或两者）强加的两组具有挑战性的属性组成。

分散式

分布式系统通过通信机制将多个具有本地属性的独立计算实体联系起来。因此，算法和其他设计组件必须考虑同步和故障模型。Deutsch 的分布式计算的八个谬误中包含了对分布式计算问题的有用总结（并非完全客观）。（请参阅这个有用的说明。）所有这些都有助于在（实时）分布式设计中考虑；每个都是基本设计和实施问题的出发点：

  1. 网络可靠
  2. 延迟为零
  3. 带宽是无限的
  4. 网络很安全
  5. 拓扑不变
  6. 有一名管理员
  7. 运输成本为零
  8. 网络是同质的

即时的

实时系统是将操作完成的及时性作为系统功能要求和正确性度量的一部分的系统。（我在这里打开了一个 SO 问题试图澄清这一点。）实际上，几乎所有系统都可能被认为是“软”实时的，因为通常对操作的及时性有不言而喻的要求/期望。我们保留实时术语，有时由软或硬限定，用于在不满足时间限制时不正确的系统。请注意，上述谬误中总结的许多问题都与及时性相交。（另见实时标签维基）

值得注意的是，RT（和 DRT）系统存在于一系列需求中，其中一个极端是“确定性”（或传统上是硬实时）。然而，许多系统具有非常重要的时间限制，但这些限制仍然是非确定性的。特别是在 DRT 系统的上下文中，将活动紧迫性的概念与活动优先级分开也是有用的。在延迟和故障是真实且重要的因素的大型系统中，计算和通信资源的显式管理以影响及时性和其他设计要求变得更加重要，这两个维度的分离变得重要。

实时创作分布式

  • 明确的及时性要求——要求是什么，它们如何映射到活动，它们是否真正的跨节点及时性要求，时间约束将如何在设计和实现中明确表示，以及如何检测、报告和恢复故障?
  • 时间同步——实现时钟同步的要求和机制是什么？关于时钟同步的维基；许多应用程序只需要NTP；更严格的要求可能需要特殊的硬件（例如IRIG-B）或方法。
  • 同步要求——系统同步的同步假设约束和要求是什么？这与时钟同步有关，但不相同。Doug Jensen 对形式模型的一些思考；关于异步系统和同步的维基百科；SO关于部分事件排序的问题；
  • 设计模式——什么是移动部件，它们在传输过程中是如何关联的？（特别是，这些关系如何影响及时性？）
  • 中间件——你将如何编码系统的分布式方面？示例包括 Real-Time CORBA（这是OIS 的一个很好的页面）或DDS。
  • 时间限制——您将如何在系统中记录、衡量和实施时间限制？
  • 部分故障——实时系统通常具有可靠性要求。分布式系统的独特方面之一是可能出现被称为“部分”故障的整类故障，这可能是由于真正的崩溃/通信故障或必须被视为故障的及时性错误。 SO关于故障转移方法的问题；
  • RTOS——将采用什么实时操作系统？

几个参考

有关 DRT 系统的相当传统的介绍，请查看Kopetz 的书。要获得更动态的视图，推荐 Jensen 的作品和他的网站。在 Java 领域，我建议阅读出色的“可靠分布式编程简介”。它没有解决及时性问题的全部领域，但确实以一种特别清晰的方式解决了部分故障。

最近，（不可靠的）故障检测器的概念已经成为一种有用的同步构造，为 DRT 系统提供有用的理论推理和实用的制定/设计/构造技术。关于该主题的开创性论文是关于快速故障检测器对实时容错系统的影响，作者是 Aguilera、Le Lann 和 Toueg。这篇论文是沉重的雪橇，但奖励每一盎司的智力投资。

于 2011-02-27T06:15:14.927 回答
1

概括地说，有两种从后端到前端获取实时数据的基本方法：

  • 推送：您可以通过发送消息将数据“推送”到客户端。我过去曾使用它向客户端发送进程间消息，以提醒 UI 发生了更新。这是传输信息的最快方式，但也有一些复杂性。例如，除非您使用 Flash、Silverlight 等，否则您（还）不能将 IPC 消息发送到 Web 应用程序。此外，您需要限制这些消息，因为如果发送太多，它会降低您的 UI 响应速度。这里要研究的一些技术是 MSMQ、TCP/IP 和 WCF 等效技术。

  • 拉取：您的 UI 可以定期从后端请求数据。这种方法的优点是很容易在 UI 上编写代码：只需每隔 X 轮询一个数据源。当然，明显的缺点是在发生更新和应用程序接收到该更新之间存在延迟。这对于实时处理可能是不可接受的。无论如何，在此模型中，您可能会调用 Web 服务或调用数据库。

这当然只是起点。这两种方法都可以使用，数据可以缓存在客户端等。这一切都取决于应用程序的需要。

于 2011-02-16T17:03:38.543 回答