使用ApacheCamel和Netty实现TCP流量负载平衡会导致事务失败

我刚接触ApacheCamel和Netty，这是我的第一个项目。我正在尝试将Camel与Netty组件一起使用，以在后端负载测试场景中平衡繁重的通信量。这是我目前的设置：

从（“netty:tcp:\\this ip:9445？defaultCodec=false&sync=true”）.loadBalance（）.roundRobin（）到（“netty:tcp:\\backend1:9445？defaultCodec=false&sync=true，netty:tcp:\\backend2:9445？defaultCodec=false&sync=true）

问题是，我在客户端系统向Camel发送tcp流量的响应中收到了意外的缓冲区大小。当我一个接一个地发送多个请求时，我看不到任何问题，缓冲区大小与预期的一样。但是，当我尝试在同一端口上运行多个用户向Camel发送类似请求时，我会间歇性地中断ee意外的缓冲区大小，有时为0字节，有时甚至大于预期的字节数。我尝试使用Camel Netty页面中提到的多个选项，如：

• 增加积压
• 保持活力
• 缓冲区大小
• 超时
• 游泳池大小
• 工人计数
• 同步的
• 流缓存（不工作）
• 禁用用于性能的useOriginalMessage
• 系统级TCP参数等

我还没有解决这个问题。我不确定我是否从根本上遗漏了什么。我确实查看了编码器/解码器，并猜测这是否是一个问题。但是，我不明白为什么负载平衡器需要对消息进行编码/解码。我曾与其他负载平衡器合作，它们只需要端点配置，因此我是assuming该Camel不需要此功能。我说得对吗？请知道问题不在我的客户端/后端，因为我从客户端到后端运行了2000用户负载测试，失败率不到1%，但Camel出现了大量失败（不是没有成功）。我有以下问题：

1.这是Apache Camel-Netty的有效用例吗？我应该看看Mina还是其他人

2.我是否可以尝试将tcp流量路由到JMS或其他组件，然后最终路由到tcp端点

3.我是否需要编码器/解码器，或者此配置是否可以工作

4.我应该继续使用这种方法还是尝试其他负载平衡器

如果你有任何其他建议，请告诉我

编辑1：

我还尝试了netty4和mina组件的相同方法。路线看起来与netty中的路线相似。netty4的路线如下：

从（“netty4:tcp:\\this ip:9445？defaultCodec=false&sync=true”）到（“netty4:tcp:\\backend1:9445？defaultCodec=false&sync=true”）

我读了几篇文章，都有同样的问题，但没有找到与我的问题相关的解决方案

编辑2：

我增加了客户端的接收超时时间，并立即注意到预期缓冲区长度问题的不匹配降低到1%以下。但是，我发现使用Camel和不使用Camel时，每个事务的响应时间都非常长；几乎高出10倍。您能帮我减少每个事务的响应时间吗？消息从我的客户端收到的回执从5000字节到20000字节不等。以下是我的最新路线：

from（“netty:tcp://this-ip:9445?sync=true&allowDefaultCodec=false&workerCount=20&requestTimeout=30000")
.螺纹（20）
.loadBalance（）
.roundRobin（）
.至（“netty”：tcp://backend-1:9445?sync=true&allowDefaultCodec=false“，”内蒂：tcp://backend-2:9445?sync=true&allowDefaultCodec=false“”

我还使用了某些性能增强功能，如：

context.setAllowUseOriginalMessage（false）；
disableJMX（）；
context.setMessageHistory（false）；
context.setLazyLoadTypeConverters（true）；

---

您能为我指出如何减少单个事务时间的正确方向吗？

对于netty4组件，没有名为defaultCodec的参数。它被称为allowDefaultCodec。 还有，先试试这样的

from("netty4:tcp:\\this-ip:9445?textline=true&sync=true").to("netty4:tcp:\\backend1:9445?textline=true&sync=true")

以上说明发送的数据是普通文本。如果发送字节或其他内容，则需要为netty提供解码/编码以处理数据

---

还有一个旁注。在运行Camel路由之前，请手动测试以通过标准tcp工具（如sockettest）发送测试消息，以验证一切正常。然后通过Camel实现相同的测试。您可以在此处找到sockettest。

对于netty4组件，没有名为defaultCodec的参数。它被称为allowDefaultCodec。 还有，先试试这样的

from("netty4:tcp:\\this-ip:9445?textline=true&sync=true").to("netty4:tcp:\\backend1:9445?textline=true&sync=true")

以上说明发送的数据是普通文本。如果发送字节或其他内容，则需要为netty提供解码/编码以处理数据

---

还有一个旁注。在运行Camel路由之前，请手动测试以通过标准tcp工具（如sockettest）发送测试消息，以验证一切是否正常。然后通过Camel实现相同的测试。您可以在此处找到sockettest。

我最终使用与上述相同的路由设置解决了问题。问题在于请求和响应Delimiter未正确配置，原因可能是它过早关闭连接，导致意外的缓冲区大小，或者在接收到整个缓冲区后等待时间过长，导致响应时间过长。

我最终使用与上述相同的路由设置解决了此问题。问题在于请求和响应定界er配置不正确，原因可能是过早关闭连接导致缓冲区大小意外，或者即使在接收到整个缓冲区后等待时间过长，导致响应时间过长。

为什么不使用netty4，因为以前的netty组件已被弃用？如果不使用allowDefaultEncoding，则可以使用allowDefaultEncoding已编辑以对数据进行编码和解码。当我未指定

defaultCodec=false

时，安装程序不起作用。我还尝试了usi