看看mina和memcached的联姻（适合不同语言客户端，高并发？）

[size=medium]/**
* 作者：张荣华
* 日期：2008-07-21
**/

看看mina和memcached的联姻

先来解释一下这两个东东的身世

Mina，是什么？
Minan是一个network 应用框架，她能很方便的帮助用户开发出高性能和高可扩展性的网络应用程序。官方地址请看：http://mina.apache.org/


Memcached是什么？
memcached一个remote cache，它只提供数据存储服务，不过它得java客户端比较不错，还有很多其他语言的客户端，也就是说其周边比较丰富。Memcached的文章太多了，随便一搜一大堆。

现在相信大家对这两个东西有点了解了，接着转入正题吧，我估计猛一看标题，很多童鞋估计都有那么一点云中子的感觉（因为云中子一般在云里或者雾里，所以云中子＝＝云里雾里），从上面的解释来看mina和memcached好像是八竿子打不到一起去的东西。这两个东西怎么能走到一起呢。先看他们能解决什么样的需求。

需求：我们知道，所有的互联网服务几乎都离不开connection这个东东，比如我们打开一个网页，从浏览器发起请求到tomcat接受请求并返回数据，这个过程就开启了一个短连接，数据返回之后这个连接就关闭了，也就是说每个请求其实都是一个新连接的开启和关闭。然后，tomcat中的application向数据库发送一个查询语句，它需要从连接池中拿到一个connection，这个connection一直在pool中，显然这个connection是一个长连接，由此可见一次请求，从浏览器到db再到浏览器既经过了短连接有经过了长连接，我们的生活是离不开连接的。

上面说的这个例子是一个请求的最简单模型，因为我们的application可不只是依赖数据库，尤其在互联网应用中，通常我们的application还依赖于其他的server，比如说我们的互联网应用可能还连接着memcached server，通常，这里也有一个连接池，维护着一堆长连接，那么结束了吗，不，再通常我们的application还依赖于其他的application。好及了，一个相对有点复杂的应用网络，接着往下说，快到重点了

重点：
一般情况下，我们的application依赖于其他application的的时候我们会直接使用http协议，或者再次封装过的http协议(诸如webservice之流)，而且这种情况是大多数情况，但是不是全部情况，因为在互联网上我们会遇到各种各样的需求。因为http连接是短连接，每次发起连接的3次握手不可避免，这是造成其并发量不高的重要原因之一（有的人也许会说，即使http并发高有什么用，你的application还是撑不住，但是我想说的是不是所有的应用都是这样的，只是你没有遇到过而已）。那么假设我有一个数据中心，这个数据中心可以提供common数据的服务，这些common的数据会被网站的各个地方获取，这些common的数据之间可能还有一些计算，我可以通过请求的参数来执行对应的操作，比如查询，统计等等(哇，看来能有效的降低数据库的压力啊)，那么看来memcached是不行了(不能定制计算)，只能自己写这样的应用了，不过以什么样的形势发布接口呢，短连接不行，并发量有限，只能长连接，还要考虑到一点，我的服务的客户端是不定的，有可能是php，也有可能是java，也有可能是python，也有可能是ruby，如何是好啊。

首先长连接是不二选择，高并发，高连接数是我们最中意的，有了这两个特性，我们这个application就可以被其他很多app使用了，就象共享memcached server一样。

其次支持多客户端语言最好是能够有效利用现有资源，比如说不需要自己去开发客户端。

这时候memcached就可以抱着mina出场了。理由：
1 Memcached有众多的客户端，可谓周边齐全，看来非它莫数。
2 mina可以非常方便的开发出server端程序，好姑娘啊。

来吧，看看最简单的示例：
Server端主类：

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.charset.Charset;

import org.apache.mina.common.ByteBuffer;
import org.apache.mina.common.IoAcceptor;
import org.apache.mina.common.SimpleByteBufferAllocator;
import org.apache.mina.filter.codec.ProtocolCodecFilter;
import org.apache.mina.filter.codec.textline.TextLineCodecFactory;
import org.apache.mina.transport.socket.nio.SocketAcceptor;
import org.apache.mina.transport.socket.nio.SocketAcceptorConfig;

/**
 * @author ahuaxuan(aaron zhang)
 * @since 2008-7-21
 * @version $Id$
 */
public class MinaServer {

	private static final int PORT = 11211;
	
	public static void main(String[] args) throws IOException {
		// code will go here next
		ByteBuffer.setUseDirectBuffers(false);
		ByteBuffer.setAllocator(new SimpleByteBufferAllocator());

		IoAcceptor acceptor = new SocketAcceptor();

		SocketAcceptorConfig cfg = new SocketAcceptorConfig();
//		cfg.getFilterChain().addLast("logger", new LoggingFilter());
		cfg.getFilterChain().addLast(
				"codec",
				new ProtocolCodecFilter(new TextLineCodecFactory(Charset
						.forName("UTF-8"))));

		 acceptor.bind(new InetSocketAddress(PORT), new ServerHandler(), cfg);

		 System.out.println("------------ Mina Server start up -----------");
	}

}

这样，启动这个main方法，就可以建立一个socket server的实例了，欢迎大家来连！！！
相当简单啊，再看看一个重要的ServerHandler类
其中有一个重要的方法：

public void messageReceived(IoSession session, Object msg) throws Exception {
		String str = msg.toString();
		String[] parts = str.split(" ");
		if (parts != null && "get".equals(parts[0])) {
			
			StringBuilder sb = new StringBuilder();
			sb.append("VALUE").append(" key ");
			sb.append("1").append(" ");
			sb.append(str.length()).append(" \r\n ");
			sb.append(str + "\r\n").append("");

			//看看这里吧
			session.write(sb.toString());
			session.write("END\r\n");

			System.out.println("Message written..." + sb.toString());
		} else {
			throw new IOException("unsupportoperation");
		}

	}

哟，这么多\r\n，还有”END\r\n”这种东西？不好意思，这个是memcached协议定的我也没有办法（说到这里大家终于知道了本文其实只不过是用mina来实现memcached协议而已，前面被我那么多废话解释弄晕了吧，嘿嘿）。


看到这里，我想要提醒一下，msg通常是这样的get aaabbbccc,其中aaabbbccc是key，但是用在我们自己的server上，它就可以不是key了，比如说它可以是/getDistrict.do?name=xx&cc=yy`````````，server拿到这样的字符串之后，一解析就知道客户端要什么了，那么就可以返回数据了，是我的话我会用json序列化我的对象，然后返回。只是一定要告诉客户端我的数据包括哪些内容，又快并发又高（再次提醒，我的application可以高并行计算，比如说大多数数据都在内存中哦），hoho，而且任何一个客户端语言都可以享受这种服务哦。


     好了，数据成功返回之后，为了让memcached的客户端能够成功解析，我们必须使用memcacached协议，看一段get协议的解释吧（目前主要是使用这个）：

一行取回命令如下：
get <key>*\r\n
<key>* 表示一个或多个键值，由空格隔开的字串
这行命令以后，客户端的等待0个或多个项目，每项都会收到一行文本，然后跟着数据区块。所有项目传送完毕后，服务器发送以下字串：
"END\r\n"来指示回应完毕。

服务器用以下形式发送每项内容：VALUE <key> <flags> <bytes>\r\n
<data block>\r\n
<key> 是所发送的键名
- <flags> 是存储命令所设置的记号
<bytes> 是随后数据块的长度，*不包括* 它的界定符“\r\n”
- <data block> 是发送的数据如果在取回请求中发送了一些键名，而服务器没有送回项目列表，这意味着服务器没这些键名（可能因为它们从未被存储，或者为给其他内容腾出空间而被删除，或者到期，或者被已客户端删除）。



这样就可以了，注意，这里只不过是很简单的测试代码（正式代码不便给出），也只不过是提供一个思路而已，大家如果也需要用到这样的场景可以沿着这个思路走下去。


声明：由于ahuaxuan水平有限，文中难免有不妥之处，希望大家不吝赐教。

ps:如果你没有memcached的客户端，最快的见效的是通过telnet，在windows console里输入telnet localhost 11211，就可以了
[/size]

评论

36 楼 tedeyang 2009-03-05  

ssnake 写道

memcached没有接触过，所以不是很明白楼主这种机制的用处何在。
不过这段时间做的一个项目里面遇到一个问题，大概的场景是这样的，由于客户端太多，因此我在服务端之前加了LVS来做负载均衡，但是这样就遇到了一个问题，客户端连到哪台服务器不是固定的，同时又有另外一个应用（同一个系统内的应用，但不是服务端）需要发消息给客户端，这个应用与各个服务端之间是通过MQ队列来通信的，每次它需要发消息给客户端，就发一个消息到队列里面，每个服务端都阻塞等待队列上消息的到达，因此应用发出来的消息被哪个服务端取到是随机的，但某个服务端取到消息之后，会先检查自己本机上的连接会话表，检查相应的客户端是否连接到本机，如果没有，就需要将消息转发给其他服务端。
最后实现的时候采用了Sun的Shoal来实现分布式的连接会话表，每次在本机的会话表插入记录的时候，会同时在Shoal维持的分布式缓存中插入相应的一条记录，当服务端在本机上的会话表中查不到相应的客户端时，会到Shoal维持的分布式缓存中去查找记录，若是找到记录，则将消息发给客户端当前连接到的那台服务端。

不知道大家有没有用过Shoal？我之所以用它，是因为它是Sun的Glassfish服务器的集群的实现基础，感觉应该性能不会太差，不过在网上貌似找不到测试评论，目前我自己也没有对Shoal的分布式缓存的性能做过测试。
刚搜了一下memcached的资料，感觉memcached也可以用在我上面的解决方案中用来替代Shoal。有没有什么资料对比过memcached和Shoal？

另外，对于我遇到的这个问题，我总感觉我这种解决方案不是太好，不知各位有没有遇到过相类似的场景，有没有什么更好的解决方案呢？

很久的老帖子了，刚才不小心翻到，忍不住要发言，虽然现在时过境迁，已经无效了。
你遇到的这种需求其实与网络底层协议是一致的，譬如局域网的广播机制。
这本质上是个寻址问题，在IP协议里就要解决。
方案如下：发送消息的应用主动推送到所有服务器，服务器接收到消息后比对自己的连接表，如果不存在对应客户则马上丢弃信息，有则响应一下。就这么简单。

35 楼 tonyybupt 2008-11-20  

做个初步的了解还不错。

34 楼 longlongriver 2008-09-07  

如果都是java应用的话，我觉得用nio的通道更高效，目前对nio的有效封装有EJOE，大伙儿如果有兴趣可以去看看！

33 楼 Arden 2008-09-07  

client->minaserver->memcached
楼主的意思是：用minaserver封装成一个业务组件的server，专门用来做业务逻辑处理的一个各个app共用的业务组件？

32 楼 cuiyi.crazy 2008-09-07  

楼主的方案真的不错

用memcached屏蔽语言的差异，用mina实现高速的资源传输---变相的完成了一个从多语言支持和底层传输的改装，确实很好

但是我最近也读过多次内存数据库，尤其是memcachedb（memcached 和 berkeley database结合体）,是否是更佳方案？这个方案我没有去实施，仅仅拿来征求对比的建议

31 楼 txzyhm521 2008-08-25  

我的理解是你想向外部提供一个统一的接口，但外部直接依赖memcached,如果可以改变外部依赖，你就不用在中间弄个server,而是把应用逻辑交给apps（可能你的app有很多，所以做一个server前端转发）。如果是这样的话，长连接体现在哪?你实现的这个server是长连接的？
不知道理解的对不对?

30 楼 bingobird 2008-07-31  

ahuaxuan 写道

bingobird 写道

最后那个性能非常关键，之前我们做过测试，cache型的存取1K的数据耗时在0.7ms，而且与数据包大小呈线性关系。楼主的0.2ms不知是在哪个场景下（请求答应报文大小？）

很显然，我这里出来的是并发之后的结果，并不是单次请求的结果，如果1ms内有5个请求都过来，每个请求实际的请求时间是1ms，那么也就是说1ms之后，5个请求都返回了，所以，平均下来一个请求就是0.2ms了


你说的cache型存取用的是什么cache，是local cache还是memcached之类内，而且你这个数据是怎么看出来的，单线程计算平均还是通过jprofile之类的内，如果是后者，那么你这个测试结果就是不准确的，jprofile在测试的时候速度会降低很多

0.7ms是采用memcache在多线程情况下的处理能力(pc)，测试结果是通过简单地压力测试取平均值的做法。即每秒处理1400左右的请求（包长1k）。当报文长度为100字节，每秒处理数也会上升到1w。
因此我对ahuaxuan测试用例中的报文长度比较关心。如果0.2ms是基于100字节以上的报文交换，那还是不错的。

29 楼 downpour 2008-07-30  

ahuaxuan 写道

bingobird 写道

最后那个性能非常关键，之前我们做过测试，cache型的存取1K的数据耗时在0.7ms，而且与数据包大小呈线性关系。楼主的0.2ms不知是在哪个场景下（请求答应报文大小？）

很显然，我这里出来的是并发之后的结果，并不是单次请求的结果，如果1ms内有5个请求都过来，每个请求实际的请求时间是1ms，那么也就是说1ms之后，5个请求都返回了，所以，平均下来一个请求就是0.2ms了


你说的cache型存取用的是什么cache，是local cache还是memcached之类内，而且你这个数据是怎么看出来的，单线程计算平均还是通过jprofile之类的内，如果是后者，那么你这个测试结果就是不准确的，jprofile在测试的时候速度会降低很多

我倒是觉得，一个重要的测试数据标准是这个Server在同1秒内能够接受的最大连接数。

28 楼 ahuaxuan 2008-07-30  

bingobird 写道

最后那个性能非常关键，之前我们做过测试，cache型的存取1K的数据耗时在0.7ms，而且与数据包大小呈线性关系。楼主的0.2ms不知是在哪个场景下（请求答应报文大小？）

很显然，我这里出来的是并发之后的结果，并不是单次请求的结果，如果1ms内有5个请求都过来，每个请求实际的请求时间是1ms，那么也就是说1ms之后，5个请求都返回了，所以，平均下来一个请求就是0.2ms了


你说的cache型存取用的是什么cache，是local cache还是memcached之类内，而且你这个数据是怎么看出来的，单线程计算平均还是通过jprofile之类的内，如果是后者，那么你这个测试结果就是不准确的，jprofile在测试的时候速度会降低很多

27 楼 bingobird 2008-07-30  

ahuaxuan 写道

fanzaiqiang 写道

从memecached server中存取数据都非常快速,因而连接都很短暂,短暂的连接可以满足较高的并发

你这个结论是从哪里得出来得？

如果是短连接每次请求都要开连接，你觉得并发会高吗，比如你访问tomcat，你得tomcat支持多少

fanzaiqiang 写道

如果想在服务器端支持条件查询,个人觉得这种方式对查询的支持毕竟有限,还不如推翻memcached,引入内存数据库机制实现分布式缓存,并支持强大的查询(SQL).

我不就是抛弃了memcached server吗（其实不是抛弃，而是不同得场景选择不同得技术而已）？
难道我说得不够清楚，有空再写一篇文章把


－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

随便提供一下我得测试结果（基础框架：xwork2.0+mina1.17+spring2.5）

每秒钟支持得请求数量为5500次(而且我觉得测试得客户端不够，否则这个数字还可以更大)，也就是平均0.2ms就可以处理返回，这个统计是客户端得统计，也就是包括网络消耗在内平均一个请求是0.2ms

最后那个性能非常关键，之前我们做过测试，cache型的存取1K的数据耗时在0.7ms，而且与数据包大小呈线性关系。楼主的0.2ms不知是在哪个场景下（请求答应报文大小？）

26 楼 ahuaxuan 2008-07-29  

fanzaiqiang 写道

从memecached server中存取数据都非常快速,因而连接都很短暂,短暂的连接可以满足较高的并发

你这个结论是从哪里得出来得？

如果是短连接每次请求都要开连接，你觉得并发会高吗，比如你访问tomcat，你得tomcat支持多少

fanzaiqiang 写道

如果想在服务器端支持条件查询,个人觉得这种方式对查询的支持毕竟有限,还不如推翻memcached,引入内存数据库机制实现分布式缓存,并支持强大的查询(SQL).

我不就是抛弃了memcached server吗（其实不是抛弃，而是不同得场景选择不同得技术而已）？
难道我说得不够清楚，有空再写一篇文章把


－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

随便提供一下我得测试结果（基础框架：xwork2.0+mina1.17+spring2.5）

每秒钟支持得请求数量为5500次(而且我觉得测试得客户端不够，否则这个数字还可以更大)，也就是平均0.2ms就可以处理返回，这个统计是客户端得统计，也就是包括网络消耗在内平均一个请求是0.2ms

25 楼 fanzaiqiang 2008-07-29  

从memecached server中存取数据都非常快速,因而连接都很短暂,短暂的连接可以满足较高的并发,LZ增加了一个MINA不知道有多大的好处.

如果想在服务器端支持条件查询,个人觉得这种方式对查询的支持毕竟有限,还不如推翻memcached,引入内存数据库机制实现分布式缓存,并支持强大的查询(SQL).


供大家讨论!

24 楼 robertpi 2008-07-28  

不错，不错，其实就是开发一个支持“标准”协议的stocket server。
关键在于究竟标不标准，因为一个企业都不止一家开发商，不能保证能认同这个，如果都是是自己做，用lz方案不错，省得自己写协议和客户端了。

23 楼 bingobird 2008-07-25  

很不错的东东，比较适用于大型网站的业务模块间调用。
Hession的调用开销超过2ms,php与java间更是需要10几ms，还是有些大的。WS就更夸张了。
这种方式在性能不错的同时，还可以通过memcache的多语言支撑来解决传统socket调用的对象序列化问题。

不过调用的接口定义需要自行封装，以及楼主提的几个顾虑，性能、稳定性、中心化等也是要考虑的。

至于ice我认为比mina应用领域广，但对JAVA的支撑没有mina好。

22 楼 elvewyn 2008-07-25  

javaeyename 写道

memcached的java客户端好像可以设置连接池呀！这个连接池里的东西不就是长连接吗？

连接池的并发性能应该比不上NIO这种机制的并发性能。

21 楼 downpour 2008-07-25  

相当于一个大家都可以访问的数据中心。只是这个数据中心到底从哪里去拿数据的实现被有效屏蔽了。

不过和ahuaxuan讨论后，认为这个Server有一些比较硬性的指标：

1. 考虑到其目的是采用长连接来优化由于短连接造成的效率问题，那么其内部的取数据的实现逻辑不应过于复杂。否则反而会成为瓶颈。

2. 这个server的比较常见的逻辑是针对一些只读表，做统计等逻辑封装。当只读表信息越来越多时，Server可能需要拆分成多个Server进行处理。否则，一个Server可能会承载过多的模块。

3. 当这个数据中心被启用后，可能越来越多的系统会依赖于它，而且这个数据中心所管理的数据多数是Master Data。所以相对而言，这个数据中心是不能当掉的。

20 楼 SteveGY 2008-07-25  

我要是没有理解错的话，messageReceived提供了一种可能性，各位可以拿来重写，变成自己想要的任何数据提供服务程序，这个服务使用memcached协议，这个还是很有趣的，关键是messageReceived函数要做的事情，LZ提供了一个思路，对application group内部大量使用memcached客户端的场景，提供长连接的数据服务，呵呵，貌似很适合短信一类的服务场景。
换句话说，这样的服务可以使用现有的memcached客户端，省掉了私有协议的客户端开发工作，这个很棒。

19 楼 dennis_zane 2008-07-24  

nickcen 写道

dennis_zane 写道

nickcen 写道

感觉就是用nio实现了一个memcache的java client吧。跟多语言一点关系都没有把。

是吗？你认真看了吗？

楼主这个思路可以作为WS、REST的替代品，做内部应用（异构同构皆可）间的交互。

多语本来就是memcache自己就能做到的。需要mina掺和吗？

内部应用会有很多异构吗？而且不要把Cache太泛化了，这东西跟WS，REST不是一个概念，不要玩弄概念了。

无语了，您想争论至少搞明白楼主在说什么？太无语了。人家根本不是在说cache，只是借memcached协议这个壳。

18 楼 ahuaxuan 2008-07-24  

nickcen 写道

对的，是我看错了，这是服务器端，你用mina实现了一个能响应memcache get请求的server。你的这个server能比memcached的性能好？有report？

如果你有兴趣，我当然愿意和你讨论下去，不过前提是你需要理解我在说什么，否则就讨论不到一块儿去了。

引用

首先谢谢大家的回帖，该贴质量的提高正式得益于你们的回帖，下面我进一步阐述我的观点

codeutil 写道
已经有现成的jmemcached，也是基于mina：

http://www.thimbleware.com/projects/jmemcached


linzongkao 写道
已经有现成的GMemcached，是基于Grizzly：

http://code.google.com/p/gmemcached/

谢谢两位给出jmemcached和gmemcached的介绍连接，让我们开阔了眼界，但是我的想法不是完全再次实现一个memcached server，因为我觉得这样做意义不大，现有的c版本的memcached 的server已经是非常的优秀了。只不过memcached的server不能适合一些特殊场景，就是我文中提到的那些，所以我并不是实现了一个 memcached server，我只是利用memcached的协议而已，这样做的好处是能利用memcached的丰富的周边（比如说现成的多语言客户端）。

从我上面这段回帖就已经可以看出，本文并不是要实现一个一摸一样的memcached server，我已经说的很清楚很明了，还要我怎么说。

javaeyename 写道

memcached的java客户端好像可以设置连接池呀！这个连接池里的东西不就是长连接吗？

这篇文章并没有说是开发客户端的东西，跟客户端没有直接联系。

17 楼 javaeyename 2008-07-24  

memcached的java客户端好像可以设置连接池呀！这个连接池里的东西不就是长连接吗？