客户端交互设计问题？
好的，这是我的情况： 我正在寻找最好的设计方法。 我在服务器端使用 PHP/Smarty，在客户端使用 HTML/jQuery，但这在这里并不重要。
我的服务器上有这个多用户系统。 它是一种订购系统。 标准用户（我们称之为客户）可以从网上商店订购一些商品。 该网上商店包含来自多个卖家的商品。
当用户（客户）下订单时，卖家（也是系统中的用户）必须收到有新订单的通知并确认/拒绝该订单。
当卖家确认/拒绝订单时，必须向用户发送通知，告知他/她的订单状态。
订单以及订单确认信息都存储在数据库中。
我现在能想到的唯一方法是不断地（在短时间内使用 AJAX）从卖家的屏幕上检查数据库中的新记录，并在客户等待时为他/她做同样的事情确认。
但我在想，有什么办法可以在用户（客户）下订单时触发向卖家发送通知，以便卖家可以仅在需要时加载数据库，而不是不断地间隔加载数据库？
当顾客等待确认时也是如此。但这并不那么重要，因为它不会一直发生。有一个等待限制，如果卖家没有回复，订单将被自动拒绝。
我希望你能理解我的问题。
Okay, here is my situation:
I'm looking for the best design approach.
I'm working in PHP/Smarty on the server-side and HTML/jQuery for the client-side, but that is not really important here.
I have this multi-user system on my server.
It is a kind of ordering system.
A standard user -- let's call them customer -- can order some items from the webshop.
The webshop contains items from multiple sellers.
When the user (customer) places the order, the seller -- also a user in the system -- has to get notified that there is a new order and confirm/decline it.
When the seller confirms/declines the order, a notification has to be send to the user giving him/her the status of his/her order.
Orders are stored in the database, as well as order confirmations.
The only way I can think of right now is to constantly -- in short intervals with AJAX -- check for new records in the database, from the sellers' screen, and do the same thing for the customer when he/she is waiting for the confirmation.
But I'm thinking, is there any way to trigger notifications to the seller when the user(customer) places the order so the seller could load the database only when needed and not constantly in intervals?
The same goes for the customer when he/she is waiting for confirmation. But that is not so important because it doesn't happen all the time. There is a waiting limit when the order will be automatically declined if the seller doesn't respond.
I hope you understand my question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Using Comet with PHP 上类似问题的答案表明，可能存在一些问题Apache 线程与客户端的所有打开连接相关联。
根据 PHP Continuations 上的这篇博客文章，可以使用PHP 的延续，但似乎没有那么多关于该主题的文档。然而，CometChat 用 PHP 做到了。目前尚不清楚他们是否正在使用延续，但他们声称可以扩展到 100,000 个连接。有关 PHP Comet 的更多信息可以在有关 Comet 和 PHP 的解决方案<的类似堆栈溢出问题中找到/a>.
我还建议使用 Java，因为 Java 在使用 Continuations 实现可扩展 Comet 方面拥有非常出色的记录。 Conversion Support 是一个聊天软件示例，它在 Jetty Web 服务器。
由于您的代码采用 PHP 语言，因此您可以 使用 Querces 在JVM。此外，Querces PHP 基准测试表明它比 Apache 更快，这为您提供了额外的优势。查看Querces 项目了解更多信息。
更新：我建议您自己进行基准测试或自己研究速度问题，因为可能有一些信息表明 Apache 更快。如果使用 Querces，重要的是要了解您本质上编写的 Java 恰好看起来和感觉都像 PHP。因此，我建议您进行额外的研究，以便您了解这种方法的优点和缺点。
The answer to a similar question here on Using Comet with PHP suggests that there could be some problems with Apache threads being tied up from all the open connections to the client.
According to this blog post on PHP Continuations, it is possible to use continuations with PHP, but there just doesn't seem to be as much documentation on the subject. However, CometChat did it in PHP. It's not clear if they are using continuations, but they claim to scale to 100,000 connections. More information on PHP Comet can be found in this similar Stack Overflow Question regarding A Solution for Comet and PHP.
I was also going to suggest using Java, as Java has a really great track record for implementing scalable Comet with Continuations. Conversion Support is an example of chat software that uses comet and continuations on a Jetty Web Server.
Since your code is in PHP, you could Use Querces to run your PHP code on the JVM. Additionally, Querces PHP Benchmarks Suggest it's Faster than Apache, which gives you added advantages. Check out the Querces Project for more information.
UPDATE: I suggest you do your own benchmarks or research the speed issue yourself, as there may be some information that may suggest Apache is faster. If using Querces, it's important to understand that you would essentially be writing Java that just happens to look and feel like PHP. Thus, I'd suggest additional research there as well so that you understand the advantages and disadvantages of this approach.
虽然即时更新固然很好，但实际上，更新永远不会是即时的，通过互联网传输数据总会存在一定程度的延迟。
由于多种原因，投票选项似乎更具吸引力。
您描述的系统听起来好像虽然一开始规模很小，但它可以轻松扩展到多服务器配置。轮询允许您创建 AJAX 请求可以查询的轮询服务器。这可以针对 AJAX 的小而快的特性进行优化，因为标准 Web 服务器可以专用于通常意义上的网页显示。
轮询理念还适用于 REST 风格的 API，使轮询区域完全独立于浏览器。您可能会发现，更进一步，您系统上的卖家更喜欢拥有本机应用程序，甚至是 iPhone/Android 应用程序。 REST API 允许您从任何可以发出 HTTP 请求的应用程序执行此操作。
从本质上讲，您可以避免被特定的技术所束缚，从而开启未来的可能性。它不会增加任何大量的工作，并且提供了永久连接所不允许的灵活性。
Although instant updates would be nice, in reality, updates would never be instant anyway, there will always be a degree of latency inherent in transfering data over the internet.
The polling option seems more attractive for several reasons.
The system you describe sounds as if although it may start out small scale, it would easily scale to a multi-server configuration. Polling would allow you to create a polling server which the AJAX requests can query. This can be optimized for the small and fast nature of AJAX, where as the standard web server can be dedicated to web page display in the usual sense.
The polling idea also lends itself to a REST style API, making the polling area completely independant of the browser. You could find that further down the line, sellers on your system would prefer to have a native app, or even an iPhone/Android app. The REST API would allow you to do this from any app that can make an HTTP request.
Essentially you're avoiding being locked in to a particular technology, and that opens up future possibilties. It doesn't add any great amount of work, and provides a level of flexability that a permenent connection would not allow.
上面提到的 COMET 和长轮询是这个问题的常见解决方案。但您也可以研究 HTML5 Web 套接字。所有浏览器都支持它，但有针对 IE 浏览器的补丁/polyfill。
您还可以查看 Node.js 与 apache 一起运行。
COMET and long polling as mentioned above are common solutions to this problem. But you could also look into HTML5 web sockets. It's supported in all browsers but there are patches/polyfills for IE browsers.
You could also look at Node.js to run along side apache.