logo标签列表

套接字可靠吗？

socketscommunicationreliabilityqos
8

在两个服务器之间发送数据，使用套接字是一个好主意吗？还是应该使用类似 MQ 的东西来移动数据。

我的问题是：如果我需要确保数据的一次性/可靠传递，套接字可靠吗？

还有其他解决方案吗？

谢谢。

2
@modosansreves：如果打乱的单词只要首尾字母正确就能辨认，那么语法错误也不会对理解造成太大影响。重点在于传达信息而非个别单词。 - Fake Code Monkey Rashid
8个回答
15

套接字是用于进行网络通信的应用程序级API。套接字的可靠性取决于创建套接字时选择的网络协议。如果选择TCP/IP，您将获得“可靠”的传输……直到达到限制。如果选择UDP/IP，则会获得“不可靠”的传输。

如其他答案所述，TCP确保在某个点上不会丢失或损坏数据：

  1. 如果有足够长时间的网络中断，或者发送方或接收方断开了TCP/IP连接，除非您采取重新启动连接的措施，否则您将丢失数据。
  2. 如果存在网络级别的数据损坏，则有很小的可能性它不会被检测到校验和。

如果需要比TCP/IP提供的更高级别的可靠性保证，您需要在应用程序的基于Socket的网络层之上实现更敏感的校验和和可靠交付机制。或使用一个可以为您完成困难工作的消息队列产品。

因此，对您的问题的答案取决于您如何使用套接字以及系统需要什么级别的可靠性。

2

套接字的可靠性取决于你的实现方式和底层硬件。如果您不想为保证交付服务（在什么情况下？100％永远不会发生）而烦恼，那么消息队列系统是一个不错的选择。消息队列将实现所有持久性、排队、重试等功能，如果您选择标准套接字，则需要自己实现这些功能。

2

如果您需要无论发生什么情况都能保证传递成功（例如对方离线进行维护），并且不想编写所有逻辑，则应该使用MQ。套接字是用于连接到另一方的工具，无论该方是MQ还是消息最终接收者。

2

Socket是可靠的，因为所有通信都建立在其上，包括MQ。

但是，您可能希望通过MQ添加一些保证交付，以提高应用程序的可靠性。什么是保证交付？保证交付确保消费者至少处理一次消息，但不会超过一次。

如果消费者关闭了？生产者关闭了？MQ服务器关闭了？磁盘崩溃了？由于MQ，无论发生什么情况（前提是管理员知道他的工作），都不会丢失任何消息。

此外，如果重新启动消费者，则不会处理任何消息两次。如果消息包含数百万美元的转移，则这可能很重要。

但是，它不能保证您的消息在合理的时间内被处理。根据您的应用程序，处理时间有时比保证交付更重要。

根据您的需求选择最佳服务器之间通信的方法取决于您。保证交付交付具有财务和性能成本，因此仅在真正需要时才使用（例如，数百万美元的转移）。

对于大多数应用程序，只需在失败时重试消息即可实现令人满意的结果。但这并不是真正的一次性保证交付。不要尝试自己实现它，这是一项非常困难的工作，只有少数人能够实现。考虑重新开发像MQ或Apache AQ这样复杂的软件是没有用的。

希望这可以帮助您。

  • jeb
1
套接字是传输数据的原始机制，其他所有内容都是在其之上实现的。在OSI网络模型中，它们属于第4层。虽然它们实现了可靠的端到端连接，但它们很少用作最终协议。你几乎总是需要实现一个应用层。这取决于你的应用程序（你需要传输文件还是只发送消息）和你的网络基础设施。
+1：使用“sockets IS”来嘲笑modosansreves是一个有趣的巧合。当然，这可能只是一个完全的巧合。 - Fake Code Monkey Rashid
2
套接字与OSI网络模型无关。套接字是一个接口，用于（可能）双向缓冲通信，其价值在于它可以附加到任何底层通道并支持底层通信通道的各种属性。除了原始/ tcp / udp和其他网络通信外，您可能会使用套接字通过管道或任何您可以想象的通道进行本地通信。不要将此概念简化为OSI。 - Don Johe
0
如果您使用流套接字，TCP协议可以确保数据在传输过程中不会丢失，并且不太可能损坏（尽管您必须决定其16位校验和是否足够或者您需要一种应用层校验机制）。
MQ系统提供的是应用级事务型可靠性，也就是在硬件或软件故障间歇性出现的情况下仍具备保证传递的能力，您可以根据实际需求来选择是否需要此项功能。
0

根据数据类型，简单的网络服务可能是最快的解决方案。它们相对容易设置和测试。但是对于一些特定的例子，我需要知道您正在运行什么样的数据和环境。

0

这主要取决于您正在开发的应用程序类型。如果您正在编写一个需要响应或确认已发送消息的程序，则TCP套接字是不错的选择。但是，如果您正在实现某种工作流场景，则应使用消息队列。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接