大并发网络服务器实现

aiserver

服务器公共组件实现 -- 消息队列
　　既然说到了消息队列，那我们继续来稍微多聊一点吧。
　　我们所能想到的最简单的消息队列可能就是使用stl的list来实现了，即消息队列内部维护一个list和一个互斥锁，putMessage时将message加入到队列尾，getMessage时从队列头取一个message返回，同时在getMessage和putMessage之前都要求先获取锁资源。
　　实现虽然简单，但功能是绝对满足需求的，只是性能上可能稍稍有些不尽如人意。其最大的问题在频繁的锁竞争上。
　　对于如何减少锁竞争次数的优化方案，Ghost Cheng提出了一种。提供一个队列容器，里面有多个队列，每个队列都可固定存放一定数量的消息。网络IO线程要给逻辑线程投递消息时，会从队列容器中取一个空队列来使用，直到将该队列填满后再放回容器中换另一个空队列。而逻辑线程取消息时是从队列容器中取一个有消息的队列来读取，处理完后清空队列再放回到容器中。
　　这样便使得只有在对队列容器进行操作时才需要加锁，而IO线程和逻辑线程在操作自己当前使用的队列时都不需要加锁，所以锁竞争的机会大大减少了。
　　这里为每个队列设了个最大消息数，看来好像是打算只有当IO线程写满队列时才会将其放回到容器中换另一个队列。那这样有时也会出现IO线程未写满一个队列，而逻辑线程又没有数据可处理的情况，特别是当数据量很少时可能会很容易出现。Ghost Cheng在他的描述中没有讲到如何解决这种问题，但我们可以先来看看另一个方案。
　　这个方案与上一个方案基本类似，只是不再提供队列容器，因为在这个方案中只使用了两个队列，arthur在他的一封邮件中描述了这个方案的实现及部分代码。两个队列，一个给逻辑线程读，一个给IO线程用来写，当逻辑线程读完队列后会将自己的队列与IO线程的队列相调换。所以，这种方案下加锁的次数会比较多一些，IO线程每次写队列时都要加锁，逻辑线程在调换队列时也需要加锁，但逻辑线程在读队列时是不需要加锁的。
　　虽然看起来锁的调用次数是比前一种方案要多很多，但实际上大部分锁调用都是不会引起阻塞的，只有在逻辑线程调换队列的那一瞬间可能会使得某个线程阻塞一下。另外对于锁调用过程本身来说，其开销是完全可以忽略的，我们所不能忍受的仅仅是因为锁调用而引起的阻塞而已。
　　两种方案都是很优秀的优化方案，但也都是有其适用范围的。Ghost Cheng的方案因为提供了多个队列，可以使得多个IO线程可以总工程师的，互不干扰的使用自己的队列，只是还有一个遗留问题我们还不了解其解决方法。 arthur的方案很好的解决了上一个方案遗留的问题，但因为只有一个写队列，所以当想要提供多个IO线程时，线程间互斥地写入数据可能会增大竞争的机会，当然，如果只有一个IO线程那将是非常完美的。
服务器公共组件实现 -- 环形缓冲区
　　消息队列锁调用太频繁的问题算是解决了，另一个让人有些苦恼的大概是这太多的内存分配和释放操作了。频繁的内存分配不但增加了系统开销，更使得内存碎片不断增多，非常不利于我们的服务器长期稳定运行。也许我们可以使用内存池，比如SGI STL中附带的小内存分配器。但是对于这种按照严格的先进先出顺序处理的，块大小并不算小的，而且块大小也并不统一的内存分配情况来说，更多使用的是一种叫做环形缓冲区的方案，mangos的网络代码中也有这么一个东西，其原理也是比较简单的。
　　就好比两个人围着一张圆形的桌子在追逐，跑的人被网络IO线程所控制，当写入数据时，这个人就往前跑；追的人就是逻辑线程，会一直往前追直到追上跑的人。如果追上了怎么办？那就是没有数据可读了，先等会儿呗，等跑的人向前跑几步了再追，总不能让游戏没得玩了吧。那要是追的人跑的太慢，跑的人转了一圈过来反追上追的人了呢？那您也先歇会儿吧。要是一直这么反着追，估计您就只能换一个跑的更快的追逐者了，要不这游戏还真没法玩下去。
　　前面我们特别强调了，按照严格的先进先出顺序进行处理，这是环形缓冲区的使用必须遵守的一项要求。也就是，大家都得遵守规定，追的人不能从桌子上跨过去，跑的人当然也不允许反过来跑。至于为什么，不需要多做解释了吧。
　　环形缓冲区是一项很好的技术，不用频繁的分配内存，而且在大多数情况下，内存的反复使用也使得我们能用更少的内存块做更多的事。
　　在网络IO线程中，我们会为每一个连接都准备一个环形缓冲区，用于临时存放接收到的数据，以应付半包及粘包的情况。在解包及解密完成后，我们会将这个数据包复制到逻辑线程消息队列中，如果我们只使用一个队列，那这里也将会是个环形缓冲区，IO线程往里写，逻辑线程在后面读，互相追逐。可要是我们使用了前面介绍的优化方案后，可能这里便不再需要环形缓冲区了，至少我们并不再需要他们是环形的了。因为我们对同一个队列不再会出现同时读和写的情况，每个队列在写满后交给逻辑线程去读，逻辑线程读完后清空队列再交给IO线程去写，一段固定大小的缓冲区即可。没关系，这么好的技术，在别的地方一定也会用到的。
服务器公共组件实现 -- 发包的方式
　　前面一直都在说接收数据时的处理方法，我们应该用专门的IO线程，接收到完整的消息包后加入到主线程的消息队列，但是主线程如何发送数据还没有探讨过。
　　一般来说最直接的方法就是逻辑线程什么时候想发数据了就直接调用相关的socket API发送，这要求服务器的玩家对象中保存其连接的socket句柄。但是直接send调用有时候有会存在一些问题，比如遇到系统的发送缓冲区满而阻塞住的情况，或者只发送了一部分数据的情况也时有发生。我们可以将要发送的数据先缓存一下，这样遇到未发送完的，在逻辑线程的下一次处理时可以接着再发送。
　　考虑数据缓存的话，那这里这可以有两种实现方式了，一是为每个玩家准备一个缓冲区，另外就是只有一个全局的缓冲区，要发送的数据加入到全局缓冲区的时候同时要指明这个数据是发到哪个socket的。如果使用全局缓冲区的话，那我们可以再进一步，使用一个独立的线程来处理数据发送，类似于逻辑线程对数据的处理方式，这个独立发送线程也维护一个消息队列，逻辑线程要发数据时也只是把数据加入到这个队列中，发送线程循环取包来执行send调用，这时的阻塞也就不会对逻辑线程有任何影响了。
　　采用第二种方式还可以附带一个优化方案。一般对于广播消息而言，发送给周围玩家的数据都是完全相同的，我们如果采用给每个玩家一个缓冲队列的方式，这个数据包将需要拷贝多份，而采用一个全局发送队列时，我们只需要把这个消息入队一次，同时指明该消息包是要发送给哪些socket的即可。有关该优化的说明在云风描述其连接服务器实现的blog文章中也有讲到，有兴趣的可以去阅读一下。
17.3.1  如何处理慢速的连接
对企业级的服务器软件，高性能和可扩展性是基本的要求。除此之外，还应该有应对各种不同环境的能力。例如，一个好的服务器软件不应该假设所有的客户端都有很快的处理能力和很好的网络环境。如果一个客户端的运行速度很慢，或者网络速度很慢，这就意味着整个请求的时间变长。而对于服务器来说，这就意味着这个客户端的请求将占用更长的时间。这个时间的延迟不是由服务器造成的，因此CPU的占用不会增加什么，但是网络连接的时间会增加，处理线程的占用时间也会增加。这就造成了当前处理线程和其他资源得不到很快的释放，无法被其他客户端的请求来重用。例如Tomcat，当存在大量慢速连接的客户端时，线程资源被这些慢速的连接消耗掉，使得服务器不能响应其他的请求了。
前面介绍过，NIO的异步非阻塞的形式，使得很少的线程就能服务于大量的请求。通过Selector的注册功能，可以有选择性地返回已经准备好的频道，这样就不需要为每一个请求分配单独的线程来服务。
在一些流行的NIO的框架中，都能看到对 OP_ACCEPT和OP_READ的处理。很少有对OP_WRITE的处理。我们经常看到的代码就是在请求处理完成后，直接通过下面的代码将结果返回给客户端：
【例17.7】不对OP_WRITE进行处理的样例：
while (bb.hasRemaining()) {
    int len = socketChannel.write(bb);
    if (len < 0) {
        throw new EOFException();
    }
}
这样写在大多数的情况下都没有什么问题。但是在客户端的网络环境很糟糕的情况下，服务器会遭到很沉重的打击。
因为如果客户端的网络或者是中间交换机的问题，使得网络传输的效率很低，这时候会出现服务器已经准备好的返回结果无法通过TCP/IP层传输到客户端。这时候在执行上面这段程序的时候就会出现以下情况。
(1) bb.hasRemaining()一直为“true”，因为服务器的返回结果已经准备好了。
(2) socketChannel.write(bb)的结果一直为0，因为由于网络原因数据一直传不过去。
(3)   因为是异步非阻塞的方式，socketChannel.write(bb)不会被阻塞，立刻被返回。
(4)   在一段时间内，这段代码会被无休止地快速执行着，消耗着大量的CPU的资源。事实上什么具体的任务也没有做，一直到网络允许当前的数据传送出去为止。
这样的结果显然不是我们想要的。因此，我们对 OP_WRITE也应该加以处理。在NIO中最常用的方法如下。
【例17.8】一般NIO框架中对OP_WRITE 的处理：
while (bb.hasRemaining()) {
    int len = socketChannel.write(bb);
    if (len < 0){
        throw new EOFException();
    }
    if (len == 0) {
        selectionKey.interestOps(
                        selectionKey.interestOps() | SelectionKey.OP_WRITE);
        mainSelector.wakeup();
        break;
    }
}
上面的程序在网络不好的时候，将此频道的 OP_WRITE操作注册到Selector上，这样，当网络恢复，频道可以继续将结果数据返回客户端的时候，Selector会通过 SelectionKey来通知应用程序，再去执行写的操作。这样就能节约大量的CPU资源，使得服务器能适应各种恶劣的网络环境。
可是，Grizzly中对OP_WRITE的处理并不是这样的。我们先看看Grizzly的源码吧。在Grizzly中，对请求结果的返回是在ProcessTask中处理的，经过 SocketChannelOutputBuffer的类，最终通过OutputWriter类来完成返回结果的动作。在OutputWriter中处理 OP_WRITE的代码如下：
【例17.9】Grizzly中对OP_WRITE 的处理：
public static long flushChannel(SocketChannel socketChannel,
        ByteBuffer bb, long writeTimeout) throws IOException
{
    SelectionKey key = null;
    Selector writeSelector = null;
    int attempts = 0;
    int bytesProduced = 0;
    try {
        while (bb.hasRemaining()) {
            int len = socketChannel.write(bb);
            attempts++;
            if (len < 0){
                throw new EOFException();
            }
            bytesProduced += len;
            if (len == 0) {
                if (writeSelector == null){
                    writeSelector = SelectorFactory.getSelector();
                    if (writeSelector == null){
                        // Continue using the main one
                        continue;
                    }
                }
                key = socketChannel.register(writeSelector, key.OP_WRITE);
                if (writeSelector.select(writeTimeout) == 0) {
                    if (attempts > 2)
                        throw new IOException("Client disconnected");
                } else {
                    attempts--;
                }
            } else {
                attempts = 0;
            }
        }
    } finally {
        if (key != null) {
            key.cancel();
            key = null;
        }
        if (writeSelector != null) {
            // Cancel the key.
            writeSelector.selectNow();
            SelectorFactory.returnSelector(writeSelector);
        }
    }
    return bytesProduced;
}
上面的程序例17.9与例17.8的区别之处在于：当发现由于网络情况而导致的发送数据受阻(len==0)时，例17.8的处理是将当前的频道注册到当前的Selector中；而在例17.9中，程序从 SelectorFactory中获得了一个临时的Selector。在获得这个临时的Selector之后，程序做了一个阻塞的操作：writeSelector.select(writeTimeout)。这个阻塞操作会在一定时间内(writeTimeout)等待这个频道的发送状态。如果等待时间过长，便认为当前的客户端的连接异常中断了。
这种实现方式颇受争议。有很多开发者置疑 Grizzly的作者为什么不使用例17.8的模式。另外在实际处理中，Grizzly的处理方式事实上放弃了NIO中的非阻塞的优势，使用 writeSelector.select(writeTimeout)做了个阻塞操作。虽然CPU的资源没有浪费，可是线程资源在阻塞的时间内，被这个请求所占有，不能释放给其他请求来使用。
Grizzly的作者对此的回应如下。
(1)   使用临时的Selector的目的是减少线程间的切换。当前的Selector一般用来处理OP_ACCEPT，和OP_READ的操作。使用临时的 Selector可减轻主Selector的负担；而在注册的时候则需要进行线程切换，会引起不必要的系统调用。这种方式避免了线程之间的频繁切换，有利于系统的性能提高。
(2)   虽然writeSelector.select(writeTimeout)做了阻塞操作，但是这种情况只是少数极端的环境下才会发生。大多数的客户端是不会频繁出现这种现象的，因此在同一时刻被阻塞的线程不会很多。
(3)   利用这个阻塞操作来判断异常中断的客户连接。
(4)   经过压力实验证明这种实现的性能是非常好的。

思考的牛

服务器底层的东西还不懂啊。