php - 使用MySQL和套接字消息队列是否被视为实时系统？

Question

我正在使用PHP和ratchet，正在处理如何从服务器端创建事件并将其推送到客户端的问题。

我知道我可以使用ZeroMQ，但这也会产生开销，每次必须通知事件时，都会建立一个新的套接字连接。

所以我想知道，拥有一个始终使用内存作为引擎从名为“ MySQL”的SocketQueue表中进行选择的线程会更好吗？

这种架构是否会使应用失去“实时”属性？

Answer 1

让我们先跳过营销术语，然后专注于严格的系统设计

尽管人们可以读取很多标签，例如实时，超快速，低延迟，但这些标签并不相同，在严格的系统设计决策中其重要性也相差很大。

快速

是的，速度是很不错的功能，但并非总能以合理的成本实现，或者始终保证包括生产生态系统中的最坏情况在内都能得到统一保证。因此，“快速”会有所帮助，但并不是实时系统设计的基石。

低延迟

此处同样适用，延迟是审查交易必须支付的主要成本。同样，如果延迟规模不是先天破坏系统设计的，那么很好，但是一旦原理上可行，实时系统设计将重点放在延迟抖动上，而不是在延迟值本身上，如我们必须与现实相处，并且必须证明该系统能够牢固地处理所有各种延迟级别，并将其作为生产生态系统现实不可分割的一部分。

即时的

好吧，如果一个系统具有这样的特性，则该系统可以被称为实时系统，即该设计已通过严格的先验证明进行了交叉验证，即在所有可能的情况下，实时执行调度都可以可靠地满足给定的内部时间范围，在该范围内，系统可以肯定其所有内部处理子任务“始终处于及时状态”的能力。


  如果以上半定义中的任何一项都不存在-是的：-R / T设计内部调度时间范围-R / T设计验证-R / T设计在“始终保持及时”状态下的鲁棒性的积极证据上述努力中的条件不能严格实时，也不能拥有“实时”属性


细心的读者已经注意到，实时性规则并未说明内部调度时间水平将持续多长时间。

是的，实时系统可以设计并可靠地证明其能力在1 [us]或1 [ms]或1 [s]或1 [min]或1 [hour]的范围内稳健地满足所有子任务，而在所有情况下，实时执行都被视为严格的实时系统。

计划约一个小时的实时系统是否还有某些原因？当然，它们已经并且是相当普遍的设计目标，想象一下通过一条链路协调的地球/深空卫星无线电上行链路和地面控制站的操作，这需要几个小时才能在此处获取并返回任何遥测/控制数据。

是的，不是所有现实世界的流程都可以在如此长的调度范围内生存，并且需要在距Nyquist稳定性标准的安全距离上具有此阈值，因为受控流程为稳定（即鲁棒）控制施加了一些其他条件。

同时，要到达实时调度范围的另一端，太紧的调度时间范围不需要保存项目，因为设计必须适合所有实际硬件的材料约束（没有人可以发送）信号的速度快于光速（并且忘记了量子缠结，即使这样做也无法为您省钱），功耗限制，并且在经济上仍然可行，包括系统设计，编程和验证的成本。

足够扩展是必须的

返回草绘的组件。

ZeroMQ应该被视为相当持久的通信+信令层。我的分布式系统应用程序使用ZeroMQ并从此方法中受益，并在适当的照顾下提供合理的服务，甚至可以减少数十个[us]调度框架。

临时设置ZeroMQ套接字的任何尝试都是不可行的，因为设置开销与实时设计意图不符。一旦启动系统并执行自诊断任务，在将整个生态系统以R / T模式声明为RTO之前，这是设置这些先验条件的必要工程实践。

您的[messaging + signalling]层设计不需要外部依赖任何MySQL表来决定消息/信号分配的正确路由。可能需要花费更长的时间处理ZeroMQ内部问题，但这是ZeroMQ专业化技术的最强大功能之一。

为了实现实时操作模式，ZeroMQ不依赖于任何Message-Broker实体，这会使您的实时设计再度陷入噩梦，因为您的设计对此没有任何工具/控件（消息/信令层的核心）元素，而您的子任务都完全依赖于Broker介导的消息/信号传递的平稳，足够长的延迟。

MySQL引擎在“始终保持及时”方面的差异最大。期望在提供合理的一组非传统编程方法方面进行大量的工程工作，以承担积极证明子任务调度的鲁棒性的责任。