Netty进阶之路-客户端池化疑云

素颜马尾好姑娘i 2022-02-01 12:59 279阅读 0赞

### Netty进阶之路-客户端池化疑云 ###

*  前言
 *  FixedChannelPool
 *   *  FixedChannelPool 构造参数
     *  FixedChannelPool 改造
 *  总结

# 前言 #

上一篇我们了解了EventExecutorGroup的工作机制，但是依然没有解决我们的1秒执行一次的问题。

# FixedChannelPool #

我们知道了EventExecutorGroup的工作机制。对于某个客户端连接Channel，只会注册到一个Nio线程中这句话很关键，也点醒了我，那如果客户端和服务端一直是由一个Channel进行交互的那就好发生1秒执行一次的问题。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2EyOTQ2MzQ0NzM_size_16_color_FFFFFF_t_70]  
果然 我们通过打印发现了除了一开始创建了5个channel之后，一直都是由一个和服务端进行交互的。  
猜测原因是由于客户端发起请求速度非常快，之后直接将其放回到线程池中，那么有可能直接后面在用这个线程。（其实也和JMeter有关，ramp-up period 参数调小，就会发现还是会出现不同的ChannelID的。ramp-up period 参数 大概意思就是多长时间执行设置的线程数）

InetSocketAddress addr = new InetSocketAddress(host, port);
        	final SimpleChannelPool pool = RPCRequestNet.poolMap.get(addr);
        	final Future<Channel> f = pool.acquire();
        	f.addListener(new FutureListener<Channel>() {
    			@Override
    			public void operationComplete(Future<Channel> arg0) throws Exception {
    				  if (f.isSuccess()) {
    				      Channel ch = f.getNow();
    				      ch.writeAndFlush(request);
    					  System.out.println("发送请求");
    					  pool.release(ch);
    				  }
    			}
    		});

## FixedChannelPool 构造参数 ##

通过查看API 我们可以看到有这些参数 其他都不细说了就一个lastRecentUsed。  
原文 ：true Channel selection will be LIFO, if false FIFO.  
翻译一下就是 true就是后进先出，false 就是先进先出。（原来是这个原因）

public FixedChannelPool(Bootstrap bootstrap,
                            ChannelPoolHandler handler,
                            ChannelHealthChecker healthCheck,
                            FixedChannelPool.AcquireTimeoutAction action,
                            long acquireTimeoutMillis,
                            int maxConnections,
                            int maxPendingAcquires,
                            boolean releaseHealthCheck,
                            boolean lastRecentUsed)

## FixedChannelPool 改造 ##

我们改造一下，lastRecentUsed参数是默认true，我们将其改成false

return new FixedChannelPool(b.remoteAddress(inetSocketAddress), handler, ChannelHealthChecker.ACTIVE, null, -1L, 5, 2147483647, true, false);

改完发现好了，哈哈 确实是这个原因。（图就不放了）

# 总结 #

1.  1.EventExecutorGroup并不是设置的越大就越好的，显然是NioEventLoopGroup的线程数量限制了上线。
2.  Netty确实是一个高性能通信框架利用FixedChannelPool 就能将并发量为30的一下子就发生完成了，只是全部都堆积在了服务器的队列中等待处理。
3.  .我们将lastRecentUsed改为false，确实是一种解决办法。其实还有一钟解决办法，就是业务线程的第二钟解决办法，我将会在后面介绍。
4.  其实Netty的提供了许多优化的方法，并不是说一定哪一种就一定是最好的，还是要和业务结合。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2EyOTQ2MzQ0NzM_size_16_color_FFFFFF_t_70]: /images/20220201/6cf152dc12064aef88e0aa330659aa38.png