使用带有Netty的Apache Camel负载平衡TCP流量会导致事务失败

Question

我是Apache Camel和Netty的新手，这是我的第一个项目。我试图在后端负载测试中使用Camel和Netty组件来负载平衡重流量，scenario.This是我现在拥有的设置：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页面中提到的多个选项，例如：

• 积压越来越多
• keepAlive
• 缓冲尺寸
• 超时
• poolSizes
• workerCount
• 同步
• 流缓存(不起作用)
• 禁用useOriginalMessage以提高性能
• 系统级TCP参数等。

我还没有解决这个问题。我不确定我是不是从根本上遗漏了什么。我确实看了一下编码器/解码器，并猜测这是否是一个问题。但是，我不明白为什么负载均衡器需要编码/解码消息。我和其他负载平衡器一起工作过，它们只需要端点配置，因此，我假设Camel不需要这个。我说的对吗？请知道问题不在我的客户端/后端，因为我从我的客户端到后端运行了2000次用户负载测试，失败率不到1%，但是看到大量的失败(不是说没有成功)。我有以下问题：

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

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

3.我是否需要编码器/解码器，或者这种配置是否有效？

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

如果你有其他建议，请告诉我。蒂娅。

Edit1：

我还对netty4和mina组件尝试了同样的方法。这条路看上去和网际网路上的路线很相似。使用netty4的途径如下：from("netty4:tcp:\\this-ip:9445?defaultCodec=false&sync=true").to("netty4:tcp:\\backend1:9445?defaultCodec=false&sync=true")我读了几篇有相同问题的帖子，但没有找到任何与我的问题相关的解决方案。

Edit2：

我增加了客户端的接收超时，并立即注意到预期缓冲区长度问题的不匹配下降到不到1%。但是，我发现在使用Camel和不使用Camel时，每个事务的响应时间都很大，几乎是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);

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

Answer 1

我最终用与上面相同的路由设置解决了这个问题。问题是请求和响应划界器没有正确配置，因为它要么过早关闭连接，导致意外缓冲区大小，要么在收到整个缓冲区后等待太久，导致响应时间过长。