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

Question

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

到目前为止，在我的职业生涯中，我一直在post操作中工作，那里从来不需要实时。由于我只剩下几天的时间，我需要介绍哪些主题？首先能够回答他的问题，并且在分布式系统中通常被认为是足够的？

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

任何帮助都将不胜感激，

Answer 1

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

分布式实时系统由两组具有挑战性的属性组成，这两组属性是由问题域或解域(或两者)强加的。

分布式

分布式系统通过通信机制将多个具有本地属性的独立计算实体链接在一起。因此，算法和其他设计组件必须考虑同步和故障模型。Deutsch的Eight Fallacies of Distributed Computing中包含了分布式计算问题的有用摘要(并非完全客观)。(请参阅this useful exposition。)在(实时)分布式设计中，所有这些都是有用的；每一个都是基本设计和实现问题的出发点：

网络开销为零网络为reliable

• Latency is zero

• Bandwidth is

• is secure

• Topology‘t

• There one administrator

• Transport is

2. 网络为同构

<代码>G225

实时

实时系统是指操作完成的及时性是系统功能需求和正确性度量的一部分。(我打开了一个SO question here，试图澄清这一点。)在现实中，几乎所有的系统都可能被认为是“软”实时的，因为通常对操作的及时性有未言明的要求/期望。我们保留实时术语，有时由soft或hard限定，用于不满足时间限制时不正确的系统。请注意，上面的谬误中总结的许多问题都与及时性相交。(另请参阅real-time tag wiki)

值得注意的是，RT (和DRT)系统存在于需求的连续体上，其中一个极端是“确定性”(或传统上称为硬实时)。然而，许多系统都有非常重要的时间约束，但这些时间约束仍然是不确定的。特别是在DRT系统的上下文中，将活动优先级优先级( activity priority)与活动优先级优先级( activity priority )的概念分开也是有用的。在延迟和故障是真实和非微不足道因素的大型系统中，显式管理计算和通信资源以影响及时性和其他设计需求变得更加重要，并且这两个维度的分离变得重要。

用实时构建分布式应用

• 明确的时效性要求-什么是要求，它们如何映射到活动，它们是否真的是跨节点的时效性要求，时间约束将如何在设计和实施中明确表示，以及如何检测、报告和recovered?
• Time同步故障-实现时钟同步的要求和机制是什么？clock synchronization上的approaches.
• Synchrony；许多应用程序只需要NTP；更严格的要求可能需要特殊的硬件(例如，IRIG-B)或Wiki要求-同步假设约束和系统同步要求是什么？这与时钟同步有关，但并不完全相同。一些thoughts on formal models from Doug Jensen；关于Asynchronous System和Synchronous的维基百科；SO question on partial event ordering；
• 设计模式-移动的部分是什么，它们在传输上是如何联系的？(特别是，这些关系如何影响timeliness?)
• Middleware -您将如何编码系统的分布式方面？示例包括Real-Time CORBA (这里是good page from OIS)或DDS.
• Time约束-如何在system?
• Partial故障中记录、测量和实施时间约束-实时系统通常具有可靠性要求。分布式系统的一个独特方面是，由于真正的崩溃/通信故障或必须被视为故障的及时性错误，整个类别的故障称为“部分”故障的可能性。SO question on failover approaches;
• RTOS -将采用什么实时操作系统？

几个参考资料

对于一个相当传统的DRT系统的演示，可以看看Kopetz' book。有关更动态的视图，请参阅Jensen的工作和his website are recommended。在Java界，我建议阅读优秀的"Introduction to Reliable Distributed Programming"。它没有解决整个领域的时效性问题，但确实以一种特别清晰的方式解决了部分失败。

最近，(不可靠的)故障检测器的概念已经作为一种有用的同步构造出现，使得用于DRT系统的有用的理论推理和实用的公式/设计/构造技术成为可能。关于这个主题的开创性论文是阿奎莱拉、勒兰和图伊格写的。这篇论文是沉重的，但回报每一盎司的智力投资。

Answer 2

从高层次上讲，有两种将实时数据从后端获取到前端的基本方法：

• Push:您可以通过发送消息的方式将数据“推送”到客户端。在过去，我曾使用它向客户端发送进程间消息，以警告UI发生了更新。这是传输信息的最快方式，但也有一些复杂之处。例如，除非您使用Flash、Silverlight等，否则您不能(目前)向web应用程序发送IPC消息。此外，您还需要限制这些消息，因为如果您发送太多消息，可能会使您的UI响应性降低。这里要介绍的一些技术包括MSMQ、TCP/IP和WCF equivalents.
• Pull：，您的UI可以定期从后端请求数据。这种方法的优点是很容易在UI上编码:只需每隔X轮询一次数据源。但当然，明显的缺点是在更新发生时和应用程序接收更新时之间存在延迟。这对于实时处理来说可能是不可接受的。无论如何，在此模型中，您可以调用web服务或调用数据库。

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