需要可靠/持久的出站套接字，选项？答案

【问题标题】：Reliable/persistent outbound sockets needed, options?需要可靠/持久的出站套接字，选项？
【发布时间】：2012-10-11 17:30:02
【问题描述】：

我有一个 Scala 应用程序，它一次维护（或尝试）与各种服务器的 TCP 连接数小时（可能 > 24）。每台服务器大约每秒发送两次约 30 个字符的短消息。这些消息被输入一个迭代器，在那里它们被解析并最终对数据库进行状态更改。

如果这些连接中的任何一个因任何原因失败，我的应用程序需要不断尝试重新连接，直到我另行指定。任何丢失的消息都是不好的。我无法控制我连接的服务器或使用的协议。

可以想象一次会有多达 300 个这样的连接。不完全是高负载场景，所以我认为不需要 NIO，尽管拥有它可能会很好？该应用的其他部分负载很高。

我正在寻找某种套接字控制器/管理器，它可以尽可能可靠地保持这些连接。我现在正在运行自己的阻塞控制器，但由于我对套接字编码（以及所有各种设置、选项、超时等）缺乏经验，我怀疑它能否实现最佳的正常运行时间。另外，我可能在某些时候需要 SSL 支持。

蔚来会提供任何真正的优势吗？

Netty 会是这里的最佳选择吗？我已经看到了 Uptime 示例 here，并且正在考虑简单地复制它，但是对于较低级别的网络来说，我不确定是否有更好的选择。

【问题讨论】：

检测断开连接和重新连接应该是微不足道的，即使使用 java.net.Socket。
我认为您实际上正在寻找可靠的消息传递服务。看看 JMS 的各种实现。
是的，这很简单；正如我上面提到的，我有一些工作。但是，我不确定确保尽可能少的数据包丢失的最佳策略，并假设这将是一个或另一个库中的“已解决”问题。我想很多都归结为超时猜测策略？过早关闭并重新打开套接字，您会丢失正在传输的所有数据包。
EJP，我无法控制我连接的服务器。因此，除非有另一种方法可以使 JMS 适应通用 TCP 流，否则我认为它不会起作用。

【解决方案1】：

但是，我不确定确保尽可能少丢失数据包的最佳策略，并假设这将是一个或另一个库中“已解决”的问题。

是的。 JMS 就是一个例子。

我想很多都归结为超时猜测策略？过早关闭并重新打开套接字，您会丢失正在传输的所有数据包。

没错。这种方法并不可靠，尤其是在连接经常上下波动的情况下。

真正的解决方案是让另一端跟踪它收到的内容，并让发送方知道何时重新建立连接。如果不能做到这一点，你就没有真正的方法来控制损失了多少。（这就是可靠的消息传递服务所做的......）

我无法控制我连接的服务器。因此，除非有另一种方法可以使 JMS 适应通用 TCP 流，否则我认为它不会起作用。

是的。如果您尝试手动实现，这同样适用。另一端必须配合。

我想您可以构建一些东西，在每个远程服务器上运行（例如）JMS 端点，并让端点使用 UNIX 域套接字或环回（即 127.0.0.1）与服务器通信。但您仍有可能丢失消息。

【讨论】：

我没想到我会找到一种方法来保留 100% 的消息而无需一些服务器端逻辑。我只是希望找到一个以前解决过这个问题并有解决方案以尽量减少损失的人，仅此而已。无论如何，感谢您将我引向 JMS；如果我可以在服务器上做一些事情，听起来就可以使用。