数据库作为 IPC 反模式
我编写了一个分层 Web 应用程序，其中包含与 java 服务交互的富 Web 客户端 (PHP)。 Web 客户端托管在 apache 服务器上，java 服务运行在同一台物理机上（重申一下：整个应用程序、客户端和服务都运行在同一台物理机上）。
用户请求 --> DB <-- 轮询器 -->请求处理程序 -->将结果存储在数据库中 --> Web 客户端使用结果更新页面 (AJAX)。
客户端和服务之间的通信使用关系数据库来传递消息。 java 服务有一个单线程轮询器，它查找并处理来自客户端的任何消息/请求。该系统有效，但我对我的设计选择没有信心。
有人对此策略有何评论吗？我读到，使用数据库作为 IPC 反模式是一种糟糕的做法，或者至少是一种不合适的做法。然而，替代方案——XMLRPC、命名管道——似乎涉及额外的依赖性。
感谢您的关注。
I've written a layered web application that consists of a rich-web client (PHP) that interacts with a java service. The web client is hosted on an apache server, and the java service runs on the same physical machine (to reiterate: the entire app, client and service, are running on the same physical machine).
User Request --> DB <-- Poller --> RequestHandler --> StoreResult in DB --> Web Client updates page with the result (AJAX).
Communication between the client and service uses a relational database to pass messages. The java service has a single-thread poller, which looks for and then processes any messages/requests from the client. The system works, but I am not confident in my design choice.
Does anyone have any comments about this strategy? I've read that using a Database as IPC antipattern is poor practice, or at least an inappropriate one. However, the alternatives--XMLRPC, named pipes--seem to involve additional dependencies.
Thanks for looking.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果是我，并且我需要 PHP 从 java 服务获取/使用数据，我会转储数据库。
让 java 服务在 127.0.0.1、端口 5544（或一些随机的 #）上侦听 HTTP。让 servlet/jsp 接受 RESTful 请求，并输出 JSON 结果。因此，如果是搜索，则 URL 将为：
h ttp://127.0.0.1:5544/search_zip_code/80203
，结果将是简单的 json:
{ "city": "Denver", "state": "Colorado" }
然后在 PHP 端执行curl 请求 - 使用用户输入的参数构建 URL，执行curl 请求，获取数据并对其进行 json_decode ( $result_array = json_decode($curl_result); )。
这很简单。这样，您可以轻松测试任一组件（从命令行执行curl/wget来测试java服务，或者检查服务器端的access_logs以查看搜索参数和来自客户端的连接）。
对于 PHP 端，使用curl_exec 和 json_decode（在 PHP 手册中搜索这些函数）。
这是我为 java 端找到的一个随机链接：
使用 java servlet struts 解析 JSON 数据
这种方式具有可扩展性（易于分离服务）、模块化（易于测试任一组件），并且返回结果的速度要快得多给客户。
If it were me, and I needed PHP to grab/consume data from a java service, i'd dump the DB.
Have the java service w/ HTTP listening on 127.0.0.1, port 5544 (or some random #). Have a servlet/jsp take RESTful requests, and spit out JSON results. So if its a search, the URL would be:
h ttp://127.0.0.1:5544/search_zip_code/80203
and the result would be simple json:
{ "city": "Denver", "state": "Colorado" }
and then on the PHP side do a curl request - build the URL with the parameters from the user input, do the curl request, get the data back and json_decode it ( $result_array = json_decode($curl_result); ).
It'd be simple. This way, you can test either component easily (do a curl/wget from command line to test the java service, or check the access_logs on the server side to see the search parameters and the connection from the client).
For the PHP side, use curl_exec and json_decode (search for those functions in the PHP manual).
Here's a random link I found for the java side:
Parsing JSON data with java servlet struts
This way would be scalable (its easy to separate the services), modular (easy to test either component), and a lot faster for delivering results back to the client.
我看到 DB 作为 IPC 的以下参数：
1）您需要存储您收到的所有（或一段时间内）消息。
2）您需要高可靠性并且不想丢失任何消息。
3）DB两侧的性能差异很大。通过这种方式，左侧客户端可以生成大量消息，并且右侧的许多客户端将处理它们。所以DB就像一个高可靠性的无源负载均衡器。
您需要这些功能吗？我认为不。您不能将其用作负载平衡器，因为所有进程都位于同一主机上。我认为您不需要存储所有网络请求。
在这种情况下，我会选择简单的套接字。
I see following arguments for DB as IPC:
1)You need to store all (or for some period) messages you ever received.
2)You need high reliability and don't want to loose any messages.
3)Perfomance of DB opposite sides is very different. In this way left client side can generate huge amount of messages and many clients on right side will process them. So DB is like passive load balancer with high reliability.
Do you need any of this features? I think no. You can't use it as load balancer because all processes are on the same host. And I think that you don't need to store all web requests.
In this case I would choose simple sockets.
如果您只需要 PHP 消息传递，只需使用 ActiveMQ - 就像 UNIX IPC 中的消息队列一样。
然而，数据库可能是 UNIX IPC 中已知的共享内存和信号量的一个很好的等价物。
因此，拥有 ActiveMQ 和数据库，您可以执行与 UNIX IPC 相同的操作，但如果一台服务器对您来说太小，则可以进行集群。
If you just need message passing for PHP, just use ActiveMQ - just like message queues in UNIX IPC.
However database may be a good equivalent of shared memory and semaphores known from UNIX IPC.
So having ActiveMQ and database you can do the same you would be able to do with UNIX IPC, but it can be clustered if one server will be too little for you.
这是一个黑客，但它显然对你有用。 这里有一个网站介绍如何实施PHP 中带有数据库表的消息队列。
It is a hack, but it obviously works for you. Here is a web site on how to implement a message queue with a DB table in PHP.