dubbo处理调用请求涉及缓存问题

一.场景

dubbo底层使用netty，一个boss线程，核心线程+1个worker。

读写io在worker线程去做。

每个worker会处理一部分socket读写。

高并发时，io线程不太会不足，原因是默认是核心线程+1。高并发时每个线程都会不断的在处理读写事件，cpu一直是处于忙的状态。这时增加io线程更多反而会因为cpu切换线程上下文而影响性能。

一般业务线程池不足可能性比较多，默认有200个线程。当然如果出现请求过多处理不过来，直接就抛错了，问题倒比较好查。

当然也可能会是网络出现瓶颈，内存及cpu出现瓶颈，需要用相应的工具命令查看。

之后会做实际测试。

而这里主要讲，worker线程在获取到socket读请求时，会从heap缓存中获取一个buffer。由于是堆缓存，不可避免一次内核到堆内存的拷贝。

二.原理

服务方处理消费方的调用流程如下：

1.一个读请求过来时,worker线程，首先从尝试从direct缓存区获取一个缓存，最多存储8块，是softReference类型的一个ByteBuf数组。

注：direct缓存默认在full gc时才会进行回收。如果没有full gc

用softReference不用担心由于缓存的原因。

注：这里如果没有则会创建一块direct缓存。

这里的direct缓存区是每个worker都有一个，所以不存在线程竞争问题。

2.将对应socket数据写入到这块direct缓存

3.创建一块heap内存，然后将direct缓存的数据写到这个堆内存

4.将之前创建的direct缓存放回到缓存池

5.将这个heap buffer交给后面的channelHandler处理。

后面会解码，channel handler处理也在io线程。

6.handler都处理完成后，会将这个解码后的消息交给另外一个线程池去做。这个线程池默认200个线程。

实际上还是发生了一次从direct缓存拷贝到堆内存。

源码：

private boolean read(SelectionKey k) {
        final SocketChannel ch = (SocketChannel) k.channel();
        final NioSocketChannel channel = (NioSocketChannel) k.attachment();

        final ReceiveBufferSizePredictor predictor =
            channel.getConfig().getReceiveBufferSizePredictor();
        final int predictedRecvBufSize = predictor.nextReceiveBufferSize();

        int ret = 0;
        int readBytes = 0;
        boolean failure = true;

        ByteBuffer bb = recvBufferPool.acquire(predictedRecvBufSize);
        try {
            while ((ret = ch.read(bb)) > 0) {
                readBytes += ret;
                if (!bb.hasRemaining()) {
                    break;
                }
            }
            failure = false;
        } catch (ClosedChannelException e) {
            // Can happen, and does not need a user attention.
        } catch (Throwable t) {
            fireExceptionCaught(channel, t);
        }

        if (readBytes > 0) {
            bb.flip();

            final ChannelBufferFactory bufferFactory =
                channel.getConfig().getBufferFactory();
            final ChannelBuffer buffer = bufferFactory.getBuffer(readBytes);
            buffer.setBytes(0, bb);
            buffer.writerIndex(readBytes);

            recvBufferPool.release(bb);

            // Update the predictor.
            predictor.previousReceiveBufferSize(readBytes);

            // Fire the event.
            fireMessageReceived(channel, buffer);
        } else {
            recvBufferPool.release(bb);
        }

        if (ret < 0 || failure) {
            k.cancel(); // Some JDK implementations run into an infinite loop without this.
            close(channel, succeededFuture(channel));
            return false;
        }

        return true;
    }

二.问题

1.最坏的情况下，这里direct缓存最大内存占用有多少？

底层用的是动态预计大小，

类：AdaptiveReceiveBufferSizePredictor

AdaptiveReceiveBufferSizePredictor最大限制是：6k。

也就是说direct dubbo用到最多6k*当前worker个数。

2.如果优化怎么优化？

在处理读请求时，最终还是会有一次direct缓存到heap堆的拷贝。

优化的话，这里要换成netty4，使用direct缓存池。