如何最好地将我的应用程序与不可靠的数据库隔离？
我有一个 Java SOAP 数据服务，它位于 Sybase 数据库之上，由于我无法控制的原因，该数据库的性能不可靠。 该数据库是供应商包的一部分，已由内部团队修改，大多数问题是由一天中某些时间的响应时间缓慢引起的。
SOAP 服务向计算网格提供数据，当我请求数据时，我需要快速且一致的响应时间。 该服务提供基本的CRUD功能，但读写比例约为100:1。
将自己与数据库不可靠的性能隔离开来并确保 SOAP 服务快速可靠的最佳策略是什么？
I have a Java SOAP data service which sits on top of a Sybase database which, for reasons out of my control, has unreliable performance. The database is part of a vendor package which has been modified by an internal team and most of the issues are caused by slow response times at certain times of the day.
The SOAP service provides data to a calculation grid and when I request data, I need the response time to be both fast and consistent. The service provides basic CRUD functionality, but the ratio of reads to writes is approximately 100:1.
What is the best strategy to isolate myself from the database's unreliable performance and ensure that the SOAP service is fast and reliable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我已经见过这个问题几次了，通常是在供应商数据库中。
如果这是在 Windows 上，您可以创建一个 Windows 服务作为 SOAP 服务和数据库之间的中介。 然后在 SOAP 服务和 Windows 服务之间放置一个消息队列（MSMQ 或 JMS 实现，例如 MQ Series）以进行异步通信。 这样数据库性能问题将不再影响SOAP服务。 然而，该解决方案确实以增加复杂性为代价。
请注意，.NET Web 服务可由其客户端调用并异步响应。 我不确定 Java SOAP 服务是否可以实现这一点。
如果这是在某种风格的 Unix 上，我认为它具有与 Windows 服务类似的功能 - 也许是一个守护进程。
I have seen this issue a few times, normally with a vendor database.
If this is on Windows, you could create a Windows service as an intermediary between the SOAP service and the database. Then put a message queue (either MSMQ or a JMS implementation such as MQ Series) between the SOAP service and Windows service for asynchronous communications. In this way the database performance issues will no longer affect the SOAP service. This solution does, however, come at the cost of increased complexity.
Note that a .NET web service can be called by, and respond asynchronously to, its clients. I'm not sure if that's possible with a Java SOAP service.
If this is on some flavour of Unix, I assume it has similar functionality to a Windows service - maybe a daemon.
为什么不使用线程呢？ 这样，即使数据库速度很慢，应用程序也可以温和地等待。
Why not use a thread? That way, the application could gently wait even if the database is slow.
RoadWarrior 的回应是正确的。 执行任何操作的请求都会放入队列中。 用户进来一次提出请求，一次接受请求。 事实上，这就是 Expedia 等网站上正在与不可靠的服务（后端）进行通信的情况。 用户的浏览器正在对服务器执行 ping 操作，直到红灯变绿。
RoadWarrior's response is right on. Requests to do any operation get put in a queue. The user comes in once to make the request, and once to pick up the request. This is in fact what is happening on sites like Expedia where it is talking to an unreliable service (the backend). The user's browser is pinging the server until the red light turns green.
如何缓存来自 Web 服务的响应（在调用 WS 请求的客户端上，或者通过在两者之间设置代理 Web 服务）？
How about caching the responses from the web service (either on the client invoking the WS request, or by setting up a proxy web service in between)?
如果数据库不太大，您可以缓存数据库中的结果。
You could cache the results from the DB if the DB Is not too big.
让其他内部团队调整该数据库，以便使用该应用程序的每个人都受益。 我确实爱我一些索引！
Get the other internal team to tune that database, so everyone using the app benefits. I do love me some indexes!