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