什么定义了实时/近实时系统？答案

【问题标题】：What defines a real-time/near-real time system?什么定义了实时/近实时系统？
【发布时间】：2013-01-18 03:44:50
【问题描述】：

是否存在系统应满足的特定指标才能被视为/分类为实时 Web 应用程序或近实时 Web 应用程序？

当我看到我正在使用的系统的非功能性要求时，该要求指出解决方案应实时/近乎实时地返回数据。我了解这些术语的定义（如 http://en.wikipedia.org/wiki/Near_real-time 所示），但我想知道是否有类似应用程序 UI 的标准（例如：Gnome 建议 http://developer.gnome.org/hig-book/3.5/feedback-response-times.html.en) 期望在 Web 应用程序中接近实时。

这是另一个问题的变体： Define realtime on the web for business

【问题讨论】：

从您链接的维基百科页面，“在某些应用程序中，近实时的延迟可能高达 15 到 20 分钟。”将此与real-time Computing 上的条目进行对比，其中时间延迟约束通常为毫秒或微秒。示例包括防抱死系统和医疗系统。
是的，但是 Web 应用程序中的传输类型和速度表明 Web 应用程序的答案是 > 毫秒和
我认为实时计算的概念很清楚。操作需要“立即”响应，并且不受其他进程的干扰——即，没有其他不稳定的进程在后台运行，并且“实时”进程以恒定的时间运行。正如您链接的文章所指出的那样，接近实时是主观的。如果我不得不猜测，这个词是从某个地方的营销部门开始的。
没有所谓的“实时网络应用程序”。仅网络延迟就意味着这是不可能的。
这篇论文引用了云托管 Web 应用程序的响应时间，似乎表明 4 秒左右的响应时间是可以接受的。这是一个比毫秒或 15 分钟更好的目标google.com/…

标签： real-time requirements

【解决方案1】：

实时计算与性能无关，而是保证事件可以在设定的时间内完成。从 CPU 调度算法到操作系统，再到正在构建的应用程序，实时要求对整个架构都有影响。

根据必须完成操作的时间量来指定实时要求。同样，这必须得到保证，当没有达到最后期限时，系统通常会出现故障（这不是预期的）。

另见What constitutes 'real time'

【讨论】：

谢谢，该链接回答了我的问题，因为业务系统的答案实际上是由业务用户在系统及其架构的约束范围内定义的。我的应用程序在与您的链接问题的答案中的银行应用程序相同的上下文中是实时的。
添加任何参考书/文章/文档对进一步学习有很大帮助。

【解决方案2】：

在高层（相当抽象）：

http://cs.brown.edu/~ugur/8rulesSigRec.pdf

在底层，基本上是指（无论是硬件还是软件）：

一个。无缓存：软件缓存、硬件缓存等。

b.没有指令流水线：这仅仅是因为在每个分支点可能不得不丢弃大量执行的指令，从而导致不确定性。

c。没有异步机制（例如，中断）。尽可能使用轮询。这是因为在中断机制中，我们不确定事件何时发生。

d。高度基于时钟或时钟触发的机制：这通常意味着在硬件内部分配时钟信号的复杂方式（查找“时钟树合成”）。

e。我以前用过 LynxOS RTOS。它在处理过程中具有很高的响应性和可预测性。但是如果你看一下它的内部，你会发现它跳过了很多不太可能发生的事件错误处理——特别是如果它是硬件资源（例如，内存）。所以总是假设内存是可用的——仅仅因为它在整个设计中的阈值很低——以确保很少达到最大限制。当然，当您将数字推到极限时（例如，产生大量进程），LynxOS 的实时行为就不再表现出来了。

【讨论】：

【解决方案3】：

在业务需求文档中看到时，应考虑应用程序的技术性质。上下文有助于确定需求是真正的real-time、web real-time，还是接近实时的意思，只要处理允许，无需等待计划/批处理过程（例如，trickle feed 数据而不是每 15 分钟加载一次数据）。

据 SignalR 的开发者称，这是the ability to have your server-side code push content to the connected clients as it happens, in real-time.

【讨论】：