即发即忘与 http 请求相比
我正在征求大家的意见。我有一个 Web 应用程序需要将数据记录到另一个 Web 应用程序数据库中。由于延迟问题，我不喜欢在第二个应用程序上使用 HTTP 请求 GET。我正在寻找快速保存第二个应用程序记录的方法，我遇到了“即发即忘”的想法，JMS 适合这种情况吗？据我了解，JMS会保证消息的传递，保证消息是否100%传递并不重要，只要能服务尽可能多的请求即可。假设我需要每秒至少 1000 个随机请求调用第二个应用程序，我应该使用 JMS 吗？ HTTP 请求？或者 XMPP 代替？
I'm looking for opinion from you all. I have a web application that need to records data into another web application database. I not prefer to use HTTP request GET on 2nd application because of latency issue. I looking for fast way to save records on 2nd application quickly, I came across the idea of "fire and forget" , will JMS suit for this scenario? from my understanding JMS will guarantee message delivery, guarantee whether message will be 100% deliver is not important as long as can serve as many requests as possible. Let say I need to call at least 1000 random requests per seconds to 2nd application should I use JMS? HTTP request? or XMPP instead?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为您总体上误解了网络。绝对没有理由认为 HTTP GET 必须比其他任何方式都慢，并且如果 HTTP 利用保持活动，它会比大多数选项更快。
JMX 不是一个协议，它是一个封装了许多其他协议（可能包括 HTTP 或 XMPP）的规范。
最后，在 Java 运行的级别上，要么是 UDP，要么是 TCP。 TCP 通过保证交付（通过重传）和排序而产生更多开销。 UDP 既不提供保证传送，也不提供按顺序传送。如果您可以处理 UDP 的限制，您会发现它“更快”，如果您不能，那么任何轻量级 TCP 包装器（HTTP 就是其中之一）都差不多。
I think you're misunderstanding networking in general. There's positively no reason that a HTTP GET would have to be any slower than anything else, and if HTTP takes advantage of keep alives it's faster that most options.
JMX isn't a protocol, it's a specification that wraps many other protocols including, possibly, HTTP or XMPP.
In the end, at the levels where Java will operate, there's either UDP or TCP. TCP has more overhead by guarantees delivery (via retransmission) and ordering. UDP offers neither guaranteed delivery nor in-order delivery. If you can deal with UDP's limitations you'll find it "faster", and if you can't then any lightweight TCP wrapper (of which HTTP is one) is just about the same.
您的要求似乎是：
我的方法是让客户端线程在内部对更新进行排队，并实现一个客户端线程，定期将排队的更新组装到如有必要，服务器可以发送一个响应来指示各个更新的状态，从而
消除了客户端上的延迟影响，并可能允许服务器更有效地处理更新。
Your requirements seem to be:
The way I would approach this is to have the client threads queue the updates internally, and implement a client thread that periodically assembles queued updates into one HTTP request and sends it to the server. If necessary, the server can send a response that indicates the status for individual updates.
Batching eliminates the impact of latency on the client, and potentially allows the server to process the updates more efficiently.
HTTP 和 JMS 或 XMPP 之间的最大区别在于，JMS 和 XMPP 允许异步即发即忘消息传递（客户端并不真正知道消息何时以及是否会到达其目的地，并且不期望得到响应）或来自接收者的确认）。这将允许第一个应用程序快速响应，而不管第二个应用程序的处理时间如何。
对于消息消费者比生产者慢的大容量分布式消息传递，异步消息传递通常是首选。我不能说这是否正是你的情况。
The big difference between HTTP and JMS or XMPP is that JMS and XMPP allow asynchronous fire and forget messaging (where the client does not really know when and if a message will reach its destination and does not expect a response or an acknowledgment from the receiver). This would allow the first app to respond fast regardless of the second application processing time.
Asynchronous messaging is usually preferred for high-volume distributed messaging where the message consumers are slower than the producers. I can't say if this is exactly your case here.
如果您拥有完全控制权，并且两个 Web 应用程序在同一个 Web 容器中运行，因此在同一个 JVM 中运行，我建议使用 JNDI 来允许两个 Web 应用程序访问允许并发修改的通用数据结构（列表？） ，即允许应用程序 A 添加新条目，同时允许应用程序 B 消耗最旧的条目。
这很可能是最快的方法。
请注意，您应该将列表中的信息保留为在 JRE 中找到的类，否则您很可能会遇到类转换异常。这些可以被规避，但最简单的很可能只是在公共数据结构中传输字符串。
If you have full control and the two web applications run in the same web container and hence in the same JVM, I would suggest using JNDI to allow both web applications to get access to a common data structure (a list?) which allows concurrent modification, namely to allow application A to add new entries and application B to consume the oldest entries simultaneously.
This is most likely the fastest way possible.
Note, that you should keep the information you put in the list to classes found in the JRE, or you will most likely run into class cast exceptions. These can be circumvented, but the easiest is most likely to just transfer strings in the common data structure.