有什么建议、建议或推荐阅读吗？
如果我可以在几十年的架构和设计推理实践经验后加几分钱：
始终对自己保持现实和诚实：
0.1 ns - NOP
0.3 ns - XOR, ADD, SUB
0.5 ns - CPU L1 dCACHE reference (1st introduced in late 80-ies )
0.9 ns - JMP SHORT
1 ns - speed-of-light (a photon) travel a 1 ft (30.5cm) distance -- will stay, throughout any foreseeable future :o)
3~4 ns - CPU L2 CACHE reference (2020/Q1)
5 ns - CPU L1 iCACHE Branch mispredict
7 ns - CPU L2 CACHE reference
10 ns - DIV
19 ns - CPU L3 CACHE reference (2020/Q1 considered slow on 28c Skylake)
71 ns - CPU cross-QPI/NUMA best case on XEON E5-46*
100 ns - MUTEX lock/unlock
100 ns - own DDR MEMORY reference
135 ns - CPU cross-QPI/NUMA best case on XEON E7-*
202 ns - CPU cross-QPI/NUMA worst case on XEON E7-*
325 ns - CPU cross-QPI/NUMA worst case on XEON E5-46*
10,000 ns - Compress 1K bytes with Zippy PROCESS
20,000 ns - Send 2K bytes over 1 Gbps NETWORK
250,000 ns - Read 1 MB sequentially from MEMORY
500,000 ns - Round trip within a same DataCenter
10,000,000 ns - DISK seek
10,000,000 ns - Read 1 MB sequentially from NETWORK
30,000,000 ns - Read 1 MB sequentially from DISK
150,000,000 ns - Send a NETWORK packet CA -> Netherlands
| | | |
| | | ns|
| | us|
| ms|
决定，你在现实中的目标是多少“实时”，这是最大的不同——如果你在技术上必须实现过程控制循环，由于其稳定性标准 低于 1 kHz RTT-End-to-End 的阈值（事件发起 + 传输 + 本地采集 + 本地处理 + 反馈循环 << 1 [ms] )、10 kHz (<< 100 [us])。了解这个“意图”有助于您决定能够（或基本上不能）实现上述目标的适当且可行的技术。选择不合适的技术是业余爱好者的常见错误（而且代价高昂）（但即使是专业软件公司也经常重复）。
在了解 RTT-E2E 阈值的实际值后，在进一步进行任何步骤之前检查 API 提供程序是否确实允许您如此频繁地在两种技术方面提供更新和商业意义。如果没有，您必须找到另一个数据馈送提供商，谁会这样做。如果您的实时系统无法从充分采样（快速）的馈送源馈送，则控制回路将无法在其稳定性范围内为您工作——这很糟糕——就像你试图观察一样糟糕您的电视不会显示来自高清视频流的每张 37~46 张图片，而是每张图片。您将无法观看此“次采样的断断续续的东西”（当然，如果您当地的 DVB-T 解码器根本不放弃显示任何内容，因为 DVB 如此残酷的规模-T 流协议违规，当即使只有几个 CRC 位在 Reed/Solomon-redundant 容错转码上的几个 CRC 位未能正确通过时，方格伪影也令人讨厌）但与稳定且无错误的 1 相比绝对没有什么好： 1 个全高清流。
拥有 RTT-E2E 阈值的实际值和可用的匹配 API 供应商，开始设计技术步骤（而不是实施它们的技术）你打算如何帮助掩盖现实世界 实时延迟 -- 传输的实际时间成本[我们]（+所有相关的加密/解密方案，无论是 SSL 隧道还是 VPN 或其他) 从 API 提供者参考访问点到您的处理引擎输入。不知道这一点，你所有的进一步决定都会有缺陷。
测量了现实世界的 ISO/OSI-L9-down-stream 延迟，在 [us] 中将该时间加倍，以便还保留合理的时间来覆盖上游延迟（不需要具有完全相同的延迟源，但数量级会接近）。
如果您的初始设计 RTT-E2E 目标图具有上述 1kHz 的控制回路阈值和您通过实验观察到的延迟的 max( DownStream ) + max( UpStream ) 上限，如在至少一个 24/7 工作周期内针对提供商的实际生产 API 网关（检查是否与您的 1kHz 控制回路阈值匹配的那个）实时测量，现在计算剩下多少时间您可以开始任何类型的本地处理 - 即 实际上还有多少 [us] 留给您的本地处理，这样您的 1kHz 控制环不会无法满足其稳定性阈值。
如果你的净本地处理时间预算已经变成负，你知道你的工作不会产生任何好的结果。这不可以。拉停。
如果您的净本地处理时间预算还剩下一些可观的[我们]——这就是您要开始的实际流程的设计目标设计这样的计算步骤和措施，以便始终安全地适应。
在不知道这个主要设计限制的情况下开始编码的任何人要么是天真要么不负责任，是一个“正教”的院士或一个头脑发热的人（他们喜欢失败并且不介意一次又一次地撞墙(一组约束，只有爱丽丝梦游仙境可以从中抽象出来——不知道你想去哪里，任何一条路都会带你到那里——这是一个很好的童话故事，但不是一个可以尝试的现实世界的实践，是吗？）
- 现在，检查一下阈值，GIL 的发布频率（在
[us] 中） - 如果它确实不 适合很多次在您剩余的净本地处理时间预算内，人们可能会直接忘记使用python，那么简单（并且对多线程处理的反对不会让您在Python领域变得更好：
"... 在 Python 中，GIL 意味着即使您有多个线程同时在计算中运行，在任何给定时刻实际上只有一个线程会运行，因为所有其他线程都将被阻塞，等待获取全局解释器锁。这意味着多线程 Python 程序实际上会比单线程版本慢，而不是更快，因为一次只运行一个线程 - 加上强制每个线程会产生会计开销每隔几毫秒等待、获取并放弃 GIL（循环方式）的线程。..."
即使所有想成为专家发布无限量的免费条建议这个和那个包是一个很棒的工具。当然，许多软件包确实是很棒的工具，但很抱歉，在某些主要的稳定性阈值水平下，几乎从来没有用于任何更严格的实时应用程序域。是的，我对设计和操作一个 python/scikit-learn GLAN 分布式快速 AI/ML 预测系统感到非常满意，但我非常肯定适合本地 RTT-E2E 的<< 1 [ms] 和80 ~ 90 [us] 阈值完全在我的控制回路的稳定性范围内）
一个人可能会在工具中花费大量的只是喜欢编码，由于已知的主要无法匹配和满足控制回路稳定性阈值，因此专业人士永远没有理由开始使用正确的，所以更好在实时系统架构可行性/审查阶段应注意不要重复其中一些或类似天真的致命决策错误。