实时分布式系统的基本要素是什么？

Question

我正在接受合同，今天我已经接受了承包商职位的第一轮面试。我已经通过了它，但我被告知 - 主要是一个UI开发人员 - 我只介绍了他们后端需要的基础知识，我应该在第二轮之前阅读分布式系统。

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

问题是如何在用户界面上实时显示数据？后端需要做什么？我已经提到了实时数据馈送的生产者/消费者模式。他很喜欢，但他说他在第二次面试时需要更多。

任何帮助都会非常感激，

Answer 1

分布式实时系统的基本要素是什么？

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

分布式

分布式系统通过通信机制将许多独立计算实体与本地属性相链接。因此，算法和其他设计组件必须考虑同步和故障模型。 Deutsch的{​​{3}}中包含了分布式计算问题的有用摘要（不完全客观）。 （参见Eight Fallacies of Distributed Computing。）所有这些在（实时）分布式设计中都很有用;每个都是基本设计和实施问题的出发点：

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

实时

实时系统是一个系统，其中操作完成的及时性是系统的功能要求和正确性度量的一部分。 （我开了一个this useful exposition来试图澄清这一点。）实际上，几乎所有的系统都可能被认为是“软”实时的，因为通常对操作的及时性有未说出的要求/期望。我们保留实时字词，有时符合 soft 或 hard ，适用于时间不正确的系统不满足约束。请注意，上述谬误中总结的许多问题与及时性相关。 （另见SO question here）

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

使用实时编写分布式

• 明确的及时性要求 - 有哪些要求，它们如何映射到活动，它们是真正的跨节点及时性要求，如何在设计和实施中明确表示时间约束，以及如何检测故障，报告，并恢复？
• 时间同步 - 实现时钟同步的要求和机制是什么？ Wiki real-time tag wiki;许多应用程序只需要clock synchronization;更严格的要求可能需要特殊硬件（例如NTP）或方法。
• 同步要求 - 系统同步的同步假设约束和要求是什么？这与时钟同步相关，但不完全相同。一些IRIG-B;维基百科thoughts on formal models from Doug Jensen和Asynchronous System; Synchronous;
• 设计模式 - 什么是运动部件，它们如何与运输相关？ （特别是，这些关系如何影响及时性？）
• 中间件 - 您打算如何编码系统的分布式方面？示例包括实时CORBA（此处为SO question on partial event ordering）或good page from OIS。
• 时间限制 - 您如何在系统中记录，衡量和执行时间限制？
• 部分失败 - 实时系统通常具有可靠性要求。分布式系统的一个独特方面是由于真正的崩溃/通信故障或必须被视为故障的及时性错误而导致称为“部分”故障的整类故障的可能性。 DDS;
• RTOS - 将采用哪些实时操作系统？

一些参考文献

对于相当传统的DRT系统演示，请查看SO question on failover approaches。对于更加动态的观点，Jensen的工作和Kopetz' book。在Java领域，我建议阅读优秀的his website are recommended。它没有解决时效性问题的全部领域，但确实以一种特别明确的方式解决了部分失败。

最近，（不可靠）故障检测器的概念已经成为一种有用的同步结构，能够为DRT系统提供有用的理论推理和实用的配方/设计/构造技术。关于这个主题的开创性论文是"Introduction to Reliable Distributed Programming"，由Aguilera，Le Lann和Toueg撰写。本文是沉重的雪橇，但奖励每一盎司的智力投资。

Answer 2

从高端开始，有两种从后端到前端获取实时数据的基本方法：

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

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

这只是当然的出发点。可以使用这两种方法，可以在客户端上缓存数据等。这完全取决于应用程序的需求。