提高实时系统的性能
首先，我想确定金融领域实时系统可接受的端到端延迟小于 200 毫秒。 好吧，这就是我所追求的。 在实时系统的设计中，有一些“设计模式”（或技术）可以提高性能（即减少处理时间、提高可扩展性等）。
我所追求的一个例子是，使用 GUID 而不是顺序号来分配主键。 GUID 的基本原理是处理程序拥有自己的主键生成器，而无需相互“协商”。 这允许进行并行处理并允许缩放。
这里还有一些。 如果可以的话，我会尝试添加到列表中。
- 使用事件驱动架构(EDA)。
- 使用消息队列来支持 EDA。
我向社区的集体智慧致敬。 多谢多谢！
First, I'd like to establish the acceptable end-to-end latency for a real-time system in the financial world is less than 200ms. Okay, here's what I'm after. In the design of real-time systems, there are "design patterns" (or techniques) that will increase the performance (i.e. reduce processing time, improve scalability, etc).
An example of what I'm after is, the use of GUIDs instead of sequential numbers for allocation of primary keys. Rationale for GUIDs is that handlers have their own primary key generators without "consulting" each other. This allows for parallel processing to occur and permits scaling.
Here're some more. I'll try and add to the list when able to.
- The use of event driven architecture (EDA).
- Use of messaging queues to support EDA.
I bow to the collective wisdom of the community. Thanks heaps!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对于一般的实时系统工作，经典规则是追求可变性并消灭它。 真正的硬实时意味着使用静态调度、简化的操作系统、高效的设备驱动程序和严格的优先级。 如果你真的希望计算 X 在已知的时间限制 T 内结束，那么没有动态或自适应的东西是可行的。
我想你在这里的意思在这方面并不是真正的实时，而且我想系统有点复杂不仅仅是读取传感器、计算控制回路、激活执行器。 如果能了解更多细节，我们会很高兴知道这里有哪些限制。
For general real-time system work, the classic rule is to go after variability and kill it. Real hard real-time means using static schedules, streamlined operating systems, efficient device drivers, and rock-hard priorities. No dynamic or adaptive stuff is feasible, if you really want computation X to end within a known time-bound T.
I guess what you mean here is not really real-time in that respect, and I guess the system is a bit more complicated than reading sensors, computing control loop, activating actuators. Some more details would be nice to know waht the constraints are here.
您已经提到了事件驱动架构，我建议您看一下分阶段事件驱动架构（SEDA）。
阶段本质上是事件队列和对事件进行操作的函数。 这种架构的“非常规”之处在于，每个阶段都可以在自己的线程中运行，并且函数通常需要异步 I/O 等。以这种方式安排程序一开始很尴尬，但允许各种魔法 - 比如QoS、调整调度等。
请参阅威尔士的伯克利论文和他的网站。 您还可以查看 Minor Gordon 的项目（来自英国剑桥），名为 yield。 他取得了一些非常好的成绩。 乍一看，该项目似乎是针对 Python 的，但它也可以用于纯 C++。
You've already mentioned Event Driven Architecture, I'd suggest you have a look at Staged Event Driven Architectures (SEDA).
A stage is essentially a queue for events and a function to operate on the event. The "unconventional" thing about this architecture is that each stage can be run in its own thread and the functions typically need asynchronous I/O, etc. Arranging programs in this way is awkward at first, but allows for all kinds of magic - like QoS, tweaked scheduling, etc.
See Welsh's Berkeley dissertation and his web site. You might also look at Minor Gordon's project (from Cambridge UK) called yield. He had some very good results. It may seem like the project is geared towards Python at first, but it can be used for pure c++ as well.
尽管听起来很简单，但大多数业务应用程序都充满了冗余计算，请消除它们。 计算重构是优化模式的支柱。 每次出现处理循环时，您都必须问：
该循环内的计算结果与循环外的输出相同。
作为一个基本示例：
在这里，您可以安全地采用 x/2 并在 cicle 之前计算它并重用该值（现代编译器现在负责这些琐碎的优化）
要查看这个简单规则的后果，我可以给您应用的示例到数据库查询。 为了避免两个表的 INNER JOIN 以获得高度重复的字段请求，您可以违反规范化规则并将其复制到与具有该值的表相关的表上。 这避免了重复的表连接处理，并且可以释放并行化，因为只有一个表需要在事务上锁定。 示例：
客户表查询经常需要客户折扣，但折扣保存在客户类型表中。
As basic as it may sound, most line of business applications are filled with redundant calculations, eliminate them. Refactoring of calculations is the backbone of optimization patterns. Every time a processing cycle appears you have to ask:
What within this cycle is calculated with the same output it would have out of the cycle.
As a basic example:
Here you can safely take x/2 and calculate it before the cicle and reuse that value (the modern compilers now take care of these trivial optimizations)
To see the ramifications of this simple rule I can give you the example applied to database querys. In order to avoid the INNER JOIN of two tables in order to get a highly recurrent field requent you can violate the normalization rules and duplicate it on the table relating to the one that has the value. This avoids repetitive table joining processing and can free up paralelization as only one of the tables needs to be locked on transactions. Example:
Client table querys need a client discount recurrently but the discount is saved in the Client type table.
除非您确定任何东西“损坏”，否则不要“修复”任何东西。
我要做的第一件事就是调整必须快速运行的程序的火焰。 我会使用我的最喜欢的技术。 然后，很可能会有足够的回旋余地来玩弄建筑。
Don't "fix" anything unless you know for sure that it's "broken".
The first thing I'd do is tune the blazes out of that program that has to run fast. I would use my favorite technique. Then, chances are, there will be enough wiggle room to fool around with architecture.