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

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

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

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

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

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

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

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

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

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

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

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

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

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


供大家讨论!

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

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


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


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

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

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

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

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


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

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