我想对实时、近实时和批处理有一个好的定义？我不是在谈论同步和异步，尽管对我来说，它们是不同的维度。这是我的想法
给出每个例子，并随时修正我的假设。
【问题讨论】：
标签： web-services real-time etl batch-processing
所有这些答案都存在问题，因为定义存在缺陷。例如，“批处理”仅仅意味着事务被分组并一起发送。实时意味着事务性，但也可能具有其他含义。因此，当您将批次与实时和接近实时的同一属性结合起来时，该属性的用途就会变得模糊。定义变得不那么连贯，不那么清晰。这将使使用数据创建的任何应用程序更加脆弱。我猜想从业者使用清晰建模的分类法会更好，例如：
Attribute4 与我现在正在做的事情更相关，所以你可以把它扔掉或扩展你想要实现的目标的列表。对于这些属性值中的每一个，可能会有额外的特定属性。但是为了将信息整合在一起，我们需要考虑需要什么才能使集体数据有用。例如，我们需要知道批处理和事务流之间的什么，以使它们一起有用。例如，您可以考虑每个属性以提供了解给定时间段内总吞吐量的能力。我们如何（希望）为我们的业务客户创建概念、逻辑和物理数据模型似乎很有趣，但我们并不总是将这种想法应用于我们在讨论中如何定义术语。
【讨论】：
任何产生输出的时间都是重要的系统。这通常是因为输入对应于物理环境或世界中的某些运动，而输出必须与相同的运动相关。从输入到输出时间的延迟必须足够小，才能达到可接受的时间线。
【讨论】：
我很好奇自己对此的反馈。实时和批处理已经很好地定义并被其他人覆盖（尽管要注意它们是在某些情况下具有非常具体的技术含义的艺术术语）。但是，“近乎实时”对我来说似乎更加模糊。
我喜欢（并且一直在使用）“近实时”来描述一种信号处理系统，该系统平均可以“跟上”，但有时会滞后。想想一个系统处理的事件只是偶尔发生......假设它有足够的缓冲能力并且处理一个事件所花费的时间小于事件之间的平均时间，它可以跟上。
在信号处理上下文中： - 实时似乎意味着在接收到信号后保证以指定（短）延迟完成处理的系统。需要一个最小的缓冲区。 - 近实时（正如我一直在使用的那样）是指接收和处理完成之间的延迟有时会变得相对较大的系统，但系统不会（除非在病态条件下）落后于缓冲区被填满。 - 批处理对我来说意味着后期处理。传入的信号只是被保存（可能需要进行一些实时预处理），然后再进行分析。
这为实时和近实时系统提供了一个很好的框架，在这些系统中，它们（理论上）可以在获取新数据的同时永远运行……处理与获取并行进行。收集完所有数据后进行批处理。
无论如何，我可能会与一些我不知道的技术定义相冲突......我认为如果需要，这里有人会兴高采烈地纠正我。
【讨论】：
https://stackoverflow.com/tags/real-time/info
实时意味着活动完成的时间是其功能正确性的一部分。例如，sqrt() 函数的正确性类似于
实现了 sqrt() 函数 如果对于所有 x >=0，sqrt(x) = y 意味着 y^2 == x。
在此设置中，执行sqrt() 过程所花费的时间不是其功能正确性的一部分。更快的算法在某种定性上可能会更好，但不会或多或少是正确的。
假设我们有一个名为sqrtrt() 的神秘函数，它是平方根的实时版本。例如，想象一下，为了正确执行防抱死制动系统中的下一个制动应用，我们需要计算速度的平方根。在这种情况下，我们可能会说：
实现了sqrtrt()函数 正确如果
- 对于所有 x >=0，
sqrtrt(x)= y 意味着 y^2 == x 和sqrtrt()在
在这种情况下，时间限制不仅仅是一个性能参数。如果sqrtrt() 未能在 275 微秒内完成，则您可能会延迟刹车，从而触发打滑或降低刹车效率，从而可能导致事故。时间限制是例程功能正确性的一部分。将其提升几层，您将获得一个实时系统（至少部分地）由具有作为其功能正确性条件的一部分的及时性的活动组成。
接近实时的系统是这样一种系统，其中活动完成时间、响应能力或根据挂钟时间衡量的感知延迟是系统质量的重要方面。典型的例子是股票报价系统——您希望在价格变化后合理快速地获得报价。对于我们大多数非高速交易者来说，这意味着数据可用与我们看到数据之间的感知延迟可以忽略不计。
“实时”和“近实时”的区别在于精度和幅度上的区别。实时系统具有从微秒到几小时不等的时间限制，但这些时间限制往往相当精确。近实时通常意味着更窄的幅度范围 - 在人类感知容差范围内 - 但通常没有精确表达。
我认为近实时系统可以称为实时系统，但它们的时间限制仅仅是概率性的：
股票价格将在交易所发生变化后的 500 毫秒内显示给用户，其中 概率 p > 0.75。
批处理操作被认为是大块的计算任务，只有宏观的、人为或流程引起的最后期限。计算的具体上下文通常并不重要，批量计算通常是一个独立的计算任务。实时和近实时任务通常与物理世界紧密耦合，它们的时间限制来自物理/现实世界交互的需求。相比之下，批处理操作可以在任何时间、任何地点进行计算；它们的输出仅由定义批次时提供的输入定义。
我会说实时意味着完成操作的时间（而不仅仅是正确的输出）是其正确性的一部分。
Near real-time 是一个狡猾的词，表示想要与实时相同的东西，但不想用纪律/努力/成本来保证它。
批处理是“近乎实时的”，您可以更容忍较长的响应时间。
通常使用这些术语（糟糕的是，恕我直言）来区分人类对延迟/性能的看法。人们认为实时是非常快的，例如毫秒或其他东西。近实时通常是几秒或几毫秒。批处理是几秒钟、几分钟、几小时甚至几天的延迟。但我认为这些并不是特别有用的区别。如果您关心及时性，有一些纪律可以帮助您做到这一点。
【讨论】：