我是Apache Camel和Netty的新手，这是我的第一个项目。我正在尝试使用带有Netty组件的Camel来在后端负载测试场景中负载平衡大量流量。这是我现在的设置：
from("netty:tcp:\\this-ip:9445?defaultCodec=false&sync=true").loadBalance().roundRobin().to("netty:tcp:\\backend1:9445?defaultCodec=false&sync=true,netty:tcp:\\backend2:9445?defaultCodec=false&sync=true)
问题是我在客户端系统中发现的响应中收到的意外缓冲区大小，这些响应将tcp流量发送给Camel。当我一个接一个地发送多个请求时，我看到没有问题，缓冲区大小是预期的。但是，当我尝试运行多个用户在同一端口上向Camel发送类似请求时，我间歇性地看到意外的缓冲区大小，有时甚至是0字节，甚至大于预期的字节数。我尝试使用Camel-Netty页面中提到的多个选项，如：
我还没有解决这个问题。我不确定我是否从根本上遗漏了一些东西。我确实看了一下编码器/解码器，猜猜这可能是个问题。但是，我不明白为什么负载均衡器需要对消息进行编码/解码。我曾与其他只需要端点配置的负载均衡器合作，因此，我假设Camel不需要这样做。我对吗？请知道问题不在于我的客户端/后端，因为我从我的客户端向后端运行了2000次用户负载测试，失败率低于1％但是看到Camel发生了大量故障（不是没有成功）。我有以下问题：
1.这是Apache Camel-Netty的有效用例吗？我应该看看米娜还是其他人？
2.我可以尝试将tcp流量路由到JMS或其他组件，然后最终到tcp端点吗？
3.我是否需要编码器/解码器或这种配置是否有效？
4.我应该继续这种方法还是尝试其他负载均衡器？
如果您有任何其他建议，请与我们联系。 TIA。
EDIT1：
我也尝试过与netty4和mina组件相同的方法。该路线看起来类似于netty中的路线。 netty4的路由如下：
from("netty4:tcp:\\this-ip:9445?defaultCodec=false&sync=true").to("netty4:tcp:\\backend1:9445?defaultCodec=false&sync=true")
我读了几篇有相同问题的帖子，但没有找到任何与我的问题相关的解决方案。
EDIT2：
我增加了客户端的接收超时，并立即发现预期缓冲区长度问题的不匹配率降至1％以下。但是，我看到使用Camel而不使用它时每个事务的响应时间是巨大的;几乎高出10倍。你能帮我减少每次交易的响应时间吗？在我的客户端收到的消息从5000到20000字节不等。这是我的最新路线：
from("netty:tcp://this-ip:9445?sync=true&allowDefaultCodec=false&workerCount=20&requestTimeout=30000")
.threads(20)
.loadBalance()
.roundRobin()
.to("netty:tcp://backend-1:9445?sync=true&allowDefaultCodec=false","netty:tcp://backend-2:9445?sync=true&allowDefaultCodec=false")
我还使用了某些性能增强功能，例如：
context.setAllowUseOriginalMessage(false);
context.disableJMX();
context.setMessageHistory(false);
context.setLazyLoadTypeConverters(true);
你能指出我如何减少个人交易时间吗？
答案 0 :(得分：0)
对于netty4组件，没有名为defaultCodec的参数。它被称为allowDefaultCodec。 http://camel.apache.org/netty4.html 此外，首先尝试这样的事情。
from("netty4:tcp:\\this-ip:9445?textline=true&sync=true").to("netty4:tcp:\\backend1:9445?textline=true&sync=true")
以上表示正在发送的数据是普通文本。如果您要发送字节或其他内容，则需要为netty提供解码/编码以处理数据。
并附注意。在运行Camel路由之前，手动测试以通过标准tcp工具（如sockettest）发送测试消息，以验证一切正常。然后通过Camel实现相同的功能。你可以在http://sockettest.sourceforge.net/找到sockettest。
答案 1 :(得分：0)
我终于用上面相同的路线设置解决了这个问题。问题在于请求和响应分隔符未正确配置，因为它过早地关闭连接导致意外的缓冲区大小，或者即使在收到整个缓冲区导致高响应时间之后它也等待太长时间。