希望这不是太主观...
我对基于消息的异步编程的想法很陌生——换句话说，编写一个自给自足的“小程序”集合，它们都同时运行并且只响应接收到的消息。
我知道这种风格必然会占用大量的 CPU 周期。
除此之外，还有什么可以支持和反对异步消息传递风格的呢？
问问题
780 次
1 回答
2
这种编程主要用于解决某一类问题；主要是那些需要处理许多连接而只做少量工作的人。电信交换机、证券交易所和即时通讯服务器自然会浮现在脑海中，但那些聪明的人可以将这种模式用于许多不同的事情。
这种方法的一大优势是分布性：您可以轻松地将它们均匀分布在多台机器上，而不是在一台机器上运行所有这些进程（拥有比处理器更多的进程通常不会对您有多大好处） ，并让他们通过网络进行通信。这允许极大的可扩展性，例如电信交换机或电子证券交易所，其中需要快速有效地处理大量少量信息。
另一方面，这种方法不适用于不会分解成小块的程序，并且在单个用户正在使用应用程序并且事件循环很小时根本没有帮助。一个很好的例子就是你拥有的几乎所有桌面应用程序。您不会从运行大量进程的文字处理器中获得任何收益，因为 99.9% 的时间都花在了事件处理上一次按键上，并且在您下一次按键之前完成，但是您在开销上花费了一些时间管理进程和消息队列。
除此之外，异步应用程序还有另一个大问题：共享数据。可以看看经典的多线程问题：假设您的应用程序是处理 ATM 交易的银行服务器。如果没有锁定账户余额，如果夫妻双方同时存入薪水，他们可能会与彼此的操作发生冲突，从而变得空头！通过使用异步处理代理，您必须做大量工作以确保正确处理这些情况，有时明显/简单的解决方案（例如锁）可能会产生瓶颈甚至线性化代码执行的不利影响，以便单个应用程序没有任何好处。
于 2011-10-25T21:46:05.597 回答