我应该使用哪种语言进行实时应用程序
我将开发实时应用程序，该应用程序将接收股票市场数据并进行一些处理，然后传播到客户端应用程序。 我决定在服务器和客户端之间划分计算，服务器将进行基本计算，然后将基本数据发送到客户端，客户端计算最终变量。
我决定使用 C# 开发客户端应用程序（仅限 GUI），并使用 C++ 开发用于计算最终变量（称为：变量计算器）的组件。 用c++开发“变量计算器”的目的是为了模块化。 例如，如果我发现变量计算在客户端需要更多时间，我可以在服务器端使用相同的模块。
我还将使用标准 C++ 开发服务器端。
笔记： 服务器应该在不到一秒的时间内处理一组消息并将其发送到客户端 市场开始时的最大消息数量为 100,000 条消息
有什么建议吗？
I am going to develop real time application which will receive stock market data and doing some processing then disseminates to client application.
I decided to divide the calculations between the server and client the server will make the basic calculations then will send the basic data to the client which calculates the final variables.
I decided to develop the client application (GUI only) using C# and the component which will calculate the final variables (called:variables calculator) using C++.
the aim of developing "variables calculator" in c++ is for modularity.
for example if I found the variables calculations will take more time on the client side I can use the same module on server side.
Also I will develop the server side using standard C++.
Notes:
The server should process set of messages and send it to client in less than one second The maximum number of messages come at the begining of the market 100,000 messages
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
您必须面对的实时约束到底是什么？ 微秒、毫秒、秒？
它实际上需要实时，还是仅仅需要高性能？
假设它确实需要实时，那么语言不太可能是系统中最重要的东西，并且您很可能受到其余运行时环境的限制。 例如：您使用的库、网络堆栈、网络协议、操作系统、CPU 架构、内存、缓存等。
尽管如此，C 可能会为您提供易用性和了解底层系统的最佳组合正在做。 如果您非常了解 C++，那么如果按照严格的编码标准使用它也会适合。 如果它具有极高的性能，或者具有极高的可预测性要求，那么您可能需要转向汇编代码，但这不太可能，而且编译器对 CPU 管道的理解可能比您更好，并且它对于超过几千行代码的任何东西都是不切实际的。
当然，如果您只是需要相对较快的速度，那么我不认为实时性应该是您选择语言的首要考虑因素，而是合适的库和工具的可用性、开发团队的经验、对应用程序的适用性等将是更重要的考虑因素。
What exactly is the real-time constraint that you have to work with? Micro-seconds, milli-seconds, seconds?
Does it actually need to be real-time, or simply high-performance?
Assuming it really needs to be real-time, the language is unlikely to be the most important thing in the system, and you are mostly likely to be constrained by the rest of the run-time environment. E.g: libraries you use, network stacks, network protocols, operating system, CPU architecture, memory, cache etc.
All that said, C is probably going to give you the best combination of ease-of-use and knowing what the underlying system is doing. If you know C++ very well, then it would also be suitable if used with a strict coding standard. If it is extremely high-performance, or has extremely high predictability requirements then you may need to drop to assembler code, but this would be unlikely, and chances are the compiler has a much better understanding of the CPU pipeline than you do, and it would be impractical for anything over a few thousand lines-of-code.
If course, if you just need some relatively fast, then I don’t the real-time-ness should be your prime consideration in language choice, and rather availability of suitable libraries and tools, developer team experience, suitability to the application, etc would be more important considerations.
我不同意“实时”是一个模糊的定义。 更有可能的是，人们只是不明白其含义。 实时是指系统的响应时间与现实世界系统相同。 实际上，您可以让系统比实时速度更快，从而导致类似于系统比实时速度慢的问题。
因此，我不认为您要求使用“实时”应用程序的语言，而是要求真正快速的应用程序。
查看语言竞赛，看看哪些测试最适合您的设计空间; 然而，我的直觉答案是使用 C。
I disagree about "real-time" being a blurred definition. More likely, people just don't understand what is meant. Real-Time refers to a system's response time being the same as the real-world system. You can actually have a system be faster than real-time, causing problems similar to having a system slower than real-time.
As such, I do not believe you are asking for language use in reference to a "real-time" application, as much as for a really fast application.
Check out the language shootout and see what does the best on the kinds of tests that best approximate your design space; however, my gut answer is to use C.
在投资银行工作近30年。 我写过很多这样的应用程序。 您需要解决的根本问题可能不是实时性能，而是延迟和吞吐量。
在这种情况下，延迟是为了减少网络延迟，与语言选择无关。
吞吐量是指长时间持续的大处理能力，而性能是指短时间内非常大的处理能力。 尽管在这种情况下语言选择比延迟更重要，但它通常并不像您想象的那么重要。
在这两者中，通常最好首先设计尽可能低的延迟。 吞吐量问题可以在开发后期通过各种技巧来解决，但摆脱现有设计中的高延迟要困难得多。
因此，我会在客户端和服务器上都使用 C#，至少为了概念验证。 没有必要引入额外的复杂性（另一种语言）来解决不太重要的问题。
编辑：我注意到您编辑了问题，表示服务器需要在不超过 1 秒的时间内处理最多 100K 条消息。 我怀疑您是否可以通过软件实现此目的，但您也许可以使用 软件和硬件的结合。
如果您确实需要这种级别的低延迟（我在这个行业 30 年里从未需要过它），那么语言选择并不像拥有非常高的带宽以及超级优化和并行化那么重要算法。 但我首先会质疑这个要求，看看他们真正的意思是什么——我敢打赌这不是他们所说的。
Having worked for investment banks for nearly 30 years. I've written many applications like this. The underlying issue that you need to solve probably isn't real-time performance, but rather latency and throughput.
Latency in this context is about reducing network delays, and the language choice isn't very relevant.
Throughput is about large processing capacity sustained over long periods of time, whereas performance is about very large processing capacity for short periods of time. Although language choice in this context is more important than with latency, it's usually not as critical as you might think.
Of the two, it's normally better to design for the lowest possible latency first. Throughput problems can be solved later in development by various tricks, but getting rid of high latency baked into an existing design is much harder.
So I would go with C# on both the client and the server, at least for the proof-of-concept. It's not necessary to introduce additional complexity (another language) to solve a problem that isn't likely to be important.
EDIT: I noticed that you edited your question to say that the server needs to process up to 100K messages in no more than 1 second. I doubt that you can achieve this with software, but you might be able to by using a combination of software and hardware.
If you really do need this level of low latency (and I've never needed it in 30 years in the business), then again the language choice isn't nearly as important as having very high bandwith together with a super-optimised and parallelised algorithm. But I would first question the requirement to see what they really mean - I bet it's not what they said.
如今，什么是“实时”应用程序的定义相当模糊。 您的实时限制可能是几个月的微秒，具体取决于应用程序，并且您对语言、操作系统和工具的选择都将取决于这些因素。
在这种情况下，我不明白为什么你不应该在服务器端使用 C#。 也许还有您没有提到的限制，但从您所说的来看，我认为没有理由在您的问题中引入第二语言。
The definition of what's a "real-time" application is pretty blurred these days. Your real-time constraints may be microseconds of months, depending on the application, and your choice on language, OS, and tools will all depend on those things.
In this case I can't see why you shouldn't use C# on the server side as well. Maybe there are constraints you haven't mentioned, but from what you said I see no reason to introduce a second language into your problem.
如今，在不需要大量处理能力的客户端/服务器应用程序中，语言选择并不像它所使用的语言那么重要。 只要您知道如何构建良好的架构，Java、C#、C/C++ 的表现类似（显然本地语言会有一些优势）。 我会考虑每种语言的易用性和可用的有用库的数量来做出决定。 我不知道你的计算到底需要什么，也不知道你正在处理什么股票信息，但请查看库和 GUI 开发工具，然后从那里开始......
These days, language choice imo does not have as much importance as what it use to when it comes to client/server applications which do not require large amounts of processing power. Java, C#, C/C++ will perform similarly (Obviously native languages will have some advantage), as long as you know how to build good architectures. I would take into consideration ease of use and amount of useful libraries available for each language to make my decision. I dont know what your calculations exactly require or what stock information you are processing, but look into libraries and GUI development tools and go from there...
Scala、Erlang 或 Java。 但我强烈推荐 Scala，因为它有很好的语法和高可扩展性。
Scala, Erlang or Java. But i strongly suggest Scala for it's nice Syntax and high scalability.
我想看看 Erlang！ 他们的架构似乎非常适合此类应用程序。
I'd take a look into Erlang ! Their architecture seems like a perfect fit for applications like this.
您可以查看自适应通信环境，这是一个便携式服务器框架用 C++ 编写高性能服务器。 这篇 Stackoverflow 帖子 有一系列描述它并分散到各种资源的链接。
You could look at Adaptive Communications Environment, which is a portable server framework for writing high-performance servers in C++. This Stackoverflow posting has a series of links that describe it and fan out to various resources.
如果您确实想要低延迟和高吞吐量，我建议您删除服务器内的任何数据处理（计算）。 如果您确实想要/需要不在客户端上进行计算，我会设置另一个服务器来提供派生数据的补充数据流。 也就是说，您根据原始/原始 Feed 计算出的值。
你在谈论什么样的计算？
您计划如何处理网络和网络堆栈中的吞吐量？ 你们有延迟测量工具/嗅探器/endace 卡吗？
If you really want low latency and high throughput I suggest you remove any data processing within the server (calculations). If you really want/need to do calculations not on the client I would set up another server that provides a complementary data stream of derived data. That is, your calculated values based on the original/raw feed.
What kinds of calculations are you talking about?
How are you planning to handle the throughput in the network and on the network stack? Do you have latency measurement tools/sniffers/endace card?
我也实现了这样一个系统，我认为RoadWarrior实际上总结得很好。
这是消息队列的一个很棒的应用领域，如果您利用良好的底层 MQ 技术，我相信您可以满足几乎任何编程语言（甚至更高级别的解释语言）的吞吐量要求。
I have also implemented such a system, and I think RoadWarrior actually sums it up very well.
This is a terrific application area for message queues, and if you leverage a good underlying MQ technology I believe you could meet your throughput requirement in almost any programming language, even higher level interpreted languages .
Dan 的直觉答案是错误的，看看他发布的网站就可以清楚地看出现在的 C++（gnu/intel 实现）如何优于 C 实现
The gut answer of Dan is wrong, looking at the site he posted is clear how nowaday C++ (gnu/intel implementation) outperform C implementation