使用套接字在两台服务器之间发送数据是个好主意，还是应该使用 MQ 之类的东西来移动数据。
我的问题：套接字是否可靠，如果我只需要一次/有保证的数据传输？
还有其他解决方案吗？
谢谢。
问问题
5014 次
8 回答
15
套接字是用于执行网络通信的应用程序级 API。套接字的可靠性取决于您在创建套接字时选择的网络协议。如果您选择 TCP/IP，您将获得“可靠”传输……达到极限。如果您选择 UDP/IP，您将获得“不可靠”传输。
如其他答案所述，TCP 可确保您在一定程度上不会丢失或损坏数据：
- 如果网络中断时间足够长，或者发送方或接收方死亡，TCP/IP 连接将中断，您将丢失数据，除非您采取措施重新启动连接。
- 如果存在网络级别的数据损坏，则校验和无法检测到它的可能性很小。
要获得比 TCP/IP 提供的更高级别的可靠性保证，您需要在应用程序的基于 Socket 的网络层之上实现更敏感的校验和和保证交付机制。或者使用为您完成工作的消息队列产品。
所以你的问题的答案是，它取决于你如何使用套接字，以及你的系统需要什么级别的可靠性。
于 2009-07-21T07:28:25.007 回答
2
套接字与您的实现一样可靠，并且基于底层硬件。如果您不想麻烦地提供有保证的交付服务（在什么条件下？100% 永远不会发生），消息队列系统是一个不错的选择。如果您使用标准套接字，消息队列将实现您需要自己实现的所有持久性、排队、重试等。
于 2009-07-21T07:05:23.900 回答
2
如果无论发生什么都需要保证交付（例如，如果对方离线进行维护）并且您不想自己编写所有逻辑，则您可能应该使用 MQ。套接字是您用来连接到另一方的东西，无论该方是 MQ 还是消息的最终接收者。
于 2009-07-21T07:05:37.707 回答
2
Socket 是可靠的，因为每次通信都是在它之上完成的，包括 MQ。
但是您可能希望通过 MQ 添加一些保证交付，以提高应用程序的可靠性。它是什么？保证交付可确保您的消息由消费者至少处理一次，并且不超过一次。消费者关闭了？制片人关了？MQ 服务器已关闭？磁盘崩溃？多亏了 MQ，无论发生什么，都不会丢失任何消息（前提是您的管理员知道他的工作）。除此之外，如果您重新启动消费者，则不会处理两次消息。如果消息包含数百万美元的转账，这可能很重要。但它不能保证您的消息在合理的时间内得到处理。处理时间有时比保证交付更重要，具体取决于您的应用程序。
您可以根据需要选择在服务器之间进行通信的最佳方式。保证交付具有财务和性能成本，因此仅在真正需要时使用（例如数百万美元的转账）。
对于大多数应用程序，只有在失败时重试消息才能获得令人满意的结果。但这并不是真正的一次性保证交付。不要试图自己实现它，这是一个非常困难的东西，只有少数人能够实现。考虑重新开发像 MQ 或 Apache AQ 这样复杂的软件是没有用的。
希望有帮助。
- 杰布
于 2009-07-21T07:50:13.793 回答
1
套接字是传输数据的原始机制。其他一切都在此之上实现。在OSI 网络模型中，它们属于第 4 层。虽然它们实现了可靠的端到端连接，但很少用作端协议。你几乎总是需要实现一个应用层。这取决于您的应用程序（您需要传输文件还是只发送消息）和您的网络基础设施。
于 2009-07-21T07:09:24.767 回答
0
根据数据的类型，简单的 Web 服务可能是最快的解决方案。它们相对容易设置和测试。虽然对于一些具体的例子，我需要知道你正在运行什么样的数据和环境。
于 2009-07-21T07:13:51.480 回答
0
这在很大程度上取决于您正在开发的应用程序的类型。如果您正在编写一个程序，您需要响应或确认发送的消息，那么 TCP 套接字就很好。但是，如果您要实现某种工作流类型的场景，则应该使用消息队列。
于 2009-07-21T07:25:49.193 回答