我开始涉足承包工作，今天已经完成了承包商职位的第一轮面试。我已经通过了，但有人告诉我——我主要是一名 UI 开发人员——我只介绍了他们后端所需的基础知识，我应该在第二轮之前阅读分布式系统。
到目前为止，在我的职业生涯中，我一直从事后期操作，而这从不需要实时。 由于我只剩下几天了，我需要涵盖哪些主题？首先能够回答他的问题并且通常被认为在分布式系统中就足够了？
问题是如何在您的 UI 上近乎实时地显示数据？后端需要做什么？我已经提到了实时数据馈送的生产者/消费者模式。他喜欢它，但他说他在第二次采访时需要更多。
任何帮助将不胜感激，
【问题讨论】：
标签： real-time distributed distributed-computing distributed-system
分布式实时系统由问题域或解决方案域（或两者）强加的两组具有挑战性的属性组成。
分布式系统通过通信机制将多个具有本地属性的独立计算实体联系起来。因此，算法和其他设计组件必须考虑同步和故障模型。 Deutsch 的Eight Fallacies of Distributed Computing 中包含了分布式计算问题的有用总结（并非完全客观）。 （参见this useful exposition。）在（实时）分布式设计中考虑所有这些都是有用的；每个都是基本设计和实施问题的出发点：
实时系统是一个系统，其中操作完成的及时性是系统功能要求和正确性度量的一部分。 （我打开了SO question here 试图澄清这一点。）实际上，几乎所有系统都可能被认为是“软”实时的，因为通常对操作的及时性有不言而喻的要求/期望。我们保留 实时 术语，有时由 soft 或 hard 限定，用于在时间时不正确的系统不满足约束条件。请注意，上述谬误中总结的许多问题都与及时性相交。 （另见real-time tag wiki）
请注意，RT（和 DRT）系统存在于一系列需求中，其中一个极端是“确定性”（或传统上，硬实时）。然而，许多系统具有非常重要的时间限制，但这些限制仍然是非确定性的。特别是在 DRT 系统的上下文中，将活动 紧急度 的概念与活动 优先级 分开也是有用的。在延迟和故障是真实且重要的因素的大型系统中，显式管理计算和通信资源以影响及时性和其他设计要求变得更加重要，这两个维度的分离变得重要。
有关 DRT 系统的相当传统的介绍，请查看 Kopetz' book。要获得更动态的视图，请查看 Jensen 的工作和 his website are recommended。在 Java 领域，我建议阅读优秀的 "Introduction to Reliable Distributed Programming"。它没有解决及时性问题的全部领域，但确实以一种特别清晰的方式解决了部分故障。
最近，（不可靠的）故障检测器的概念已成为一种有用的同步构造，为 DRT 系统提供有用的理论推理和实用的制定/设计/构造技术。关于该主题的开创性论文是 On the impact of fast failure detectors on real-time fault-tolerant systems，作者是 Aguilera、Le Lann 和 Toueg。这篇论文是沉重的雪橇，但奖励每一盎司的智力投资。
【讨论】：
概括地说，有两种从后端到前端获取实时数据的基本方法：
推送：您可以通过发送消息将数据“推送”到客户端。我过去曾使用它向客户端发送进程间消息，以提醒 UI 发生了更新。这是传输信息的最快方式，但也有一些复杂性。例如，除非您使用 Flash、Silverlight 等，否则您（目前）不能将 IPC 消息发送到 Web 应用程序。此外，您需要限制这些消息，因为如果发送过多，可能会使您的 UI 响应速度变慢。这里要研究的一些技术是 MSMQ、TCP/IP 和 WCF 等效技术。
Pull：您的 UI 可以定期从后端请求数据。这种方法的优点是很容易在 UI 上编写代码：只需每隔 X 轮询一个数据源。当然，明显的缺点是在发生更新和应用程序接收到该更新之间存在延迟。这对于实时处理可能是不可接受的。无论如何，在此模型中，您可能会调用 Web 服务或调用数据库。
这当然只是起点。两种方式都可以使用，数据可以缓存在客户端等等。这一切都取决于应用程序的需要。
【讨论】：