在两个服务器之间发送数据,使用套接字是一个好主意吗?还是应该使用类似 MQ 的东西来移动数据。
我的问题是:如果我需要确保数据的一次性/可靠传递,套接字可靠吗?
还有其他解决方案吗?
谢谢。
在两个服务器之间发送数据,使用套接字是一个好主意吗?还是应该使用类似 MQ 的东西来移动数据。
我的问题是:如果我需要确保数据的一次性/可靠传递,套接字可靠吗?
还有其他解决方案吗?
谢谢。
套接字是用于进行网络通信的应用程序级API。套接字的可靠性取决于创建套接字时选择的网络协议。如果选择TCP/IP,您将获得“可靠”的传输……直到达到限制。如果选择UDP/IP,则会获得“不可靠”的传输。
如其他答案所述,TCP确保在某个点上不会丢失或损坏数据:
如果需要比TCP/IP提供的更高级别的可靠性保证,您需要在应用程序的基于Socket的网络层之上实现更敏感的校验和和可靠交付机制。或使用一个可以为您完成困难工作的消息队列产品。
因此,对您的问题的答案取决于您如何使用套接字以及系统需要什么级别的可靠性。
套接字的可靠性取决于你的实现方式和底层硬件。如果您不想为保证交付服务(在什么情况下?100%永远不会发生)而烦恼,那么消息队列系统是一个不错的选择。消息队列将实现所有持久性、排队、重试等功能,如果您选择标准套接字,则需要自己实现这些功能。
如果您需要无论发生什么情况都能保证传递成功(例如对方离线进行维护),并且不想编写所有逻辑,则应该使用MQ。套接字是用于连接到另一方的工具,无论该方是MQ还是消息最终接收者。
Socket是可靠的,因为所有通信都建立在其上,包括MQ。
但是,您可能希望通过MQ添加一些保证交付,以提高应用程序的可靠性。什么是保证交付?保证交付确保消费者至少处理一次消息,但不会超过一次。
如果消费者关闭了?生产者关闭了?MQ服务器关闭了?磁盘崩溃了?由于MQ,无论发生什么情况(前提是管理员知道他的工作),都不会丢失任何消息。
此外,如果重新启动消费者,则不会处理任何消息两次。如果消息包含数百万美元的转移,则这可能很重要。
但是,它不能保证您的消息在合理的时间内被处理。根据您的应用程序,处理时间有时比保证交付更重要。
根据您的需求选择最佳服务器之间通信的方法取决于您。保证交付交付具有财务和性能成本,因此仅在真正需要时才使用(例如,数百万美元的转移)。
对于大多数应用程序,只需在失败时重试消息即可实现令人满意的结果。但这并不是真正的一次性保证交付。不要尝试自己实现它,这是一项非常困难的工作,只有少数人能够实现。考虑重新开发像MQ或Apache AQ这样复杂的软件是没有用的。
希望这可以帮助您。
根据数据类型,简单的网络服务可能是最快的解决方案。它们相对容易设置和测试。但是对于一些特定的例子,我需要知道您正在运行什么样的数据和环境。
这主要取决于您正在开发的应用程序类型。如果您正在编写一个需要响应或确认已发送消息的程序,则TCP套接字是不错的选择。但是,如果您正在实现某种工作流场景,则应使用消息队列。