RED5只能使用NioProcessor-1线程进行处理问题-优快云博客

针对Red5服务在生产环境中出现的拒绝服务问题，本文详细分析了其内部线程池配置导致的问题，并提供了一种改进NioSocketAcceptor构造方式的解决方案，通过调整线程池类型提高系统的处理能力和稳定性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

经过本人验证，下列方法可行。

原始出处：http://www.pigg.co/red5-issues.html

最近生产环境的red5经常出现拒绝服务的问题,仔细查看日志后发现所有的请求都是NioProcessor-1来完成,如果请求服务过多,会导致该线程处理不过来,也将导致线上其它服务将无响应,仔细查看了下RTMPMinaTransport构造源码

 
public void start() throws Exception {
    initIOHandler();
 
    IoBuffer.setUseDirectBuffer(!useHeapBuffers); // this is global, oh well
    if (useHeapBuffers) {
        // dont pool for heap buffers
        IoBuffer.setAllocator(new SimpleBufferAllocator());
    }
 
    log.info("RTMP Mina Transport Settings");
    log.info("Connection Threads: {}", connectionThreads);
    log.info("I/O Threads: {}", ioThreads);
 
    //use default parameters, and given number of NioProcessor for multithreading I/O operations
    //acceptor = new NioSocketAcceptor(ioThreads);
 
    //create separate executors to handle connections and i/o
    Executor connectionExecutor = Executors.newFixedThreadPool(connectionThreads);
    Executor ioExecutor = Executors.newFixedThreadPool(ioThreads);
    acceptor = new NioSocketAcceptor(connectionExecutor, new NioProcessor(ioExecutor));
 
    acceptor.setHandler(ioHandler);
    acceptor.setBacklog(50);
 
    log.info("TCP No Delay: {}", tcpNoDelay);
    log.info("Receive Buffer Size: {}", receiveBufferSize);
    log.info("Send Buffer Size: {}", sendBufferSize);
    
    ...
}

我们可以看到NioSocketAcceptor的构造是通过connectionExecutor与NioProcessor来完成的,从作者的代码上看,他希望监听连接与I/O处理使用不同的线程池处理,理论上说这种做法没有错,但进一步去看NioSocketAcceptor的构造方法会发这种构造方式有些问题.由于已经指定了connectionExecutor与ioExecutor,从代码中我们可以看出,这两种其实都是FixedThreadPool,即固定线程数的线程池,所有任务会在一个阻塞的队列中等待处理,在cpu资源与memory资源足够的情况下,这种做法显然有些保守了.

解决方案

既然已经知道red5的问题可能出在线程池的构造上,那么我们直接使用最直接的方法去构造NioSocketAcceptor

acceptor=newNioSocketAcceptor(DEFAULT_IO_THREADS);

这种方式其实是构造了两个CachedThreadPool,保证任务的优先处理,这样无疑提高了系统处理能力,问题也就得以解决,但这种做法并不是最优方案,如果想要达到更好的效果,必须了解red5的decode与encode,尽可能减少I/O线程的占用时间,尽可能减少线程上下文切换,以及使用用高效的序列化与反序列化工具.