客户-客户交互设计问题？答案

【问题标题】：Client-client interaction design issue?客户-客户交互设计问题？
【发布时间】：2011-01-29 17:35:48
【问题描述】：

好的，这是我的情况：我正在寻找最好的设计方法。我在服务器端使用 PHP/Smarty，在客户端使用 HTML/jQuery，但这在这里并不重要。

我的服务器上有这个多用户系统。它是一种订购系统。一个标准用户——我们称他们为客户——可以从网上商店订购一些商品。网上商店包含来自多个卖家的商品。

当用户（客户）下订单时，卖家（也是系统中的用户）必须收到有新订单的通知并确认/拒绝。

当卖家确认/拒绝订单时，必须向用户发送通知，告知他/她的订单状态。

订单以及订单确认信息都存储在数据库中。

我现在能想到的唯一方法是不断地——在短时间内使用 AJAX——从卖家的屏幕上检查数据库中的新记录，并为客户做同样的事情。正在等待确认。

但我在想，有没有办法在用户（客户）下订单时触发通知给卖家，这样卖家就可以只在需要时加载数据库，而不是每隔一段时间加载数据库？

客户在等待确认时也是如此。但这并不是那么重要，因为它不会一直发生。如果卖家不回复，订单将自动被拒绝，有一个等待限制。

希望你能理解我的问题。

【问题讨论】：

我认为您应该研究 COMET - 它基本上是一个术语，它封装了模拟 PUSH 机制的各种方法。看看这个答案stackoverflow.com/questions/603201/using-comet-with-php 和这个stackoverflow.com/questions/1320542/… 我认为这应该给你足够的开始
谢谢。彗星似乎是要走的路。只是我在这两个线程中有点迷失。我找不到多用户系统的示例。有什么帮助吗？
好的。我读了几篇关于 COMET 和长轮询的文章，现在基本明白了。唯一的问题是我被 Apache 服务器困住了，这不是这项工作的最佳选择。谁能告诉我 Apache 可以同时使用的最大持久连接数是多少？
Apache 有 CometProcessor 接口，当您使用 Http11NioProtocol 时，它将汇集连接。但是，我认为 Comet 不是解决此问题的正确方法，卖家或用户是否真的需要立即知道新订单已发生？我认为对于这个用例来说，每隔 1 或 2 分钟轮询一次就足够了。
马上知道并不重要。但为什么不呢？除了 apache 问题，关于彗星方法的任何缺点？

标签： ajax web-applications client-server comet multi-user

【解决方案1】：

Using Comet with PHP 上类似问题的答案表明，Apache 线程可能存在一些问题，因为 Apache 线程被绑定到客户端的所有打开连接中。

根据PHP Continuations 上的这篇博文，可以在 PHP 中使用延续，但似乎没有关于该主题的那么多文档。但是，CometChat did it in PHP。目前尚不清楚他们是否使用延续，但他们声称可以扩展到 100,000 个连接。有关 PHP Comet 的更多信息，请参阅关于 A Solution for Comet and PHP 的类似 Stack Overflow Question。

我还建议使用 Java，因为 Java 在实现可扩展的 Comet with Continuations 方面有着非常好的记录。 Conversion Support 是聊天软件的一个例子，它在 Jetty Web Server 上使用彗星和延续。

由于您的代码是在 PHP 中，您可以Use Querces to run your PHP code on the JVM。此外，Querces PHP Benchmarks Suggest it's Faster than Apache 为您带来更多优势。查看Querces Project 了解更多信息。

更新：我建议您自己进行基准测试或自己研究速度问题，因为可能有一些信息表明 Apache 更快。如果使用 Querces，重要的是要了解您实际上是在编写恰好看起来和感觉像 PHP 的 Java。因此，我还建议您在那里进行更多研究，以便您了解这种方法的优缺点。

【讨论】：

【解决方案2】：

虽然即时更新会很好，但实际上，更新永远不会是即时的，通过互联网传输数据总会存在一定程度的延迟。

出于多种原因，轮询选项似乎更有吸引力。

您描述的系统听起来好像虽然开始时规模很小，但很容易扩展到多服务器配置。轮询将允许您创建 AJAX 请求可以查询的轮询服务器。这可以针对 AJAX 的小而快的特性进行优化，因为标准 Web 服务器可以专用于通常意义上的网页显示。

投票的想法也适用于 REST 风格的 API，使投票区域完全独立于浏览器。您可能会发现，您系统上的卖家更愿意拥有本机应用程序，甚至是 iPhone/Android 应用程序。 REST API 将允许您从任何可以发出 HTTP 请求的应用程序中执行此操作。

从本质上讲，您是在避免被锁定在特定技术上，这为未来开辟了可能性。它不会增加任何大量工作，并且提供了永久连接所不允许的灵活性级别。

【讨论】：

【解决方案3】：

上面提到的COMET 和长轮询是解决这个问题的常用方法。但您也可以查看 HTML5 Web 套接字。所有浏览器都支持它，但 IE 浏览器有补丁/polyfills。

您还可以查看 Node.js 以与 apache 一起运行。

【讨论】：