通过NIO实现Memcached multi get

Memcached（简称为：MC）在互联网广泛使用，是最基础的架构。但MC的mget（即一次获取多个值）一直是一个难题，我们的要求是mget性能上要尽量接近普通memcache get。下面通过一段伪代码介绍了如何以接近get single value的性能实现mget，并且就该架构在实际环境中遇到的一些问题加以讨论。

场景

在开始这个话题之前先考虑一个问题，为什么需要MC mget？Redis不是已经很好的实现了list，hashset，hashtable，zset等等丰富的数据结构吗？这个问题需要从本厂的应用场景开始。用户登陆之后会修改自己的状态，同时获得自己关注人的状态。修改自己的状态是一次MC set过程。自己的关注人列表可以从Redis中获得，此时key是用户的uid，value是关注任的list。获得自己关注人的状态则是根据关注人uid的一次MC get，时间复杂度是O(1)。可以这样做，在程序中执行一个for循环，依次从MC中get关注人状态，这个get过程的时间复杂度是O(n)。当关注人列表扩展到2000时，每次MC get平均耗时2~5ms，这种线性循环获取好友状态的办法要耗时10s，是完全无法接受的。怎么解决这个问题呢？

通过NIO实现mget，并发的执行MC get

danga.memcached2.0.1已经使用NIO框架来实现mget，但是它的实现有些问题，参考：http://blog.youkuaiyun.com/e_wsq/article/details/7876801。mget伪代码如下：

private final class Conn {
	public ByteBuffer outgoing;
	// 使用一个ByteBuffer list来存储从MC读出的内容
	public List<ByteBuffer> incoming = new ArrayList<ByteBuffer>();

	public Conn(Selector selector) {
		channel = getSock().getChannel();
		channel.configureBlocking( false );
		channel.register( selector, SelectionKey.OP_WRITE | SelectionKey.OP_READ, this );

		outgoing = ByteBuffer.wrap( request.append( "\r\n" ).toString().getBytes() );
	}

	public boolean isFinished() {
		// judge if get "END\r\n"
	}

	public ByteBuffer getBuffer() {
		int last = incoming.size()-1;
		if ( last >= 0 && incoming.get( last ).hasRemaining() ) {
			return incoming.get( last );
		}
		else {
			ByteBuffer newBuf = ByteBuffer.allocate( 8192 );
			incoming.add( newBuf );
			return newBuf;
		}
	}
}

public Object getMulti() throws Exception {
	selector = Selector.open();
	Conn conn = new Conn(selector);

   try {
		while(timeRemaining) {
			int n = selector.select(timeout));
			if ( n > 0 ) {
				Iterator<SelectionKey> it = selector.selectedKeys().iterator();
			   	while ( it.hasNext() ) {
			      SelectionKey key = it.next();
			      it.remove();

			      if ( key.isReadable() )
						readResponse( key );
					else if ( key.isWritable() )
						writeRequest( key );
			   }
			}
			else {
				// error...
			}

			timeRemaining = timeout - (SystemTimer.currentTimeMillis() - startTime);
		}
	}
	finally {
		selector.close();
	}
}

public void writeRequest( SelectionKey key ) throws IOException {
	ByteBuffer buf = ((Conn) key.attachment()).outgoing;
	SocketChannel sc = (SocketChannel)key.channel();

	if ( buf.hasRemaining() ) {
		sc.write( buf );
	}

	if ( !buf.hasRemaining() ) {
	   // switching to read mode for server
		key.interestOps( SelectionKey.OP_READ );
	}
}

public void readResponse( SelectionKey key ) throws IOException {
	Conn conn = (Conn)key.attachment();
	ByteBuffer buf = conn.getBuffer();
	int count = conn.channel.read( buf );
	if ( count > 0 ) {
		if ( log.isDebugEnabled() )
			log.debug( "read  " + count + " from " + conn.channel.socket().getInetAddress() );

		if ( conn.isFinished() ) {
			...
			return;
		}
	}
}

 

伪代码中主要给出了NIO中的一些逻辑。并发mget的好处是非常明显的，但这段代码有几个明显的坑。

mget伪代码的几个坑

1. Too many open files的坑

每次getMulti都执行Selector.open()?? Linux系统中，执行Selector.open()打开一对pipe（参考：http://blog.youkuaiyun.com/haoel/article/details/2224055），当后续IO慢时，Selector就不能及时关闭。造成大量pipe被创建，导致Too many open files错误。一般NIO的逻辑是只有一个全局selector，新channel注册后只需selector.wakeup() 即可。

2. 死循环的坑

Java6 NIO有两个众所周知的坑：http://bugs.sun.com/view_bug.do?bug_id=6693490和http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933。简单的说，就是Selector应该只在2种情况有返回值，即有网络事件发生或者超时。但是Selector有时却会在没有获得任何selectionKey的情况返回，这是一个Java6 NIO的bug。上面这段mget的伪代码中没有相关处理，容易造成死循环。我们可以参考MINA的解决方法，伪代码如下：

long t0 = System.currentTimeMillis();
int selected = select(1000L);
long t1 = System.currentTimeMillis();
long delta = (t1 - t0);

if ((selected == 0) && !wakeupCalled.get() && (delta < 100)) {
    // Last chance : the select() may have been
    // interrupted because we have had an closed channel.
    if (isBrokenConnection()) {
        LOG.warn("Broken connection");

        // we can reselect immediately
        // set back the flag to false
        wakeupCalled.getAndSet(false);

        continue;
    } else {
        LOG.warn("Create a new selector. Selected is 0, delta = " + (t1 - t0));
        // Ok, we are hit by the nasty epoll
        // spinning.
        // Basically, there is a race condition
        // which causes a closing file descriptor not to be
        // considered as available as a selected channel, but
        // it stopped the select. The next time we will
        // call select(), it will exit immediately for the same
        // reason, and do so forever, consuming 100%
        // CPU.
        // We have to destroy the selector, and
        // register all the socket on a new one.
        registerNewSelector();
    }

    // Set back the flag to false
    wakeupCalled.getAndSet(false);

    // and continue the loop
    continue;
}

 

这段代码非常清晰，触发条件是selector返回值为0，网络没有断开，并且时间<100ms就认为是触发了Java NIO的bug。处理的方法就是重建一个selector。另外一个可以参考的例子是Jetty的处理方法：http://wiki.eclipse.org/Jetty/Feature/JVM_NIO_Bug