2010年的6月9日是一个圣战的日子，零点一到就有人开始，好戏也如约在晚上7点发生。人人网战场是SJ的公共主页：http://page.renren.com/sj

对不同人，这个日子意味着不同，滋味也不同。作为人人网技术团队，我们要保证服务能力、用户体验能够应付得了这个挑战。

某一个服务器的能力总有限，为了应付突然增长的读写量，web服务架构、内部服务架构、数据库架构等要能够轻松通过服务器调配来满足。就web服务器而言，我们增加了1倍的机器。现在再回头来看监控的数据，一切显得美好。这个期间整个服务做到了服务能力没有中断。除此之外，在这次圣战中，其中还有一项我们独有的技术起到了重要的作用：rose portal ，下面作一个介绍：

图1是sj的主页：

图1 sj在人人网的公共主页

这个页面分为三列：

• 左边有 “推荐给好友”、“基本信息”、“相册”;
• 中间有“给SJ留言”、“好友留言”;
• 右边有“好友”，“人人的用户还关注”等。

在后台，这些被分解为不同的模块，我们称之为”window”。这每一个window都意味着可能连接一个独立的服务集群，比如基本信息服务、留言服务、好友服务、相册服务等等。这样，一个公共主页就等于多个独立的、可配置的window模块组成，如图2所示 ：

图2 公共主页的window模块组成

随着伟大圣战的深入，这个页面就变成这样(右边的栏目不见了)，如图3所示：

图3 圣战进行中时模块的自动保护

产品同学看到此情此景，仍然很开心：“只要留言的window能在，其它的没在不要紧”

但是不一会，继续恶化，如图4所示：

图4 圣战进行中压力进一步增加

甚至到了图5的情形：

图5 圣战进行中压力进一步增加

黄晶看着公共主页呈现出这种状况时，笑着形容这样的图“缺胳膊少腿”：“怎么还没加机器”。当公共主页技术团队把机器逐步增加一倍的时候，这种情况变少了，甚至就没有了。

虽然这些页面看起来“缺胳膊少腿”，但要知道在以前，这种情况，我们整个页面的某个模块堵了可会导致用户浏览器长期空白，直至最后提示网页不可显示。这给用户带来很不好的体验，同时因为网页一直不释放连接，恶性循环导致web服务器最后全哑了。

好在，早在半年前我们开发了rose portal框架，解决了此问题，rose portal是一个服务端portal技术，基于rose框架 (也就是servlet容器) 下的服务端portal技术，rose portal不是Java常说的portlet技术，也不是基于ajax的客户端portal技术。

rose poral提供这些特性；

1. 能够将一个页面分为多个窗口；
2. 开发者使用一个主控制器，在主控制器中不断通过portal.addWindow方法，将请求并发转发给多个窗口；
3. 每个窗口有单独的控制器处理逻辑、可以返回独立视图就像一个web请求一样；
4. 框架能够处理并发转发、并发逻辑处理、并发渲染，并最后统一返回把html输出给浏览器；
5. 提供了“整体超时控制”手段，使得某个窗口因一时服务能力下降时不影响整个页面的输出；

这里有一个portal开发示例：

http://code.google.com/p/paoding-rose/wiki/Rose_Portal_Demo

献上现在最新的sj主页（2010/6/10 10:46）作为结束，如图6，目前粉丝 粉丝 21w+、留言146w+，谢谢（另感谢李伟博同学，以上图片均是他收集的）：

图6 最新的sj主页

share.renren.com 已经成为人人网上的一大热门应用，优质的内容通过分享在好友间迅速传播。为了提高站外内容的传播效率，我们试图制定出一套开放内容协议(open graph protocol)，任何网页只要遵守该协议，share.renren.com就能从页面上提取最有效的信息并呈现给用户。

下面是协议初稿，有任何意见，请在留言中提出，谢谢！

Protocol Element 协议元素

说明:
1. Null 表示是否允许为空
2. Mult 表示是否允许重复
3. Y 允许
4. N 禁止

Base element 基本类型

人人网中间层：问题篇

人人网中间层：求解篇

面对人人网海量的UGC，数据挖掘工作势在必行，能把用户最想要的信息推荐出来，是我们正在研究的课题之一。在推荐系统中，分类器是个非常重要的部分。

分类器的研究重点落在两个方面，一方面是文本关键词的提取，一方面是对已有关键词或标签的文本进行训练分类。下图为关键词提取在分类器中的位置

下文简单介绍关键词提取常用的方法。

基于词频（TFIDF）统计的方法

思想：常用TFIDF计算文本特征权重，权重高的为关键词，该方法简单，效果也不错。

在实际操作中常会对文本进行聚类处理，计算文本特征权重后，先对文本向量（在聚类操作中，常用文本的句子做为向量单位）利用余弦定理计算文本相似度或距离，然后通过聚类算法，将相似文本聚类。最后在各文本类中选择关键词，合并得出最终结果。这样先通过文本相似度聚类，提高了关键词准确率。下图为k-means聚类算法过程

TFIDF：TF（term frequency）为特征在文本中出现频率，IDF（inverse document frequency）文档中出现该词的频率log(D/Dｗ)，该公式的思想是：特征权重除了和出现频率成正比外，还和文档频率成反比（如果只有文本中包含该特征，则认为该特征更能体现文本的专有特性）。

特征权重=TF*IDF。

特征权重计算方法还有：用于VSM的信息熵算法，基于增益的对TFIDF改进算法算法等。

该方法常结合聚类算法一同使用。

基于词语共现图提取方法

思想：文本中两个特征经常共现在文本的同一段落，则认为两个特征在意义上是相互关联的，共现概率越高，关联越紧密。

由此计算每个特征节点重要性，即与其他特征同现指数连乘，选取最重要的节点作为关键词。

其中最简单的特征同现指数可以用两个特征同现频率表示。

该方法在小规模文本集时并不能很好的反映特征间的关系。

因此文本集的大小会影响算法的稳定性和准确性。

基于词语网络的方法

思想：它是词语共现图的发展，因此与同现图类似，每个特征为网络中的节点，网络的边表示特征间的关系，不同的是该算法引入了图论的模型及算法。

首先要提到最小世界网络（Small-World-Network）这个概念：具有高聚类系数，且平均路径长度短的网络。

其中图的聚类系数为所有节点的(实际边数/最多可能边数)和平均值；

图的平均路径长度即：网络图中,任意两个节点间最短路径边数的平均值。

这种网络和我们以人为节点，人与人之间关系为边，构成的现实世界具有同样的特性：聚类系数高，平均路径短。同理，该模型适用于词语网络。下图为SWN的模型图

在该网络中，特征即为节点，边表示除了前面说的特征同现频率外，还有jaccard系数等计算方法。网络图构建完成后，提取关键词工作即转换为对关键节点的选择。而由于我们认为词语网络是适用于SWN模型的，那关键节点即为影响SWN性质的节点。在现实世界网络中，就相当于去寻找影响社会发展的人，一个公司中的关键人物一样。

通常寻找关键节点的方法有两种，一是直接衡量节点的属性值来判断节点的重要程度，如节点的度(节点到其他节点距离和的倒数)、节点中介性指标（Betweenness Centrality：其他节点间最短路径 经过该节点的概率）等。另一种是通过衡量删除节点后，对SWN性质的破坏程度，即衡量删除节点后聚类系数和平均路径长度的变化，决定该节点的重要度。

本期就先介绍到这里，下期将对词语网络中的一些关键点进行详细介绍，敬请关注文本分析系列！

注：本文纯属个人理解，如有失误，请不吝赐教！

书接上文。

原理篇

Nuclear系统构建于java之上，NIO组件使用Netty，数据序列化使用google的Protocol Buffers，Spring当然是用了的。下图是Nuclear系统内部的一个预览：

嗯……其实这张图对各位看官意义不大，只是罗列出了Nuclear中的各个组件及简单的层次关系。下面着重分析分区、节点增减、路由的原理。

分区

前文讲到，我们是一个分布式的Key-Value存储系统，那么key对应的数据分布在什么节点上，需要遵守一定的规则。熟悉Memecached Client的同学一定清楚一致性Hash的应用，没错，Hash Ring就是我们的不二选择。在Nuclear中，数据分布在0~2⁶⁴的Hash Ring上，Nuclear集群初始化的时候，根据节点数均分整个Hash Ring。如下图所示：

在N=3时，A,B,C三个节点的配置就是系统需要的最少节点了。Nuclear中，顺时针的开始值和结束值确定一个分区管理的数据范围，同时规定分区的范围左开右闭。因此，如上图，我们记录A,B,C分别管理的分区范围是：
A {[c,a],[b, c],[a,b]}
B {[a,b],[c,a],[b,c]}
C {[b,c],[a,b],[c,a]}
可以看出，A处理管理自己的分区数据外，还会把自己管理的数据顺时针往前复制到2(N-1)个节点中。

节点变更

Nuclear增加节点时需要制定目标节点的名称，即增加的节点是用来分担目标节点的负载的。这点不同于Dynamo的分区策略，节点增加的时候会均衡的从现有的节点窃取分区，Nuclear中增加的节点只会影响到邻近的三个节点。加入我们在上面的例子中增加一个新节点N后分区图如下所示：

记录N,A,B,C管理的分区如下：
N {[c,n],[b,c],[a,b]}
A {[n,a],[c,n],[b,c]}
B {[a,b],[n,a],[c,n]}
C {[b,c],[a,b],[n,a]}
Nuclear的分区管理模块将自动的计算出需要同步到N上的数据:
A [a,b] => N
B [b,c] => N
C [c,n] => N
各位看官不难明白，其实就是把A,B,C不再需要的数据挪给新的节点了。删、替换节点原理大同小异，不再冗述。

路由

Nuclear提供服务器端路由策略，Client的请求随机落在Node节点上，由接收到请求的节点处理后续的逻辑。相对于Client端路由来说，优点是Client无需知道Nuclear集群元数据，易于维护；缺点是会造成一定程度的延时，不过我们的测试结果显示延时在可接受范围之内。

两个设计上的Tips贡献给大家:
1. 万事皆异步
我们在编码的过程中走了一些弯路，同步的操作在高并发的情况下带来的性能下降是非常恐怖的，于是乎，Nuclear系统中任何的高并发操作都消除了Block。no waiting, no delay。

2. 根据系统负载控制后台线程的资源占用
Nuclear系统中有不少的后台线程默默无闻的做着各种辛苦的工作，但是它们同样会占用系统资源，我们的解决方案是根据系统负载动态调整线程的运行和停止，并达到平衡。

展望篇

Nuclear中计划在不远的将来(不远有多远?)实现如下功能：

1. Eventually Consistent 最终的一致性问题，在保重数据完整性上至关重要。
2. Async Store 异步数据库存储，各位可以参考：adbcj, async-mysql-connector
3. Read Cache
4. Balance Monitor 建立集群的负载监控体系，在新节点加入的时候可以自动去平衡负载最高的节点。

参考资料：

1. Amazon’s Dynamo
   http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
2. Cassandra
   http://incubator.apache.org/cassandra/
3. Voldemort
   http://project-voldemort.com/

书曰：工欲善其事，必先利其器。人人网作为国内第一大SNS网站，欲存海量UGC数据，必有海量存储系统。Nuclear存储系统在高性能、高可靠、可扩展的海量数据存储需求下横空出世，待小的给列位看官慢慢道来。

缘由篇

看过《人人网使用的开源软件列表》一文的看官一定知道人人网的关系型数据库使用的是MySQL，Key-Value存储使用的是Tokyo Cabinet，话说战斗在第一线的UGC Team的兄弟们发现，MySQL虽然已经被我们用上了散库、散表大法，但是每次数据达到服务器负载临界值时，必然得经过一番迁移数据的剧痛；使用TC也会存在这个问题，且TC只在某些特定的应用场景起作用。于是乎，我们开始需找能满足高性能、高可靠、可扩展等特性，同时能符合UGC应用场景的存储系统，下表列出我们的考察对象及需求。

TC在使用过程中发现单独使用TC会在某些时间点出现性能瓶颈；Voldemort目前的版本对扩展性支持不好；且Voldemort和Casscandra作为一个正在快速开发中的系统，我们尚未有勇气把它引入到生产环境中。追溯到Amazon的Dynamo系统，我们决定在其思想上开发自己的存储系统，Nuclear就是在这样的背景下诞生的。言归正传，给各位道来功能篇及应用篇。

功能篇

高可扩展

一个Nuclear集群支持1到n(n<2⁶⁴)个节点(Node)的规模，每台服务器(Server)支持部署多个节点。当集群资源达到瓶颈时，可以通过增加新的节点来扩展。增加新节点的过程，系统服务无需停止，无需人工干预迁移数据。Nuclear理论上可以无限Scale-Out。

高可靠

单个节点的crash永远对系统的运行造成影响，不存在单点风险。数据的写入参考Dynamo的W+R>N理论，简释之，例如设置系统每一份数据都存储在3个节点上(N=3)，那么读的话必须成功读到两个节点上的数据才认为读成功 (R=2)，写的话必须成功写到两个节点上才认为写成功( W=2)。系统永远可写入(Hinted HandOff)。

高性能

在Xeon E5405 CPU的服务器上，单节点每秒最高2.5w req/s。整个集群的性能取决于一致性级别、N、W、R数及底层存储引擎的选择。例举我们的一个测试数据：
节点数量：4 Node (Server配置： Xeon E5405，16G memory，千兆网卡)
存储引擎：Mysql5.0.45
参数：N=3 W=2 R=2
压力：100 Client Write Request
测试结果：单个Node 15862 req/s，从Client看平均单次请求耗时5ms(见图)， 99.51% 请求耗时 < 50ms

存储

Nuclear本身的数据存储是基于Key-Value形式的，value的形式可以是富数据模型，也可以是List；如果底层的存储引擎是关系型的，那么Nuclear还提供弱结构化的查询功能。下面是Nuclear目前及计划中支持的存储引擎。

*Cassandra我们只使用其底层的存储引擎

应用篇

Nuclear组件介绍

普通节点(Node)
普通节点的职责是接收并处理来自Client的请求，管理该节点上的存储引擎。

中心节点(Seed)
中心节点维护着整个Nuclear集群的拓扑关系(membership)，它熟知每一个节点负责的数据区域。它定时对所有节点进行健康检测，因此熟知每一个节点当前的状态及负责的数据区域。

客户端(Nuclear Client)
提供简单有效的CRUD API。详情如下：
Get
@param key<String>
@param dataID<Long>
@param consistencyLevel
@return ByteString

List
@param key<String>
@param Condition<?>
@param consistencyLevel
@return List<ByteString>

Put
@param key<String>
@param dataID<Long>
@param value<ByteString>
@param consistencyLevel

Replace
同 Put
dataID可选

Delete
@param key<String>
@param dataID<Long>
@param consistencyLevel

NextDataID
@reutrn dataID<Long>

参数详解：
@param dataID<Long> dataID
每一条数据在Nuclear集群中的唯一标示，由系统提供。使用DataID而不是Key作为数据的唯一标示的目的是为了满足Key->List的需求。

@param consistencyLevel
一致性级别，Nuclear系统提供一致性级别选择如下：

书接上文，为了提高性能，在人人网的技术结构中，在数据库和页面之间，有中间层。中间层高性能的基础是用内存代替磁盘。

用内存代替磁盘

数据库系统的最大瓶颈在磁盘IO，大量的小数据请求不是磁盘的强项。人人网中间层服务就是利用了内存代替硬盘的方法来提高整体性能。有了这层服务以后，以前的数据库关联查询被提前计算并缓存，需要访问时直接获取。
通用的Memcached缓存方案也有些不足，数据不能自己变化，也不能部分变化。于是人人网选择了自己实现缓存的方式。
在自己实现缓存的过程中，管理内存相对容易，通信协议是比较复杂的部分，我们在这方面选择了开源的Ice通信框架（http://www.zeroc.com）来完成繁琐的工作，至今它都工作的很好。
Ice通信框架在人人网完成了两件事，通信和定位。客户端通过IceGrid组件定位到需要的服务地址，将请求发送到中间层服务，中间层服务将结果返回。客户端只需要知道一个地址就可以找到所有的服务；同时，众多服务也可以在不同的服务器之间随意迁移。在现在的人人网有超过500个Ice写成的中间层服务在运行。

定制的内存数据

用Ice解决了通信和部署的问题后，中间层服务就是核心的数据结构管理。概括的说，就是灵活变化，保证速度。下面列举若干使用了中间层服务的情况

一份数据 多种排序

在人人网的好友页，有很多排序方式可以显示好友列表。每种列表都是从一个按ID排序的服务中获取的，再经过排序，缓存在各个顺序的列表中。

随时间变化的数据

在很多列表页面，都会显示“在线标志”，这个标志是冗余在各个列表的缓存当中，定期刷新的。这些需要和cache一起实现的业务逻辑，在人人网中间层当中非常普遍。

特殊类型

我们用了一个bit保存用户的激活状态。200M内存可以保存全部int范围的状态。并且查询和更新速度飞快。
接下来的实践篇将会用这个为例子展示中间层的实现。

由开源软件组成的系统

与很多大型的网站一样，人人网的系统全部是由开源软件构建的。使用Nginx做前端接入，resin做容器，Memcached做通用cache，MySQL做数据库，使用Linux操作系统。
除了上述的部分外，人人网还有一个与众不同的中间层。中间层以服务的形式存在，位于MySQL和resin中间，提供高并发低成本的数据访问层。

数据库的压力

在上述结构系统中，数据库的性能往往成为系统瓶颈。人人网在发展的过程中不断重构，改变最大的就是数据库部分。大概的步骤是“优化SQL”，“业务拆分”，“垂直拆分”和“水平拆分”几个阶段，关于数据库优化的细节将来再引用到这里。
经过优化后的数据库，单台可以承担每秒3000次的主键查询。再提高性能的优化，我们采用的方案是使用中间层。

性能目标

增加中间层可以在不增加服务器数量的前提下，提高服务的整体性能，并且提高系统的可扩展性。这里简要列举一些使用中间层服务优化的效果。

实时更新的数据

用户的个人信息数据，目前的写操作500次/秒，读操作2万次/秒。这些数据分布在数十个数据表中，如果用数据库做10次主键查询，需要的时间将会非常可观。中间层的缓存服务把这个性能稳定在了99.9%的请求时间小于20ms。
判断好友关系，读操作900次/秒。这个操作现在使用6G内存存储了所有的好友关系，在2ms内返回任意两人的好友关系。
关联查询，仅好友列表就有1300次/秒。如果使用关联查询，数据库需要同步很多无用的字段。现在只需要两次内存请求，并且衍生出很多种类的排序。

大量聚合的访问

聚合的页面在SNS中是访问量最大的部分。首页集成的功能多达17个模块，这些模块之间的关系相对独立。为了快速的把这些数据集合在一起，就需要迅速获取数据。
我们对整体技术框架的要求是，关键页面执行时间要在100ms以内。

Session同步

众多的resin服务器之间，如何共享用户身份验证的结果，在各种session共享机制中，我们的方案是使用中间层服务来集中存储的。

待续

问题篇只是开端，接下来的“求解篇”将会分析人人网中间层的主要应用场景。“实践篇”将会举例一个典型的中间层服务。

[编者按：求解篇的内容会在下期广播中播出]

小的不才，斗胆发言

多角度定义架构

定义架构的最短形式是：“架构是一种结构”，太棒了，这是一种正确的理解，但世界还没太平。若做一个比喻，架构就像一个操作系统，不同的角度有不同的理解，不同的关切者有各自的着重点，多视点的不同理解都是架构需要的，也只有通过多视点来考察才能演化出一个有效的架构。

从静态的角度，架构要回答一个系统在技术上如何组织；从变化的角度，架构要回答如何支持系统不断产生的新功能、新变化以及适时的重构；从服务质量的角度，架构要平衡各种和用户体验有关的指标；从运维的角度，架构要回答如何充分利用计算机或网络资源及其扩展策略；从经济的角度，架构要回答如何在可行的基础上降低实现成本等等。

没有架构策略的系统，让我诅咒它散掉： 人们不知道如何简单一致地理解，不知道如何加入一个新功能，如何调高或调低某个服务质量指标，如何应付增大的访问，如何提高系统的容错能力或稳定性，如何充分省钱。没有良好架构支持的系统，出来混的迟早要还！我们诅咒他散掉。

如何得到一个良好的架构？
只言片语

像妈妈那样优生

架构所要做的是一个“细节还未完全落实的技术决策，这个决策是一个框架、是一种权衡、是一个路线图”，这个决策规定了整个系统的技术“风格”和后续技术发展方向。

系统的开发是一个从无到有的过程，需要不断地迭代：功能上不断地丰富，技术上不断地完善。如果把一个系统比喻一个人，怎么让这个人不断地往健康、完备的方向成长就是我们的目的了。一开始，这个人并不完善，包括很多器官并不成熟，甚至没有，通过营养的摄入，时间的沉淀，不断地重构最终成功。人也需要重构？！不是吗？血液的60天一变换，牙齿的两次生长等等(注1)，有一个专业术语“新陈代谢”！ 当一个人新陈代谢的能力下降的时候，也就是老了。

在系统从无到有的过程，架构要着眼于未来，落实于现在，规划迭代、优化的路径。这个架构要支持目前最紧迫的任务：“生出来”，也要支持以后能不断地新陈代谢的可能性，两者缺一不可。

像理想那样追求

系统的每个阶段都很重要，一个好的起点并不意味着一直会好下去，制定了各种策略后，贯彻、执行是最重要的课题。没有人一开始就想把一件事情做糟糕，但这个世界就是这样，很多事情都会变坏，越来越不可控。导致如此境地的主观原因就是自己没有设法去维护、坚持、贯彻原先的理想。作为一个程序员或架构员，要不断审视自己开发的系统，主动维护系统的架构，如若发现有对架构产生破坏的地方，应该适时纠正，坚持零容忍。如果不零容忍会怎样？千里之堤溃于蚁穴，我们诅咒他散掉。

谁来做架构？

架构师这样的一个帽子，很多人会闪闪躲躲。

国外多少年的工作经验才可能成就一个架构师，而国内3、5年工作经验的小毛头就说自己是个架构师了。通常认为，架构师理应无所不能，一旦有人被称为架构师，他就应该接受重重的检验。总之，那些自称是架构师的人在冒着道德风险。但，同学们不要胆却，所谓时势造英雄。有人称你是一个英雄，那是因为你被需要，要勇敢地站出来，扮演好自己的角色是对岗位的敬畏。当我把你看成是一位架构师的时候，我需要你不断地给自己暗示，不断地以理想的架构师来要求自己，和同学们在工作中学习，一项一项地突破自己，把工作做好。

一个组织可能会明确地任命一些人为架构师，但大部分的组织可能不会。但在一个项目团队中总有需要有人完成类似的工作，这可能是一个人，也可能是整个团队在商量的气氛中完成。

我的意见是：如果你愿意，你就是架构师！

架构模式

当一个问题、一个系统可以采用很多解决方式来设计时，我们采用什么方式并且以一致的思想、方式解决这个问题时，这就是风格了，当这种风格具有可复用性那就是一种模式了。在编程上，我们有“设计模式”的指导，在架构上，我们也应该总结一些良好的模式出来，应用在不同的情况。关于这方面的资料，目前并不难找。

小的不才，发言结束。请多指教。

注1：周期数字没有核实准确性，但意思已到。

MySQL
关系型数据库存储系统，我们的DBA团队很强大，每人管理上百台MySQL服务器，其他就不多说了，网上资料太多了

Tokyo Cabinet
一个key-value的存储引擎，日本人开发，国内很多公司也开始使用，我们内部很多地方也用它来代替MySQL来做存储，比如我们的搜索结果页的用户资料，就是用它来做一层MySQL外的冗余存储，目的是加快搜索结果页的显示。在key-value并需要持久存储的场景下，用它比MySQL更有效，Cabinet本身只是一个存储引擎，没有网络处理能力，你可以用它作为自己的某个系统的下层存储引擎，更好的是搭配Tokyo Tyrant使用。

Tokyo Tyrant
一个支持Memcached传输协议的网络接口，由Tokyo Cabinet的作者开发，目的是为Tokyo Cabinet提供网络接入能力，即Tokyo Tyrant处理网络连接，协议解析，然后调用Tokyo Cabinet的API来完成持久化存储。

ICE
一个跨语言的网络通讯框架，框架本身提供了强大的通讯能力，管理工具，负载均衡方案，其跨语言能力也是一个很大的亮点，基于这个框架之上，我们选用合适的语言来提供合适的服务，比如我们使用C++来开发Cache服务，使用Java来开发一些逻辑服务。框架本身可以很重，也可以很轻，具体要看你怎么用：）

Memcached
一个纯内存的key-value的cache系统，高效、稳定，使用广泛，如果你连它都没听说过就太out啦，memcached本身不具备分布式能力，需要依靠Client来实现分布，这里强调一点的是，你应该选择一致性Hash来做key的分布。各种语言的client都有，我们使用spymemcached作为java的Client，spymemcached是一个异步的NIO的memcached client，对网络IO的处理非常的精巧，也更加高效，同时因为提供异步操作方式，可以让你对Memcached的操作有更好的控制能力，Memcached到1.4.0版本之后，开始支持binary protocol，spymemcached对其也支持的比较好，使用binary protocol可以提高对协议的解析效率和网络IO的读写效率。
上面说到我们使用ICE自己开发了Cache服务，为什么我们还要用Memcached呢？主要在对Cache的操作粒度不一样，Memcached对Cache对象以binary byte作为一个整体来操作，需要频繁的序列化和反序列化，我们使用ICE提供的Cache服务，可以以Cache对象的一个或者多个字段来操作，比如一个用户对象，我们可以只更新它的姓名，而Memcached

Nginx
高效、稳定的Web Server，我们利用其代理能力，做跨IDC的请求代理，同时也将其和我们的Resin(Java Web 容器)搭配，放在Resin的前面来解决Resin的对网络连接处理能力弱的问题，在一些小地方也用它来做7层的负载均衡

Resin
一个Java Web Server，比Tomcat更高效，是我们主要的Java Web容器

Squid
代理服务器，我们用他来做图片文件的反向代理缓存

LVS
能提供4层的负载均衡，高效、高可用，高并发。我们用他替代了很多硬件的负载均衡设备

Struts
Java web框架，不过这个已经是历史了，我们开发了一套自己的Web框架替代了它，未来我们也会把我们的内部的这套Web框架开源出来

Lucence
基于Java的搜索引擎框架，用它我们构建了一个搜索集群来提供搜人的服务

Netty
一个Java的网络框架，和apache的mina类似，但比mina更高效，我们用来做一些小的服务

Ganglia
一个监控系统，帮组我们了解我们每台Server的资源利用情况

还有些小东西就不列出来了，最后要说的一点就是，对这些开源软件或者系统，我们都非常的了解，或者说知根知底，从API到内部实现原理，甚至到一些源码的细节。