通过上一篇总结Hadoop中的集群环境配置和使用技巧的介绍，我们就假设已经拥有了一个可运行的Hadoop集群环境。以下的这篇文章主要是用python实现hadoop中的map/reduce查询。原文链接：http://slaytanic.blog.51cto.com/2057708/731750

条件，假设你已经装好了hadoop集群，配好了hdfs并可以正常运行。

$hadoop dfs -ls /data/dw/explorer
Found 1 items
drwxrwxrwx     - rsync supergroup                    0 2011-11-30 01:06 /data/dw/explorer/20111129


$ hadoop dfs -ls /data/dw/explorer/20111129
Found 4 items
-rw-r--r--     3 rsync supergroup     12294748 2011-11-29 21:10 /data/dw/explorer/20111129/explorer_20111129_19_part-00000.lzo
-rw-r--r--     3 rsync supergroup             1520 2011-11-29 21:11 /data/dw/explorer/20111129/explorer_20111129_19_part-00000.lzo.index
-rw-r--r--     3 rsync supergroup     12337366 2011-11-29 22:09 /data/dw/explorer/20111129/explorer_20111129_20_part-00000.lzo
-rw-r--r--     3 rsync supergroup             1536 2011-11-29 22:10 /data/dw/explorer/20111129/explorer_20111129_20_part-00000.lzo.index

#!/usr/bin/python
#-*-coding:UTF-8 -*-
import sys
import cElementTree

debug = False#设置lzo文件偏移位
if debug:
        lzo = 0
else:
        lzo = 1

for line in sys.stdin:
        try:
                flags = line[:-1].split('\t')
#hadoop查询走标准输入，数据以\t分隔，去掉每行中的\n
                if len(flags) == 0:
                        break
                if len(flags) != 11+lzo:
#hadoop采用lzo则偏移位+1，lzo设置为False则+1
                        continue
                stat_date=flags[0+lzo]#日期
                stat_date_bar = stat_date[:4]+"-"+stat_date[4:6]+'-'+stat_date[6:8]#拼成2011-11-29格式
                version = flags[4+lzo]
                xmlstr = flags[10+lzo]
                #xmlstr=line
                dom = cElementTree.fromstring(xmlstr)
#xml字段对象，以下均为取值操作
                uuid = dom.attrib['UUID']
                node = dom.find('UserDoubleClick')
                associateKey=node.get('AssociateKey')
                associateKeys=associateKey.split('.')
                player = associateKeys[0]
                fileext=node.get('FileExt')
                count=node.get('Count')
                print stat_date_bar+','+version+','+fileext+','+player+','+associateKey+'\t'+count
#输出map后的数据，这里map不对数据做任何处理，只做取值，拼接操作
#将\t前的字符串作为key输入reduce，\t后的count作为reduce计算用的value
except Exception,e:
print e
#抛出异常 

#!/usr/bin/python
#-*-coding:UTF-8 -*-
import sys
import cElementTree
import os
import string

res = {}

for line in sys.stdin:
        try:
                flags = line[:-1].split('\t')
#拆分\t以获得map传过来的key和value
                if len(flags) != 2:
#\t切割后，如果数据有问题，元素多于2或者少于2则认为数据不合法，跳出继续下一行
                        continue
                skey= flags[0]
#取出第一个元素作为key
                count=int(flags[1])
#取出第二个元素作为value
                if res.has_key(skey) == False:
                        res[skey]=0
                res[skey] += count
#计算count总和
        except Exception,e:
                pass
#不抛出，继续执行

for key in res.keys():
        print key+','+'%s' % res[key]
#格式化输出，以放入临时文件

#!/bin/sh

[ $1 ] && day=$1 DATE=`date -d "$1" +%Y%m%d`
[ $1 ] || day=`date -d "1 day ago" +%Y%m%d`     DATE=`date -d "1 day ago" +%Y%m%d`
#取昨天日期

cd /opt/modules/hadoop/hadoop-0.20.203.0/
#进入hadoop工作目录
bin/hadoop jar contrib/streaming/hadoop-streaming-0.20.203.0.jar -file /home/rsync/explorer/explorer_map.py -file /home/rsync/explorer/explorer_red.py -mapper /home/rsync/explorer/explorer_map.py -reducer /home/rsync/explorer/explorer_red.py -inputformat com.hadoop.mapred.DeprecatedLzoTextInputFormat -input /data/dw/explorer/$DATE -output /tmp/explorer_$DATE
#执行map/reduce，并将排序完结果放入hdfs:///tmp/explorer

bin/hadoop fs -copyToLocal /tmp/explorer_$DATE /tmp
#将m/r结果从hdfs://tmp/explorer_$DATE 保存到本地/tmp下
bin/hadoop dfs -rmr /tmp/explorer_$DATE
#删除hdfs下临时文件夹

cd
#返回自身目录
cd explorer
#进入explorer文件夹
./rm.py $DATE
执行入库和删除临时文件夹脚本

#!/usr/bin/python

import os
import sys
import string

if len(sys.argv) == 2:
                date = sys.argv[1:][0] #取脚本参数
                os.system ("mysql -h192.168.1.229 -ujobs -p223238 -P3306    bf5_data    -e \"load data local infile '/tmp/explorer_"+date+"/part-00000' into table explorer FIELDS TERMINATED
BY '\,' (stat_date,ver,FileExt,player,AssociateKey,count)\"")#执行入库sql语句，并用load方式将数据加载到统计表中
                os.system ("rm -rf /tmp/explorer_"+date)#删除map/reduce过的数据
else:
                print "Argv error"

#因为没有安装MySQLdb包，所以用运行脚本的方式加载数据。

20111129/23:59:54 111.161.25.184 182.132.25.243 <Log_Explorer ProductVer="5.05.1026.1111" UUID="{C9B80A9B-704E-B106-9134-1ED3581D0123}"><UserDoubleClick FileExt="mp3" AssociateKey="Audio.mp3" Count="1"/></Log_Explorer>

-----------------------------------------------------------

2011-11-29,5.05.1026.1111,mp3,Audio,Audio.mp3,1

#将hadoop中的数据文本copy出来一个，lzo需要解压缩，然后将map中的debug模式置为True，也就是不加hadoop中的lzo偏移量。
#用head输入hadoop里的文件，通过管道操作放入map/reduce中执行，看输出结果

$head explorer_20111129 | explorer_map.py | explorer_red.py

本文主要是和大家一起探讨Hadoop的集群配置（并非在单机上）的一些细节，通过对这些细节的详细描述，希望能帮助大家轻松搭建Hadoop集群环境，为搭建高性能Web打下坚实的基础。让我们一起来看看吧，原文如下：

环境

7台普通的机器，操作系统都是Linux。内存和CPU就不说了，反正Hadoop一大特点就是机器在多不在精。JDK必须是1.5以上的，这个切记。7台机器的机器名务必不同，后续会谈到机器名对于MapReduce有很大的影响。

部署考虑

正如上面我描述的，对于Hadoop的集群来说，可以分成两大类角色：Master和Slave，前者主要配置NameNode和 JobTracker的角色，负责总管分布式数据和分解任务的执行，后者配置DataNode和TaskTracker的角色，负责分布式数据存储以及任 务的执行。本来我打算看看一台机器是否可以配置成Master，同时也作为Slave使用，不过发现在NameNode初始化的过程中以及 TaskTracker执行过程中机器名配置好像有冲突（NameNode和TaskTracker对于Hosts的配置有些冲突，究竟是把机器名对应 IP放在配置前面还是把Localhost对应IP放在前面有点问题，不过可能也是我自己的问题吧，这个大家可以根据实施情况给我反馈）。最后反正决定一 台Master，六台Slave，后续复杂的应用开发和测试结果的比对会增加机器配置。

实施步骤

1. 在所有的机器上都建立相同的目录，也可以就建立相同的用户，以该用户的home路径来做hadoop的安装路径。例如我在所有的机器上都建立了/home/wenchu。
2. 下载Hadoop，先解压到Master上。这里我是下载的0.17.1的版本。此时Hadoop的安装路径就是/home/wenchu/hadoop-0.17.1。
3. 解压后进入conf目录，主要需要修改以下文件：hadoop-env.sh，hadoop-site.xml、masters、slaves。

   Hadoop的基础配置文件是hadoop-default.xml，看Hadoop的代码可以知道，默认建立一个Job的时候会建立Job的Config，Config首先读入hadoop-default.xml的配置，然后再读入hadoop-site.xml的配置（这个文件初始的时候配置为空），hadoop-site.xml中主要配置你需要覆盖的hadoop-default.xml的系统级配置，以及你需要在你的MapReduce过程中使用的自定义配置（具体的一些使用例如final等参考文档）。

   以下是一个简单的hadoop-site.xml的配置：

   <?xml version="1.0"?>
   <?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
   <!-- Put site-specific property overrides in this file. -->
   <configuration>
   <property>
      <name>fs.default.name</name>//你的namenode的配置，机器名加端口
      <value>hdfs://10.2.224.46:54310/</value>
   </property>
   <property>
      <name>mapred.job.tracker</name>//你的JobTracker的配置，机器名加端口
      <value>hdfs://10.2.224.46:54311/</value>
   </property>
   <property>
      <name>dfs.replication</name>//数据需要备份的数量，默认是三
      <value>1</value>
   </property>
   <property>
       <name>hadoop.tmp.dir</name>//Hadoop的默认临时路径，这个最好配置，如果在新增节点或者其他情况下莫名其妙的DataNode启动不了，就删除此文件中的tmp目录即可。不过如果删除了NameNode机器的此目录，那么就需要重新执行NameNode格式化的命令。
       <value>/home/wenchu/hadoop/tmp/</value>
   </property>
   <property>
      <name>mapred.child.java.opts</name>//java虚拟机的一些参数可以参照配置
      <value>-Xmx512m</value>
   </property>
   <property>
     <name>dfs.block.size</name>//block的大小，单位字节，后面会提到用处，必须是512的倍数，因为采用crc作文件完整性校验，默认配置512是checksum的最小单元。
     <value>5120000</value>
     <description>The default block size for new files.</description>
   </property>
   </configuration>

   hadoop-env.sh文件只需要修改一个参数：
   

   # The java implementation to use.  Required.
    export JAVA_HOME=/usr/ali/jdk1.5.0_10

   配置你的Java路径，记住一定要1.5版本以上，免得莫名其妙出现问题。

   Masters中配置Masters的IP或者机器名，如果是机器名那么需要在/etc/hosts中有所设置。Slaves中配置的是Slaves的IP或者机器名，同样如果是机器名需要在/etc/hosts中有所设置。范例如下，我这里配置的都是IP：

   Masters:
    10.2.224.46
   
     Slaves:
    10.2.226.40
    10.2.226.39
    10.2.226.38
    10.2.226.37
    10.2.226.41
    10.2.224.36

4. 建立Master到每一台Slave的SSH受信证书。由于Master将会通过SSH启动所有Slave的Hadoop，所以需要建立单向或者双向证书保证命令执行时不需要再输入密码。在Master和所有的Slave机器上执行：ssh-keygen -t rsa。执行此命令的时候，看到提示只需要回车。然后就会在/root/.ssh/下面产生id_rsa.pub的证书文件，通过scp将Master机器上的这个文件拷贝到Slave上（记得修改名称），例如：scp root@masterIP:/root/.ssh/id_rsa.pub /root/.ssh/46_rsa.pub，然后执行cat /root/.ssh/46_rsa.pub >>/root/.ssh/authorized_keys，建立authorized_keys文 件即可，可以打开这个文件看看，也就是rsa的公钥作为key，user@IP作为value。此时可以试验一下，从master ssh到slave已经不需要密码了。由slave反向建立也是同样。为什么要反向呢？其实如果一直都是Master启动和关闭的话那么没有必要建立反 向，只是如果想在Slave也可以关闭Hadoop就需要建立反向。
5. 将Master上的Hadoop通过scp拷贝到每一个Slave相同的目录下，根据每一个Slave的Java_HOME的不同修改其hadoop-env.sh。
6. 修改Master上/etc/profile：
   新增以下内容：（具体的内容根据你的安装路径修改，这步只是为了方便使用）
   

   export HADOOP_HOME=/home/wenchu/hadoop-0.17.1
   export PATH=$PATH:$HADOOP_HOME/bin

   修改完毕后，执行source /etc/profile来使其生效。
7. 在Master上执行Hadoop namenode –format，这是第一需要做的初始化，可以看作格式化吧，以后除了在上面我提到过删除了Master上的hadoop.tmp.dir目录，否则是不需要再次执行的。
8. 然后执行Master上的start-all.sh，这个命令可以直接执行，因为在6中已经添加到了path路径，这个命令是启动hdfs和mapreduce两部分，当然你也可以分开单独启动hdfs和mapreduce，分别是bin目录下的start-dfs.sh和start-mapred.sh。
9. 检查Master的logs目录，看看Namenode日志以及JobTracker日志是否正常启动。
10. 检查Slave的logs目录看看Datanode日志以及TaskTracker日志是否正常。
11. 如果需要关闭，那么就直接执行stop-all.sh即可。

以上步骤就可以启动Hadoop的分布式环境，然后在Master的机器进入Master的安装目录，执行hadoop jar hadoop-0.17.1-examples.jar wordcount输入路径和输出路径，就可以看到字数统计的效果了。此处的输入路径和输出路径都指的是HDFS中的路径，因此你可以首先通过拷贝本地文件系统中的目录到HDFS中的方式来建立HDFS中的输入路径：

hadoop dfs -copyFromLocal /home/wenchu/test-in test-in。其中/home/wenchu/test-in是本地路径，test-in是将会建立在HDFS中的路径，执行完毕以后可以通过hadoop dfs –ls看到test-in目录已经存在，同时可以通过hadoop dfs –ls test-in查看里面的内容。输出路径要求是在HDFS中不存在的，当执行完那个demo以后，就可以通过hadoop dfs –ls 输出路径看到其中的内容，具体文件的内容可以通过hadoop dfs –cat文件名称来查看。

经验总结和注意事项（这部分是我在使用过程中花了一些时间走的弯路）：

1. Master和Slave上的几个conf配置文件不需要全部同步，如果确定都是通过Master去启动和关闭，那么Slave机器上的配置不需要去维护。但如果希望在任意一台机器都可以启动和关闭Hadoop，那么就需要全部保持一致了。
2. Master和Slave机器上的/etc/hosts中必须把集群中机器都配置上去，就算在各个配置文件中 使用的是IP。这个吃过不少苦头，原来以为如果配成IP就不需要去配置Host，结果发现在执行Reduce的时候总是卡住，在拷贝的时候就无法继续下 去，不断重试。另外如果集群中如果有两台机器的机器名如果重复也会出现问题。
3. 如果在新增了节点或者删除节点的时候出现了问题，首先就去删除Slave的hadoop.tmp.dir，然后重新启动试试看，如果还是不行那就干脆把Master的hadoop.tmp.dir删除（意味着dfs上的数据也会丢失），如果删除了Master的hadoop.tmp.dir，那么就需要重新namenode –format。
4. Map任务个数以及Reduce任务个数配置。前面分布式文件系统设计提到一个文件被放入到分布式文件系统中，会被分割成多个block放置到每一个的DataNode上，默认dfs.block.size应该是64M，也就是说如果你放置到HDFS上的数据小于64，那么将只有一个Block，此时会被放置到某一个DataNode中，这个可以通过使用命令：hadoop dfsadmin –report就可以看到各个节点存储的情况。也可以直接去某一个DataNode查看目录：hadoop.tmp.dir/dfs/data/current就 可以看到那些block了。Block的数量将会直接影响到Map的个数。当然可以通过配置来设定Map和Reduce的任务个数。Map的个数通常默认 和HDFS需要处理的blocks相同。也可以通过配置Map的数量或者配置minimum split size来设定，实际的个数为：max(min(block_size,data/#maps),min_split_size)。Reduce可以通过这个公式计算：0.95*num_nodes*mapred.tasktracker.tasks.maximum。

总的来说出了问题或者启动的时候最好去看看日志，这样心里有底。

Hadoop中的命令（Command）总结

这部分内容其实可以通过命令的Help以及介绍了解，我主要侧重于介绍一下我用的比较多的几个命令。Hadoop dfs 这个命令后面加参数就是对于HDFS的操作，和Linux操作系统的命令很类似，例如：

• Hadoop dfs –ls就是查看/usr/root目录下的内容，默认如果不填路径这就是当前用户路径；
• Hadoop dfs –rmr xxx就是删除目录，还有很多命令看看就很容易上手；
• Hadoop dfsadmin –report这个命令可以全局的查看DataNode的情况；
• Hadoop job后面增加参数是对于当前运行的Job的操作，例如list,kill等；
• Hadoop balancer就是前面提到的均衡磁盘负载的命令。

其他就不详细介绍了。

作者：岑文初   原文链接：http://www.infoq.com/cn/articles/hadoop-config-tip

为了演示如何创建一个自定义Writable，我们编写了一个表示一对字符串的实现，名为TextPair。

import java.io.*;
import org.apache.hadoop.io.*;
public class TextPair implements WritableComparable {
private Text first;
private Text second;
public TextPair() {
set(new Text(), new Text());
}
public TextPair(String first, String second) {
set(new Text(first), new Text(second));
}
public TextPair(Text first, Text second) {
set(first, second);
}
public void set(Text first, Text second) {
this.first = first;
this.second = second;
}
public Text getFirst() {
return first;
}
public Text getSecond() {
return second;
}
@Override
public void write(DataOutput out) throws IOException {
first.write(out);
second.write(out);
}
@Override
public void readFields(DataInput in) throws IOException {
first.readFields(in);
second.readFields(in);
}
@Override
public int hashCode() {
return first.hashCode() * 163 + second.hashCode();
}
@Override
public boolean equals(Object o) {
if (o instanceof TextPair) {
TextPair tp = (TextPair) o;
return first.equals(tp.first) && second.equals(tp.second);
}
return false;
}
@Override
public String toString() {
return first + "\t" + second;
}
@Override
public int compareTo(TextPair tp) {
int cmp = first.compareTo(tp.first);
if (cmp != 0) {
return cmp;
}
return second.compareTo(tp.second);
}
}

通过委托给每个Text对象本身，TextPair的write()方法依次序列化输出流中的每一个Text对象。同样，也通过委托给Text对象本身，readFields()反序列化输人流中的字节。DataOutput和DataInput接口有丰富的整套方法用于序列化和反序列化Java基本类型，所以在一般情况下，我们能够完全控制Writable对象的数据传输格式。

正如为Java写的任意值对象一样，我们会重写java.lang.Object的hashCode()方法，equals()方法和toString()方法。HashPartitioner使用hashCode()方法来选择reduce分区，所以应该确保写一个好的哈希函数来确保reduce函数的分区在大小上是相当的。

TextPair是WritableComparable的实现，所以它提供了compareTo()方法的实现，加入我们希望的顺序：它通过一个一个String逐个排序。请注意，TextPair不同于前面的TextArrayWritable类(除了它可以存储Text对象数之外)，因为TextArrayWritable只是一个Writable，而不是WritableComparable。

实现一个快速的RawComparator

上例中所示代码能够有效工作，但还可以进一步优化。正如前面所述，在MapReduce中，TextPair被用作键时，它必须被反序列化为要调用的compareTo()方法的对象。是否可以通过查看其序列化表示的方式来比较两个TextPair对象。

事实证明，我们可以这样做，因为TextPair由两个Text对象连接而成，二进制Text对象表示是一个可变长度的整型，包含UTF-8表示的字符串中的字节数，后跟UTF-8字节本身。关键在于读取开始的长度。从而得知第一个Text对象的字节表示有多长，然后可以委托Text对象的RawComparator，然后利用第一或者第二个字符串的偏移量来调用它。下面例子给出了具体方法(注意，该代码嵌套在TextPair类中)。

public static class Comparator extends WritableComparator {
private static final Text.Comparator TEXT_COMPARATOR = new Text.Comparator();
public Comparator() {
super(TextPair.class);
}
@Override
public int compare(byte[] b1, int s1, int l1,
byte[] b2, int s2, int l2) {
try {
int firstL1 = WritableUtils.decodeVIntSize(b1[s1]) + readVInt(b1, s1);
int firstL2 = WritableUtils.decodeVIntSize(b2[s2]) + readVInt(b2, s2);
int cmp = TEXT_COMPARATOR.compare(b1, s1, firstL1, b2, s2, firstL2);
if (cmp != 0) {
return cmp;
}
return TEXT_COMPARATOR.compare(b1, s1 + firstL1, l1 - firstL1,
b2, s2 + firstL2, l2 - firstL2);
} catch (IOException e) {
throw new IllegalArgumentException(e);
}
}
}
static {
WritableComparator.define(TextPair.class, new Comparator());
}

静态代码块注册原始的comparator以便MapReduce每次看到TextPair类，就知道使用原始comparator作为其默认comparator。

自定义comparator

从TextPair可知，编写原始的cornparator比较费力，因为必须处理字节级别的细节。如果需要编写自己的实现，org.apache.hadoop.io包中Writable的某些前瞻性实现值得研究研究。WritableUtils的有效方法也比较非常方便。

如果可能，还应把自定义comparator写为RawComparators。这些comparator实现的排序顺序不同于默认comparator定义的自然排序顺序。下面的例子显示了TextPair的comparator，称为First Comparator。只考虑了一对Text对象中的第一个字符串。请注意，我们重写了compare()方法使其使用对象进行比较，所以两个compare()方法的语义是相同的。

public static class FirstComparator extends WritableComparator {
private static final Text.Comparator TEXT_COMPARATOR = new Text.Comparator();
public FirstComparator() {
super(TextPair.class);
}
@Override
public int compare(byte[] b1, int s1, int l1,
byte[] b2, int s2, int l2) {
try {
int firstL1 = WritableUtils.decodeVIntSize(b1[s1]) + readVInt(b1, s1);
int firstL2 = WritableUtils.decodeVIntSize(b2[s2]) + readVInt(b2, s2);
return TEXT_COMPARATOR.compare(b1, s1, firstL1, b2, s2, firstL2);
} catch (IOException e) {
throw new IllegalArgumentException(e);
}
}
@Override
public int compare(WritableComparable a, WritableComparable b) {
if (a instanceof TextPair && b instanceof TextPair) {
return ((TextPair) a).first.compareTo(((TextPair) b).first);
}
return super.compare(a, b);
}
}

package org.apache.hadoop.io;
import java.io.DataOutput;
import java.io.DataInput;
import java.io.IOException;
public interface Writable {
    void write(DataOutput out) throws IOException;
    void readFields(DataInput in) throws IOException;
}

IntWritable writable = new IntWritable();
writable.set(163);

IntWritable writable = new IntWritable(163);

public static byte[] serialize(Writable writable) throws IOException {
    ByteArrayOutputStream out = new ByteArrayOutputStream();
    DataOutputStream dataOut = new DataOutputStream(out);
    writable.write(dataOut);
    dataOut.close();
    return out.toByteArray();
}

byte[] bytes = serialize(writable);
assertThat(bytes.length, is(4));

assertThat(StringUtils.byteToHexString(bytes), is("000000a3"));

public static byte[] deserialize(Writable writable, byte[] bytes)
throws IOException {
    ByteArrayInputStream in = new ByteArrayInputStream(bytes);
    DataInputStream dataIn = new DataInputStream(in);
    writable.readFields(dataIn);
    dataIn.close();
    return bytes;
}

IntWritable newWritable = new IntWritable();
deserialize(newWritable, bytes);
assertThat(newWritable.get(), is(163));

IntWritable实现了WritableComparable接口，后者是Writable和java.lang.Comparable接口的子接口。

package org.apache.hadoop.io;
public interface WritableComparable extends Writable, Comparable {
}

package org.apache.hadoop.io;
import java.util.Comparator;
public interface RawComparator extends Comparator {
     public int compare(byte[] b1, int s1, int l1, byte[] b2, int s2, int l2);
}

WritableComparator是RawComparator对WritableComparable类的一个通用实现。它提供两个主要功能。首先，它提供了一个默认的对原始compare()函数的调用，对从数据流对要比较的对象进行反序列化，然后调用对象的compare()方法。其次，它充当的是RawComparator实例的一个工厂方法（Writable方法已经注册)。例如，为获得IntWritable的comparator，我们只需使用:

RawComparator comparator = WritableComparator.get(IntWritable.class);

IntWritable w1 = new IntWritable(163);
IntWritable w2 = new IntWritable(67);
assertThat(comparator.compare(w1, w2), greaterThan(0));

byte[] b1 = serialize(w1);
byte[] b2 = serialize(w2);
assertThat(comparator.compare(b1, 0, b1.length, b2, 0, b2.length), greaterThan(0));

现在假设。该.文件是一个grip格式的压缩文件，压缩后的大小为1GB。和前面一样，HDFS将此文件存储为16块。然而，针对每一块创建一个分块是没有用的，因为不可能从gzip数据流中的任意点开始读取，map任务也不可能独立于其他分块只读取一个分块中的数据。gzip格式使用DEFLATE来存储压缩过的数据，DEFLATE将数据作为一系列压缩过的块进行存储。问题是，每块的开始没有指定用户在数据流中任意点定位到下一个块的起始位置，而是其自身与数据流同步。因此，gzip不支持分割(块)机制。

在这种情况下，MapReduce不分割gzip格式的文件，因为它知道输入是gzip压缩格式的(通过文件扩展名得知)，而gzip压缩机制不支持分割机制。这样是以牺牲本地化为代价:一个map任务将处理16个HDFS块。大都不是map的本地数据。与此同时，因为map任务少，所以作业分割的粒度不够细，从而导致运行时间变长。

在我们假设的例子中，如果是一个LZO格式的文件，我们会碰到同样的问题，因为基本压缩格式不为reader提供方法使其与流同步。但是，bzip2格式的压缩文件确实提供了块与块之间的同步标记(一个48位的PI近似值)，因此它支持分割机制。（上一篇中我们列出了每种压缩格式是否支持分割。）

对于文件的收集，这些问题会稍有不同。ZIP是存档格式，因此它可以将多个文件合并为一个ZIP文件。每个文件单独压缩，所有文档的存储位置存储在ZIP文件的尾部。这个属性表明ZIP文件支持文件边界处分割，每个分片中包括ZIP压缩文件中的一个或多个文件。

在MapReduce我们应该使用哪种压缩格式？

根据应用的具体情况来决定应该使用哪种压缩格式。就个人而言，更趋向于使用最快的速度压缩，还是使用最优的空间压缩？一般来说，应该尝试不同的策略，并用具有代表性的数据集进行测试，从而找到最佳方法。对于那些大型的、没有边界的文件，如日志文件，有以下选项。

• 存储未压缩的文件。
• 使用支持分割机制的压缩格式，如bzip2。
• 在应用中将文件分割成几个大的数据块，然后使用任何一种支持的压缩格式单独压缩每个数据块(可不用考虑压缩格式是否支持分割)。在这里，需要选择数据块的大小使压缩后的数据块在大小上相当于HDFS的块。
• 使用支持压缩和分割的Sequence File(序列文件)。

对于大型文件，不要对整个文件使用不支持分割的压缩格式，因为这样会损失本地性优势，从而使降低MapReduce应用的性能。

那么我们如何在MapReduce中使用压缩呢？

如前所述，如果输入的文件是压缩过的，那么在被MapReduce读取时，它们会被自动解压，根据文件扩展名来决定应该使用哪一个压缩解码器。

如果要压缩MapReduce作业的输出，请在作业配置文件中将mapred.output.compress属性设置为true。将mapred.output.compression.codec属性设置为自己打算使用的压缩编码/解码器的类名，如下例所示，此应用程序运行最高气温作业从而产生压缩的输出结果：

public class MaxTemperatureWithCompression {
     public static void main(String[] args) throws IOException {
         if (args.length != 2) {
            System.err.println("Usage: MaxTemperatureWithCompression <input path> " + "<output path>");
            System.exit(-1);
         }
         JobConf conf = new JobConf(MaxTemperatureWithCompression.class);
         conf.setJobName("Max temperature with output compression");
         FileInputFormat.addInputPath(conf, new Path(args[0]));
         FileOutputFormat.setOutputPath(conf, new Path(args[1]));
         conf.setOutputKeyClass(Text.class);
         conf.setOutputValueClass(IntWritable.class);
         conf.setBoolean("mapred.output.compress", true);
         conf.setClass("mapred.output.compression.codec", GzipCodec.class,
         CompressionCodec.class);
         conf.setMapperClass(MaxTemperatureMapper.class);
         conf.setCombinerClass(MaxTemperatureReducer.class);
         conf.setReducerClass(MaxTemperatureReducer.class);
         JobClient.runJob(conf);
     }
}

% hadoop MaxTemperatureWithCompression input/ncdc/sample.txt.gz output

最终输出的每部分都是压缩过的。在本例中。只有一部分:

% gunzip -c output/part-00000.gz
1949 111
1950 22

如果为输出使用了一系列文件，可以设置mapred.output.compression.type属性来控制压缩类型，默认为RECORD，它压缩单独的记录。将它改为BLOCK，则可以压缩一组记录。由于它有更好的压缩比，所以推荐使用。

map作业输出结果的压缩

即使MapReduce应用使用非压缩的数据来读取和写入，我们也可以受益于压缩map阶段的中间输出。因为map作业的输出会被写入磁盘并通过网络传输到reducer节点，所以如果使用LZO之类的快速压缩，能得到更好的性能，因为传输的数据量大大减少了。下表显示了启用rnap输出压缩和设置压缩格式的配置属性。

属性名称	类型	默认值	描述
mapred.compress.map.output	布尔	false	压缩map输出
mapred.map.output.compression.codec	类	org.apache.hadoop.io.compress.DefaultCodec	map输出使用的压缩编码/解码器

下面几行代码用于在map作业中启用gzip格式来压缩输出结果:

conf.setCompressMapOutput(true);
conf.setMapOutputCompressorClass(GzipCodec.class);

压缩格式	Hadoop压缩编码/解码器
DEFLATE	org.apache.hadoop.io.compress.DefaultCodec
gzip	org.apache.hadoop.io.compress.GzipCodec
bzip2	org.apache.hadoop.io.compress.BZip2Codec
LZO	com.hadoop.compression.lzo.LzopCodec

LZO格式是基于GPL许可的，不能通过Apache来分发许可，基于此，它的hadoop}编码/解码器必须单独下载，地址是http://code.google.com/p/hadoop-gpl-compression/。lzop编码/解码器兼容干lzop工具，它其实就是LZO格式，但额外还有头部，它正是我们想要的。还有一个纯LZO格式的编码/解码器LzoCodec，它使用.lzo_deflate作为扩展名(根据DEFLATE类推，是没有头部的gzip格式）。

CompressionCodec对流进行压缩和解压缩

CompressionCodec有两个方法可以用于轻松地压缩或解压缩数据。要想对正在被写入一个输出流的数据进行压缩，我们可以使用createOutputStream(OutputStreamout)方法创建一个CompressionOutputStream（未压缩的数据将被写到此)，将其以压缩格式写入底层的流。相反，要想对从输入流读取而来的数据进行解压缩，则调用createInputStream(InputStreamin)函数，从而获得一个CompressionInputStream,，从而从底层的流读取未压缩的数据。CompressionOutputStream和CompressionInputStream类似干java.util.zip.DeflaterOutputStream和java.util.zip.DeflaterInputStream，前两者还可以提供重置其底层压缩和解压缩功能，当把数据流中的section压缩为单独的块时，这比较重要。比如SequenceFile。

下例中说明了如何使用API来压缩从标谁输入读取的数据及如何将它写到标准输出：

public class StreamCompressor {
public static void main(String[] args) throws Exception {
String codecClassname = args[0];
Class<?> codecClass = Class.forName(codecClassname);
Configuration conf = new Configuration();
CompressionCodec codec = (CompressionCodec)
ReflectionUtils.newInstance(codecClass, conf);
CompressionOutputStream out = codec.createOutputStream(System.out);
IOUtils.copyBytes(System.in, out, 4096, false);
out.finish();
}
}

% echo "Text" | hadoop StreamCompressor org.apache.hadoop.io.compress.GzipCodec \
| gunzip -
Text

在阅读一个压缩文件时，我们通常可以从其扩展名来推断出它的编码/解码器。以.gz结尾的文件可以用GzipCodec来阅读，如此类推。每个压缩格式的扩展名均以下表所示：

压缩格式	工具	算法	文件扩展名	多文件	可分割性
DEFLATEa	无	DEFLATE	.deflate	不	不
gzip	gzip	DEFLATE	.gz	不	不
ZIP	zip	DEFLATE	.zip	是	是，在文件范围内
bzip2	bzip2	bzip2	.bz2	不	是
LZO	lzop	LZO	.lzo	不	不

CompressionCodecFactory提供了getCodec()方法，从而将文件扩展名映射到相应的CompressionCodec。此方法接受一个Path对象。下面的例子显示了一个应用程序，此程序便使用这个功能来解压缩文件。

public class FileDecompressor {
    public static void main(String[] args) throws Exception {
       String uri = args[0];
       Configuration conf = new Configuration();
       FileSystem fs = FileSystem.get(URI.create(uri), conf);
       Path inputPath = new Path(uri);
       CompressionCodecFactory factory = new CompressionCodecFactory(conf);
       CompressionCodec codec = factory.getCodec(inputPath);
       if (codec == null) {
           System.err.println("No codec found for " + uri);
           System.exit(1);
       }
       String outputUri =
       CompressionCodecFactory.removeSuffix(uri, codec.getDefaultExtension());
       InputStream in = null;
       OutputStream out = null;
       try {
           in = codec.createInputStream(fs.open(inputPath));
           out = fs.create(new Path(outputUri));
           IOUtils.copyBytes(in, out, conf);
       } finally {
           IOUtils.closeStream(in);
           IOUtils.closeStream(out);
       }
    }
}

% hadoop FileDecompressor file.gz

表4-3

本地库

考虑到性能，最好使用一个本地库（native library）来压缩和解压。例如，在一个测试中，使用本地gzip压缩库减少了解压时间50%，压缩时间大约减少了10%(与内置的Java实现相比较)。表4-4展示了Java和本地提供的每个压缩格式的实现。井不是所有的格式都有本地实现(例如bzip2压缩)，而另一些则仅有本地实现（例如LZO）。

压缩格式	Java实现	本地实现
DEFLATE	是	是
gzip	是	是
bzip2	是	否
LZO	否	是

Hadoop带有预置的32位和64位Linux的本地压缩库，位于库/本地目录。对于其他平台，需要自己编译库，具体请参见Hadoop的维基百科http://wiki.apache.org/hadoop/NativeHadoop。

本地库通过Java系统属性java.library.path来使用。Hadoop的脚本在bin目录中已经设置好这个属性，但如果不使用该脚本，则需要在应用中设置属性。

默认情况下，Hadoop会在它运行的平台上查找本地库，如果发现就自动加载。这意味着不必更改任何配置设置就可以使用本地库。在某些情况下，可能希望禁用本地库，比如在调试压缩相关问题的时候。为此，将属性hadoop.native.lib设置为false，即可确保内置的Java等同内置实现被使用(如果它们可用的话)。

CodecPool(压缩解码池)

如果要用本地库在应用中大量执行压缩解压任务，可以考虑使用CodecPool，从而重用压缩程序和解压缩程序，节约创建这些对象的开销。

下例所用的API只创建了一个很简单的压缩程序，因此不必使用这个池。此应用程序使用一个压缩池程序来压缩从标准输入读入然后将其写入标准愉出的数据：

public class PooledStreamCompressor {
    public static void main(String[] args) throws Exception {
    String codecClassname = args[0];
    Class<?> codecClass = Class.forName(codecClassname);
    Configuration conf = new Configuration();
    CompressionCodec codec = (CompressionCodec)
    ReflectionUtils.newInstance(codecClass, conf);
    Compressor compressor = null;
    try {
        compressor = CodecPool.getCompressor(codec);
        CompressionOutputStream out = codec.createOutputStream(System.out, compressor);
        IOUtils.copyBytes(System.in, out, 4096, false);
        out.finish();
    } finally {
        CodecPool.returnCompressor(compressor);
    }
  }
}

到此，就介绍完了Hadoop中的编码器和解码器，希望对大家有所帮助，下次我将继续为大家分享Hadoop的相关知识，再见！

Memcached 是什么？

Memcached是一种集中式Cache，支持分布式横向扩展。这里需要解释说明一下，很多开发者觉得Memcached是一种分布式缓存系统， 但是其实Memcached服务端本身是单实例的，只是在客户端实现过程中可以根据存储的主键做分区存储，而这个区就是Memcached服务端的一个或 者多个实例，如果将客户端也囊括到Memcached中，那么可以部分概念上说是集中式的。其实回顾一下集中式的构架，无非两种情况：一是节点均衡的网状 （JBoss Tree Cache），利用JGroup的多播通信机制来同步数据；二是Master-Slaves模式（分布式文件系统），由Master来管理Slave，比 如如何选择Slave，如何迁移数据等都是由Master来完成，但是Master本身也存在单点问题。下面再总结几个它的特点来理解一下其优点和限制。

内存存储：不言而喻，速度快，但对于内存的要求高。这种情况对CPU要求很低，所以常常采用将 Memcached服务端和一些CPU高消耗内存、低消耗应用部署在一起。（我们的某个产品正好有这样的环境，我们的接口服务器有多台，它们对CPU要求 很高——原因在于WS-Security的使用，但是对于内存要求很低，因此可以用作Memcached的服务端部署机器）。

集中式缓存（Cache）：避开了分布式缓存的传播问题，但是需要非单点来保证其可靠性，这个就是后面集成中所作的集群（Cluster）工作，可以将多个Memcached作为一个虚拟的集群，同时对于集群的读写和普通的Memcached的读写性能没有差别。

分布式扩展：Memcached很突出的一个优点就是采用了可分布式扩展的模式。可以将部署在一台机器上的多个 Memcached服务端或者部署在多个机器上的Memcached服务端组成一个虚拟的服务端，对于调用者来说则是完全屏蔽和透明的。这样做既提高了单 机的内存利用率，也提供了向上扩容（Scale Out）的方式。

Socket通信：这儿需要注意传输内容的大小和序列化的问题，虽然Memcached通常会被放置到内网作为 缓存，Socket传输速率应该比较高（当前支持TCP和UDP两种模式，同时根据客户端的不同可以选择使用NIO的同步或者异步调用方式），但是序列化 成本和带宽成本还是需要注意。这里也提一下序列化，对于对象序列化的性能往往让大家头痛，但是如果对于同一类的Class对象序列化传输，第一次序列化时 间比较长，后续就会优化，也就是说序列化最大的消耗不是对象序列化，而是类的序列化。如果穿过去的只是字符串，这种情况是最理想的，省去了序列化的操作， 因此在Memcached中保存的往往是较小的内容。

特殊的内存分配机制：首先要说明的是Memcached支持最大的存储对象为1M。它的内存分配比较特殊，但是 这样的分配方式其实也是基于性能考虑的，简单的分配机制可以更容易回收再分配，节省对CPU的使用。这里用一个酒窖做比来说明这种内存分配机制，首先在 Memcached启动的时候可以通过参数来设置使用的所有内存——酒窖，然后在有酒进入的时候，首先申请（通常是1M）的空间，用来建酒架，而酒架根据 这个酒瓶的大小将自己分割为多个小格子来安放酒瓶，并将同样大小范围内的酒瓶都放置在一类酒架上面。例如20厘米半径的酒瓶放置在可以容纳20-25厘米 的酒架A上，30厘米半径的酒瓶就放置在容纳25-30厘米的酒架B上。回收机制也很简单，首先新酒入库，看看酒架是否有可以回收的地方，如果有就直接使 用，如果没有则申请新的地方，如果申请不到，就采用配置的过期策略。从这个特点来看，如果要放的内容大小十分离散，同时大小比例相差梯度很明显的话，那么 可能对于空间使用来说效果不好，因为很可能在酒架A上就放了一瓶酒，但却占用掉了一个酒架的位置。

缓存机制简单：有时候很多开源项目做的面面俱到，但到最后因为过于注重一些非必要的功能而拖累了性能，这里提到 的就是Memcached的简单性。首先它没有什么同步，消息分发，两阶段提交等等，它就是一个很简单的缓存，把东西放进去，然后可以取出来，如果发现所 提供的Key没有命中，那么就很直白地告诉你，你这个Key没有任何对应的东西在缓存里，去数据库或者其他地方取；当你在外部数据源取到的时候，可以直接 将内容置入到缓存中，这样下次就可以命中了。这里介绍一下同步这些数据的两种方式：一种是在你修改了以后立刻更新缓存内容，这样就会即时生效；另一种是说 容许有失效时间，到了失效时间，自然就会将内容删除，此时再去取的时候就不会命中，然后再次将内容置入缓存，用来更新内容。后者用在一些实时性要求不高， 写入不频繁的情况。

客户端的重要性：Memcached是用C写的一个服务端，客户端没有规定，反正是Socket传输，只要语言 支持Socket通信，通过Command的简单协议就可以通信。但是客户端设计的合理十分重要，同时也给使用者提供了很大的空间去扩展和设计客户端来满 足各种场景的需要，包括容错、权重、效率、特殊的功能性需求和嵌入框架等等。

几个应用点：小对象的缓存（用户的Token、权限信息、资源信息）；小的静态资源缓存；SQL结果的缓存（这部分如果用的好，性能提高会相当大，同时由于Memcached自身提供向上扩容，那么对于数据库向上扩容的老大难问题无疑是一剂好药）；ESB消息缓存。

优化MemCached系统Java客户端的原因

MemCached在大型网站被应用得越来越广泛，不同语言的客户端也都在官方网站上有提供，但是Java开发者的选择并不多。由于现在的 MemCached服务端是用C写的，因此我这个C不太熟悉的人也就没有办法去优化它。当然对于它的内存分配机制等细节还是有所了解，因此在使用的时候也 会十分注意，这些文章在网络上有很多。这里我重点介绍一下对于MemCache系统的Java客户端优化的两个阶段。

第一阶段：封装Whalin

第一阶段主要是在官方推荐的Java客户端之一whalin开源实现基础上做再次封装。

1. 缓存服务接口化：定义了IMemCache接口，在应用部分仅仅只是使用接口，为将来替换缓存服务实现提供基础。
2. 使用配置代替代码初始化客户端：通过配置客户端和SocketIO Pool属性，直接交由CacheManager来维护Cache Client Pool的生命周期，便于单元测试。
3. KeySet的实现：对于MemCached来说本身是不提供KeySet的方法的，在接口封装初期，同事向我提出这个需求的时候，我个 人觉得也是没有必要提供，因为缓存轮询是比较低效的，同时这类场景，往往可以去数据源获取KeySet，而不是从MemCached去获取。但是SIP的 一个场景的出现，让我不得不去实现了KeySet。
   SIP在作服务访问频率控制的时候需要记录在控制间隔期内的访问次数和流量，此时由于是集群，因此数据必须放在集中式的存储或者缓存中，数据库肯定撑不住 这样大数据量的更新频率，因此考虑使用Memcached的很出彩的操作——全局计数器 （storeCounter,getCounter,inc,dec），但是在检查计数器的时候如何去获取当前所有的计数器？我曾考虑使用DB或者文件， 但是效率有问题，同时如果放在一个字段中的话，还会存在并发问题。因此不得不实现了KeySet，在使用KeySet的时候有一个参数，类型是 Boolean，这个字段的存在是因为在Memcached中数据的删除并不是直接删除，而是标注一下，这样会导致实现keySet的时候取出可能已经删 除的数据。如果对于数据严谨性要求低，速度要求高，那么不需要再去验证Key是否真的有效，而如果要求Key必须正确存在，就需要再多一次的轮询查找。
4. 集群的实现：Memcached作为集中式缓存，存在着集中式的致命问题：单点问题。虽然Memcached支持多Instance分布 在多台机器上，但仅仅只是解决了数据全部丢失的问题，当其中一台机器出错以后，还是会导致部分数据的丢失，一个篮子掉在地上还是会把部分的鸡蛋打破。因此 就需要实现一个备份机制，能够保证Memcached在部分失效以后，数据还能够依然使用，当然大家很多时候都用缓存不命中就去数据源获取的策略。然而在 SIP的场景中，如果部分信息找不到就去数据库查找，很容易将SIP弄垮，因此SIP对于Memcached中的数据认为是可信的，做集群也是必要的。
5. LocalCache结合Memcached使用，提高数据获取效率：在第一次压力测试过程中，发现和原先预料的一 样，Memcached并不是完全无损失的，Memcached是通过Socket数据交互来进行通信的，因此机器的带宽，网络IO，Socket连接数 都是制约Memcached发挥其作用的障碍。Memcache的一个突出优点就是Timeout的设置，也就是可以对放进去的数据设置有效期，从而在一 定的容忍时间内对那些不敏感的数据就可以不去更新，以提高效率。根据这个思想，其实在集群中的每一个Memcached客户端也可以使用本地的缓存，来存 储获取过的数据，设置一定的失效时间，来减少对于Memcached的访问次数，提高整体性能。

因此，在每一个客户端中都内置了一个有超时机制的本地缓存（采用Lazy Timeout机制），在获取数据的时候，首先在本地查询数据是否存在，如果不存在则再向Memcache发起请求，获得数据以后，将其缓存在本地，并设置有效时间。方法定义如下：

/**

  * 降低memcache的交互频繁造成的性能损失，因此采用本地cache结合memcache的方式

  * @param key

  * @param 本地缓存失效时间单位秒

  * @return

**/

public Object get(String key,int localTTL);

第二阶段：优化

第一阶段的封装基本上已经可以满足现有的需求，也被自己的项目和其他产品线所使用，但是不经意的一句话，让我开始了第二阶段的优化。有同事告诉我说 Memcached客户端的SocketIO代码里面有太多的Synchronized（同步），多多少少会影响性能。虽然过去看过这部分代码，但是当时 只是关注里面的Hash算法。根据同事所说的回去一看，果然有不少的同步，可能是作者当时写客户端的时候JDK版本较老的缘故造成的，现在 Concurrent包被广泛应用，因此优化并不是一件很难的事情。但是由于原有Whalin没有提供扩展的接口，因此不得不将Whalin除了 SockIO，其余全部纳入到封装过的客户端的设想，然后改造SockIO部分。

结果也就有了这个放在Google上的开源客户端：http://code.google.com/p/memcache-client-forjava/。

1. 优化Synchronized：在原有代码中SockIO的资源池被分成三个池（普通Map实现），——Free（闲）、Busy（忙） 和Dead（死锁），然后根据SockIO使用情况来维护这三个资源池。优化方式为首先简化资源池，只有一个资源池，设置一个状态池，在变更资源状态的过 程时仅仅变更资源池中的内容。然后用ConcurrentMap来替代Map，同时使用putIfAbsent方法来简化Synchronized，具体 的代码可参见Google上该软件的源文件。
2. 原以为这次优化后，效率应该会有很大的提高，但是在初次压力测试后发现，并没有明显的提高，看来有其他地方的耗时远远大于连接池资源维 护，因此用JProfiler作了性能分析，发现了最大的一个瓶颈：Read数据部分。原有设计中读取数据是按照单字节读取，然后逐步分析，为的仅仅就是 遇到协议中的分割符可以识别。但是循环Read单字节和批量分页Read性能相差很大，因此我内置了读入缓存页（可设置大小），然后再按照协议的需求去读 取和分析数据，结果显示效率得到了很大的提高。具体的数据参见最后部分的压力测试结果。

上面两部分的工作不论是否提升了性能，但是对于客户端本身来说都是有意义的，当然提升性能给应用带来的吸引力更大。这部分细节内容可以参看代码实现部分，对于调用者来说完全没有任何功能影响，仅仅只是性能。

压力测试比较

在这个压力测试之前，其实已经做过很多次压力测试了，测试中的数据本身并没有衡量Memcached的意义，因为测试是使用我自己的机器，其中性 能、带宽、内存和网络IO都不是服务器级别的，这里仅仅是将使用原有的第三方客户端和改造后的客户端作一个比较。场景就是模拟多用户多线程在同一时间发起 缓存操作，然后记录下操作的结果。

Client版本在测试中有两个：2.0和2.2。2.0是封装调用Whalin Memcached Client 2.0.1版本的客户端实现。2.2是使用了新SockIO的无第三方依赖的客户端实现。checkAlive指的是在使用连接资源以前是否需要验证连接 资源有效（发送一次请求并接受响应），因此启用该设置对于性能来说会有不少的影响，不过建议还是使用这个检查。

单个缓存服务端实例的各种配置和操作下比较：

缓存配置	用户	操作	客户端 版本	总耗时(ms)	单线程耗时(ms)	提高处理能力百分比
checkAlive	100	1000 put simple obj 1000 get simple obj	2.0 2.2	13242565 7772767	132425 77727	+41.3%
No checkAlive	100	1000 put simple obj 1000 put simple obj	2.0 2.2	7200285 4667239	72002 46672	+35.2%
checkAlive	100	1000 put simple obj 2000 get simple obj	2.0 2.2	20385457 11494383	203854 114943	+43.6%
No checkAlive	100	1000 put simple obj 2000 get simple obj	2.0 2.2	11259185 7256594	112591 72565	+35.6%
checkAlive	100	1000 put complex obj 1000 get complex obj	2.0 2.2	15004906 9501571	150049 95015	+36.7%
No checkAlive	100	1000 put complex obj 1000 put complex obj	2.0 2.2	9022578 6775981	90225 67759	+24.9%

从上面的压力测试可以看出这么几点，首先优化SockIO提升了不少性能，其次SockIO优化的是get的性能，对于put没有太大的作用。原以为获取数据越大性能效果提升越明显，但结果并不是这样。

单个缓存实例和双缓存实例的测试比较：

缓存配置	用户	操作	客户端 版本	总耗时(ms)	单线程耗时(ms)	提高处理能力百分比
One Cache instance checkAlive	100	1000 put simple obj 1000 get simple obj	2.0 2.2	13242565 7772767	132425 77727	+41.3%
Two Cache instance checkAlive	100	1000 put simple obj 1000 put simple obj	2.0 2.2	13596841 7696684	135968 76966	+43.4%

结果显示，单个客户端对应多个服务端实例性能提升略高于单客户端对应单服务端实例。

缓存集群的测试比较：

缓存配置	用户	操作	客户端 版本	总耗时(ms)	单线程耗时(ms)	提高处理能力百分比
No Cluster checkAlive	100	1000 put simple obj 1000 get simple obj	2.0 2.2	13242565 7772767	132425 77727	+41.3%
Cluster checkAlive	100	1000 put simple obj 1000 put simple obj	2.0 2.2	25044268 8404606	250442 84046	+66.5%

这部分和SocketIO优化无关。2.0采用的是向集群中所有客户端更新成功以后才返回的策略，2.2采用了异步更新，并且是分布式客户端节点获取的方式来分散压力，因此提升效率很多。

开源代码下载

其实封装后的客户端一直在内部使用，现在作了二次优化以后，觉得应该开源出来，一是可以完善自己的客户端代码，二是也可以和更多的开发者交流使用心 得。目前我已经在Google Code上传了应用的代码、范例和说明等，有兴趣的朋友可以下载下来测试一下，与现在用的Java Memcached客户端在易用性和性能方面是否有所提高，也期待更多对于这部分开源内容的反馈，能够将它做的更好。

链接地址：http://code.google.com/p/memcache-client-forjava/。

原文链接

首先要认识到SOA产品本身就是一个集成平台，为了完成数据集成，应用集成和流程集成，我们需要一个基础平台来集中统一的完成这个事情。因此SOA集成平 台重点则是将服务集成和服务组装的能力全部管理起来，从这个概念上理解自然涉及到SOA最核心的UDDI，ESB和BPEL等功能。这些集成的特性和功能 完全是在各个业务系统外的，又是大家都需要的基础公共功能，则应该纳入到平台集中管理。

SOA称之为平台的原因则是它提供了业务系统都需要的通用基础架构和技术，这种能力是大家都需要的公共基础能力。但是如果我们买入一个SOA套装产品，这 个产品可能刚开始没有任何服务接入，也无法提供任何服务能力，那么这个产品本身就是一个技术平台。如果后面我们将数据服务，业务服务，流程服务全部识别， 开发后发布到平台上，那么SOA平台本身就是一个专属某个业务域的业务平台。

平台本身要考虑SOA化

平台的核心是它是一个公共的基础能力提供中心，平台本身已经集中了所有可复用的能力，开发框架和技术。通过平台我们可以快速的开发平台和应用。

在软件开发里面我们比较关注技术平台，而技术平台简单理解就是所有业务系统标准的技术能力的抽象和封装形成了一个不承载具体业务的空框架。这个空框架不仅仅是简单的技术开发框架，而是融入了更多的基础服务能力。

基础服务能力包括两个层面，一个是纯粹技术方面的基础服务能力，包括日志，异常，消息，事务，国际化，缓存等内容。一个是业务抽象后和业务无关的技术能 力，包括通用权限模型，通用流程模型，邮件短信组件，常用UI组件。有了这些，你会发现技术平台本身就是一个完完整整可以独立运行起来的应用，除了没有具 体业务功能外其他一应俱全。

基于该平台我们可以开发业务应用，那如果平台本身是基于SOA架构的，那么开发的应用自然也就满足SOA架构风格。一个应用功能应该包括资源层，技术组 件，服务组件层，流程层等。一个应用功能在实现业务过程中能够看到业务和技术实现是剥离和松耦合的。一个应用它本身是基于在技术平台上开发的多个业务组件 构成的，业务组件间本身松耦合，业务组件间通过服务进行交互。

基于平台开发的业务应用，本身业务组件之间可能基于ESB总线方式进行消息交换，我们可以联想下java里面的IOC控制反转模式，和通过ESB总线进行交互的思路是很类似的，只有这样才能够实现组件之间进一步的解耦。

传统的很多快速软件开发平台是完全不能符合SOA架构风格要求的，因为基于某些快速开发平台开发出来的应用本身就是紧耦合和封闭的应用。而基于SOA架构 风格的平台开发出来的应用本身就是完全组件化和服务化的应用，应用内部SOA化和松耦合，应用和应用之间也松耦合，应用本身可复用的能力很容易通过服务方 式暴露出来。

技术平台和业务平台

首先要说明技术平台和业务平台都是开发人员关注的平台，而应用平台可能是最终用户关注的平台。可以看到技术平台和业务平台的划分正好体现了业务和技术本身的一次解耦。

技术平台只关注和业务完全无关的技术本身，将各种技术能力组件化和服务化，提供各种通用的基础服务和技术服务。技术平台提供一套完整的开发框架和开发环境，同时也提供一套完整的执行环境。技术平台既为产品服务，也为业务平台服务。

而细分到某个专业的业务域后可能出现业务平台，业务平台也可以叫做产品平台，比如电信的BOSS平台，网管平台都是很常见的业务平台。那业务平台和技术平 台最大的不同是业务平台本身提供了开发多个产品都可复用的业务组件和业务能力。业务平台本身是对多个同类产品通用业务能力的抽取，提炼和下沉。

应用产品->产品平台->技术平台，正好体现了可复用能力的逐层下移，下移的目的只有一个即最大限度的复用，而复用的好处是对通用能力统一管 理和统一维护。我们可以试想下，如果没有这种平台，当我们面对N个产品开发对应N套产品开发源代码的时候，对用通用功能的修改调整和升级将是一件巨大的麻 烦。

作者：人月神话   来源：新浪博客   原文链接

接缝，顾名思义，就是指程序中的一些特殊的点，在这些点上你无需作任何修改就可以达到改动程序行为的目的。

“接缝”这个词语不太好理解，根据我的理解，大约还是依赖点的含义。通过事先找到依赖点，并采取一定方式解除依赖，就能够改善代码质量，尤其是 针对遗留代码而言。准确而言，我们寻找接缝以及解依赖，就是为了代码能够具有好的可重用性与可扩展性，尤其是当我们能解除对其他外部服务的依赖时，可以带 来程序的可测试性。

最近项目组的同事和我讨论了这样一个满足可测试性的问题。项目中需要对返回的响应信息PlatformResponse进行处理，这些信息会根 据不同的StatusCode，得到不同的提示或出错信息。为了避免分支语句的判断，同事利用hash table将StatusCode与提示（出错）信息进行了映射，然后根据当前的StatusCode就可以返回对应的结果。返回结果后，还需要调用外部 服务对消息进行处理，例如消息的输出。由于之前相关的类PlatformResponse并没有提供这一逻辑，相关服务要返回消息时，直接返回了 PlatformResponse对象，然后再由客户端根据当前的StatusCode来判断，输出相关的提示信息，所以同事将这些逻辑写到了扩展方法 中，例如定义PlatformResponseHelper静态类：

public static class PlatformResponseHelper {
    private static HashTable messageMapping = //此处略
    public static void Output(this PlatformResponse response) {
        ServiceLocator.Lookup.Write(messageMapping[response.StatusCode]);
    }
}

现在，我们需要进行单元测试。项目之前已经为ServiceLocator提供了Mock对象，并且该对象在Controller中也是通过依 赖注入的方式获得的。所以，在测试Controller时，可以通过注入模拟的ServiceLocator对象进行测试，从而解除与外部服务之间的依赖 关系。现在，在增加了PlatformResponse的扩展方法时，遇到了难题，即如何解除扩展方法与ServiceLocator之间的依赖关系？

显然，这里的ServiceLocator.Lookup.Write()方法调用就是前面所说 的“接缝”。我们希望在单元测试中不依赖于ServiceLocator，这就需要解除PlatformResponse与ServiceLocator 之间的耦合关系。同事希望既能达到可测试性的目的，又要保障调用的简单。

在面向对象设计中，最常见的解除依赖的方法是职责分离以及抽象，或者利用反射或IOC容器来解除具体依赖。由于要解除与 ServiceLocator的耦合关系，再加上调用PlatformResponse相关方法的Controller也是通过依赖注入 ServiceLocator对象的，所以我首先想到将ServiceLocator转移到扩展方法的外部，通过传入参数的方式注入依赖。由于这个对象是 单例的，因此Controller获得的ServiceLocator也就是PlatformResponse需要的对象。当我们调用 PlatformResponse的Output()方法时，可以将Controller获得的ServiceLocator对象作为方法参数传给 PlatformResponse。在Controller层，我们利用依赖注入注入Mock对象，就可以达到较好的可测试性了。

然而，倘若要这样做，就需要将调用代码改为：

businessService.Response.Output(serviceLocator)；

由于C#的扩展方法有很多限制，例如它要求必须是静态类和静态方法，很难利用OO的一些特性，所以我想到的第二个方案是不采用扩展方法，而是将 之前的逻辑直接封装到PlatformResponse中。我们可以将Output()方法定义为虚方法，然后再为测试定义 PlatformResponse的子类，它将作为测试使用的Mock类，重写Output()方法。遗憾的是，系统基本上都是在调用外部服务的时候才获 得的PlatformResponse对象。我们不可能去修改服务对象，使其在单元测试时返回该类的子类对象。

第三条路是转移职责，将扩展方法Output()转移到一个专门的类，例如OutputMessage，由它来负责管理StatusCode与提示（出错）消息之间的映射关系，以及消息的输出，然后由子类重写消息处理的逻辑，完成模拟。例如代码：

public class OutputMessage {
    private PlatformResponse response;
    private HashTable messageMapping = //此处略
    public OutputMessage(PlatformResponse response) {
        this.response = response;
    }
    public void Output() {
        OutputInternal();
    }
    protected virtual void OutputInternal() {
        ServiceLocator.Lookup.Write(messageMapping[response.StatusCode]);
    }
}
public class MockOutputMessage {
    public MockOutputMessage(PlatformResponse response):base(response) {}
    protected override void OutputInternal() {
    //模拟国际化服务对消息进行处理;
   }
}

可是这一方案实际上更无法达到同事的目标，因为改动后的调用变得比第一种方案更复杂：

new OutputMessage(businessService.Response).Output();

那么，应该怎么办？同事的理想目标是调用简单。就目前而言，在C#中，只有扩展方法才能让我们对PlatformResponse对象的 message处理显得如此的自然而简洁。再加上PlatformMessage对象已经被广泛使用，因此从PlatformMessage类的角度进行 处理，就变得不再可能。

让我们再来仔细思考“接缝”的问题。是谁引入了依赖点？接缝是调用ServiceLocator这条语句，而它的目的实际上是需要获得 IMessageWriter。是这个外部服务成为测试的障碍。所以解决的重点应该是解除与IMessageWriter之间的依赖。要这样做，就需要修 改Output()扩展方法，使其能够传入IMessageWriter对象。这种改进事实上与第一种方案没有什么区别，唯一的不同是它依赖于更小的接 口，而不是全局的ServiceLocator对象。我认为，这已经是一个最好的方案了。但是同事依旧执著于调用的简单性。他认为，不能为了单元测试，而 改变客户端调用的方式。

现在，我们已经明白扩展方法是最简单的实现方式，纠结仅仅在于IMessageWriter服务的获取方式而已。在产品代码中，我们可以通过 ServiceLocator来获得IMessageWriter对象，而在测试的时候，我们又需要模拟该服务对象。若要两全齐美，只有区分测试与生产环 境。事实上，这是我最初想到的做法，就是引入预定义来区分测试与真正的生产环境。但同事无法接受这种C++所主要采取的预定义做法。因此，我唯一能想到的 是修改PlatformMessage类的定义，提供设置IMessageWriter的属性（因为C#并不支持扩展属性），并在Output()方法中 判断IMessageWriter对象是否为null。如果为null，则说明它没有在测试环境下注入，这就需要通过ServiceLocator获得。

public class PlatformResponse {
    private IMessageWriter writer = null;
    public IMessageWriter MessageWriter {
        get; set;
    }
}
public static class PlatformResponseHelper {
    private static HashTable messageMapping = //略去

    public static void Output(this PlatformResponse response) {
        String message = messageMapping[response.StatusCode];
        //如果不为null，说明是测试注入了该对象;
       if (response.MessageWriter !=null) {
           response.MessageWriter.Write(message);
       } else {
           ServiceLocator.Lookup.Write(message);
       }
    }
}

我们常常需要在灵活性和简单性之间进行设计权衡。大多数情况下，都可能产生非此即彼的选择。要做到两全齐美真的很难。从面向对象的角度来看，我 不认为最后的方案是最佳方案。其实，通过方法参数注入IMessageWriter的做法已经足够好了，它并没有加大结构与调用的复杂性。无论怎样，设计 总是见仁见智的问题，就看大家的选择了。唯一需要遵循的原则，就是设计必须结合具体的场景来做出正确的决定。

来源: 捷道    原文链接

一、网站基本数据概览

• 据2010年统计，优酷网日均独立访问人数（uv)达到了8900万，日均访问量（pv）更是达到了17亿，优酷凭借这一数据成为google榜单中国内视频网站排名最高的厂商。
• 硬件方面，优酷网引进的戴尔服务器主要以 PowerEdge 1950与PowerEdge 860为主，存储阵列以戴尔MD1000为主，2007的数据表明，优酷网已有1000多台服务器遍布在全国各大省市，现在应该更多了吧。

二、网站前端框架

从一开始，优酷网就自建了一套CMS来解决前端的页面显示，各个模块之间分离得比较恰当，前端可扩展性很好，UI的分离，让开发与维护变得十分简单和灵活，下图是优酷前端的模块调用关系：

这样，就根据module、method及params来确定调用相对独立的模块，显得非常简洁。下面附一张优酷的前端局部架构图：

三、数据库架构

应该说优酷的数据库架构也是经历了许多波折，从一开始的单台MySQL服务器（Just Running）到简单的MySQL主从复制、SSD优化、垂直分库、水平sharding分库，这一系列过程只有经历过才会有更深的体会吧，就像MySpace的架构经历一样，架构也是一步步慢慢成长和成熟的。

1、简单的MySQL主从复制:

MySQL的主从复制解决了数据库的读写分离，并很好的提升了读的性能，其原来图如下：

其主从复制的过程如下图所示：

但是，主从复制也带来其他一系列性能瓶颈问题：

1. 写入无法扩展
2. 写入无法缓存
3. 复制延时
4. 锁表率上升
5. 表变大，缓存率下降

那问题产生总得解决的，这就产生下面的优化方案，一起来看看。

2、MySQL垂直分区

如果把业务切割得足够独立，那把不同业务的数据放到不同的数据库服务器将是一个不错的方案，而且万一其中一个业务崩溃了也不会影响其他业务的正常进行，并且也起到了负载分流的作用，大大提升了数据库的吞吐能力。经过垂直分区后的数据库架构图如下：

然而，尽管业务之间已经足够独立了，但是有些业务之间或多或少总会有点联系，如用户，基本上都会和每个业务相关联，况且这种分区方式，也不能解决单张表数据量暴涨的问题，因此为何不试试水平sharding呢？

3、MySQL水平分片（Sharding）

这是一个非常好的思路，将用户按一定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增加，只要简单地配置一台服务器即可，原理图如下：

如何来确定某个用户所在的shard呢，可以建一张用户和shard对应的数据表，每次请求先从这张表找用户的shard id，再从对应shard中查询相关数据，如下图所示：

但是，优酷是如何解决跨shard的查询呢，这个是个难点，据介绍优酷是尽量不跨shard查询，实在不行通过多维分片索引、分布式搜索引擎，下策是分布式数据库查询（这个非常麻烦而且耗性能）

四、缓存策略

貌似大的系统都对“缓存”情有独钟，从http缓存到memcached内存数据缓存，但优酷表示没有用内存缓存，理由如下：

1. 避免内存拷贝，避免内存锁
2. 如接到老大哥通知要把某个视频撤下来，如果在缓存里是比较麻烦的

而且Squid 的 write() 用户进程空间有消耗，Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。

但为何我们访问优酷会如此流畅，与土豆相比优酷的视频加载速度略胜一筹？这个要归功于优酷建立的比较完善的内容分发网络（CDN），它 通过多种方式保证分布在全国各地的用户进行就近访问——用户点击视频请求后，优酷网将根据用户所处地区位置，将离用户最近、服务状况最好的视频服务器地址 传送给用户，从而保证用户可以得到快速的视频体验。这就是CDN带来的优势，就近访问，有关CDN的更多内容，请大家Google一下。

五、其他相关架构文章推荐

Flickr网站架构
回顾MySpace架构的坎坷之路
国内图片网站Yupoo架构
twitter网站架构
PlentyOfFish.com .NET网站的又一传奇

作者：王国峰  来源：青藤园  原文链接

1）如果面对的是一位中国的专家级人物，也许你可以讲一下中国云计算网的定义:

“云计算是并行计算、分布式计算和网格计算的发展，或者说是这些科学概念的商业实现。”

这类定义很中国特色，即“拿一个复杂的概念去解释一个更复杂的概念”(导师如是说)，反正到最后一般人还是不懂。做这个定义的人，也许也未必真的能讲清楚并行计算、分布式计算和网格计算。

2）如果面对的是一位计算机专业或IT从业的人，但只是听过云计算，但没涉猎过。为了省事，给他看维基百科的云计算​的定义吧，个人觉得讲得挺清楚的。

“云计算（英语：Cloud Computing），是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需提供给计算机和其他设备。整个运行方式很像电网。

云计算是继1980年代大型计算机到客户端-服务器的大转变之后的又一种巨变。用户不再需要了解“云”中基础设施的细节，不必具有相应的专业知识，也无需直接进行控制。^[1] 云计算描述了一种基于互联网的新的IT服务增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展而且经常是虚拟化的资源。^[2][3] 云其实是网络、互联网的一种比喻说法。因为过去在图中往往用云来表示电信网，后来也用来表示互联网和底层基础设施的抽象。典型的云计算提供商往往提供通用的网络业务应用，可以通过浏览器等软件或者其他Web服务来访问，而软件和数据都存储在服务器上。云计算关键的要素，还包括个性化的用户体验。”

​3）如果你自己都看不懂，或者别人看了还是不懂。那么我尝试给一种更浅白的解释：

​云计算，就是“云态的网络设备” 向外提供的“按需动态变化的”一系列计算服务。

• 云态的网络端，指的是云计算服务提供者是一群协同工作的网络设备。云一方面说明了其规模化，另一方面云的特性（云碰到云变大云）说明这群协作的网络设备的规模是易于扩展的（从整一片云的角度看，虽说要求易于scale out，但并不关注scale in），再者对于观云者我们是看不到云里面的内容，这也说明云的内部对用户而言是不可见的。

• ​按需动态变化的，表示提供的服务能力是动态变化的，还是按需提供的，同时云本身也是动态可变的。但目前而言，从自己了解的，觉得这个服务的动态调整的粒 度并不细。一开始还以为Amazon提供的CPU、存储等服务的粒度都是很很很细粒度的（比如具体用了多少就是多少），结果发现是我太天真了。

• ​计算服务，在此是广义的计算服务，包括存储、CPU计算能力、网络能力等。

（​嗯，上面的内容，一般看过云计算内容的人都会明白的，甚至觉得讲得没什么信息了。嗯，其实我只想用自己的语言解释一遍而已。）

​首先看对象，其次看你想往抓哪个点去讲。

其实这个跟对象也有关系，毕竟根据对象熟悉的点去讲，对方更容易接受。在此，自己谈谈本人对云计算更抽象化的认识——泛化的中间层理论。

正如某句著名的话（突然忘了出处了）——“一切问题都可以通过增加一个中间层去解决”所述，我觉得云计算解决问题的方式也是如此的，加了一层，屏蔽了底下那层，向上提供更傻瓜化的服务，然后更多人能使用了。

当年多了一层操作系统，尤其是图形化操作系统的出现，普通人能玩计算机了。Java在OS上加了层虚拟机，Java应用能跨平台了。现在多了云计 算，理想来说，我们不用买神马CPU，主板，存储等硬件了，只要联网就成了。但单纯这样还不够，似乎跟网络虚拟桌面区分不开呢！

“这个网络虚拟桌面是什么呢？这个概念我也没研究过，只是上回说去某实验室交流云平台时，听那边一老师说，华为现在有些部门的人工作时前面就一个显示屏，一根网线，打开屏幕见登录界面，一登录就进入相应自己工作的操作系统环境了。”

​如果只是登录一下，然后服务端读取用户信息，返回用户内容，个人觉得还不够云呢！要够云，就得体现按需动态提供的能力，比如默认配置了很拙的计 算能力（比如配了一个不给力的CPU），现在突然要进行一个高密度的计算任务，比如科学计算任务，那云应该按我的需求提供更强力的计算能力，可不能让我按 之前的CPU能力等上几月半年才算出来。呃，当然，这样最后结算也是得多给些money的。似乎我又说了些理想化的事情，目前而言，CPU类的计算能力以 及存储能力还是很难算流量那般结算的，相对而言，目前带宽还是有可能做到的。

​所以，云计算就是增加了一个中间层然后解决相应了问题。I云（IaaS）多了设备虚拟层，用户在其上不用care硬件设备了；在P云上的用户不用care平台以下的东西；在S云上面的，用不着安装相应软件就能使了哦（呃，现在还是得装个浏览器的。）

嗯嗯，似乎有些太抽象了。那试试讲云计算产品的特征，即如何去识别云计算。

从云计算概念的发展历程，个人觉得云计算的服务也好，产品也好，一般都有以下两大特征：

1. 内容在网络端。很多云产品给用户的感觉就是从本地端迁移到网络端，比如I和S，其中一般会拿S做说明。比如一般会讲 Salesforce的故事，从基于CRM客户端提供服务到基于web CRM提供服务。内容在网络端，一般还会延伸出云计算许多卖点，如异地设备同步啊，多种终端访问啊。

2. 可按需调度计算资源。按需调度，即以合理分配的策略进行资源的动态调度。动态调度是云计算最主要的技术特征之一，云计算大多的技术点和学术研究点都基于此，比如多副本协作、虚拟机动态迁移等等。

这两个特征，应该是要并存的，不能只有1而没2（没有1只有2，呃，这就是本地设备了吧~）。比如电子邮件服务，能称作云服务的，我直接想到的是Gmail，在我的认识中，G的服务都是S。而以前的电子邮箱服务称不上云，主要是因为没有动态性。    

现在很多打着云的旗号的产品，我们很难知道它们是不是真的云产品，因为一般我们只能知道内容是放在网络端了，但云内是否有一套体现动态性的系统，我们不知道。所以有了以下问题：

——​云是要给用户感知的？！

本人不以为然。云给用户的体验应该是一直保持良好的可用性，所以云就应该让用户无法感知到它。比如一个基于 云的服务，在低访问量和高访问量的情况下，给用户的体验应该是一致的，但对于访问的用户而言，他并不知道服务端是否因访问量上升而增多服务的计算资源。如 果让用户感知到差异，只能表示这云做得不够好。所以云的提出是为了提供服务质量的，其本身便不是让用户体验的。因此面对这么多“云产品”，用户并不知道它 是不是真的云，尤其对于SaaS。只要用户觉得体验好，其实就足够了。

​呃，绕了一圈，得出用户无法感知云，表示也难以识别云，似乎有些坑人了。其实，我只想说明，不要轻易相信“云”，因为我们很难知道；同时，只要有“云”的良好体验，其实我们用户也用不着理会它是不是真的有一套复杂的动态调度机制去支撑的云。

说了这么多，除了是为了总结自己的思考之外，还想说明的是，在理解云计算的时候，别人云亦云。在理解别人的说法的同时，要有自己的理解，同时更 新自己的理解。导师曾经说过，他认为的云计算的两大特征是动态化和服务化。咋一想，挺有道理的，导师再一讲，觉得更有道理了。要理解云计算，要找个适当的 点。

“互联网上的云计算服务特征和自然界的云、水循环具有一定的相似性，因此，云是一个相当贴切的比喻。通常云计算服务应该具备以下几条特征：

• 基于虚拟化技术快速部署资源或获得服务

• 实现动态的、可伸缩的扩展

• ……”

说云计算服务特征与自然的云或水有相似性，这难以厚非，毕竟用云这个概念就是想用自然云去形容其特征。但特征里的第一条，“基于虚拟化技术”，个人表示很不解。

云计算的实现，一定要用虚拟化吗？个人认为，虚拟化技术只是推进云计算的发展，因为虚拟化技术使实现云的规 模性变得简单了。如果没有虚拟化，以真机去实现云的规模是很吃力的，尤其当一般情况下，由于真机资源利用率低下，实现云浪费的资源是巨大。而虚拟化便是能 充分利用真机的资源，同时解决了大规模联机的问题。当物理主机本身资源利用率便很高的情况下，虚拟化的意义也不大。

​再发散一下，如果有一台NB得不行的主机，同时能保证其资源的高利用率，那还需要做云吗？其实，云计算的网络端抽象成一个巨型主机的话，why not不直接用这样一个主机呢？ 问题就是无法做到，才有的Google起初用各种廉价设备协同为世界提供强力搜索服务的美好故事，也有了现在云计算的需求。

写在最后

写此文，最初只是自己想理清自己对云计算的思考。毕竟研一时自己看过些书，课程有相关内容，之后参与了实验室的云平台项目而且一直跟进着，自己觉得有必要总结总结，虽说比最初想写的多了许多内容，也显得零散许多。

写得较杂，较乱，较浅，若有说的不是之处，望交流。

作者：wenlele  来源：CSDN  原文链接

由于最近忙工作实习的事情，又要忙学校的毕业设计，所以很久没在博客上分享自己的技术实践成果了，真的很抱歉。今天我在整理自己毕业设计的时候，我 觉得有一样东西不得不推荐给大家，这个东西就叫Memcached。可能有些朋友已经对他非常熟悉，也可能已经用得非常溜，但我想对于像我一样的初学者来 说，这篇文章应该还是能帮助一些初学者朋友解决一些有关使用Memcached的问题的。

首先，我先简单介绍一下Memcached是什么样的东西。其实说白了他就是一个缓存框架，但与普通缓存不同的是他能支持分布式集群部署，想象一 下，当你需要缓存的数据很多时，你可能需要加入更多的服务器来满足你的数据缓存需求。下面是更专业的解释（其实太多的术语反而会让大家觉得这个东西很复 杂）。

Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据 库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。其守护进程（daemon ）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。

很简单，他就是用来作缓存的，一般应用在你的应用和数据库之间，缓解数据库服务器的I/O负载压力。因为他能满足分布式集群的特性，所以我对他非常 感兴趣，于是自己就在.NET上简单实现了一个demo，顺便把实现的过程记录了下来，以便以后自己翻阅，当然也为那些初学者提供一个现成的思路。

准备工作

下载Windows版本的Memcached服务器，下载地址：http://www.itivy.com/DownloadFile.ashx?id=634418560909724471

下载.NET中可用的Memcached客户端，这里我用了Enyim的客户端，下载地址：http://www.itivy.com/DownloadFile.ashx?id=634418565974010508

配置工作

第一步先启动memcached服务：

将下载的压缩包解压到c:\

你可以直接双击memcached.exe图标运行memcached，我们还可以采取cmd命令行模式下启动memcached。

这时候细心的你应该注意到你的taskmanager中多了一个memcached进程，是的，这时候memcached服务已经启动了。

第二步配置memcached客户端：

这里我们为了在演示中看到缓存的效果，故新建了两个网站，每一个网站都可以设置和读取缓存内容，如在webA中设置了缓存，可以在webB中获取由 webA设置的缓存内容。下面我们来配置一下这两个网站的web.config文件，在configuration节点下添加以下配置信息：

<configsections>
    <!--Memcached客户端配置信息-->
    <sectiongroup name="enyim.com">
      <section name="memcached" type="Enyim.Caching.Configuration.MemcachedClientSection, Enyim.Caching">
    </section>
    <section name="memcached" type="Enyim.Caching.Configuration.MemcachedClientSection, Enyim.Caching">
  </section>
  <enyim.com>
    <memcached>
      <servers>
        <!-- put your own server(s) here-->
        <add address="192.168.1.150" port="11211">
      </add>
      <socketpool minpoolsize="10" maxpoolsize="100" connectiontimeout="00:00:00.5000000" deadtimeout="00:00:00.5000000">
    </socketpool>
  </servers>
  <!--Memcached客户端配置信息-->
  <appsettings>
    <!--系统统一缓存策略-->
    <add key="CacheStrategy" value="MyCache.Core.MemcachedCacheStrategy,MyCache.Core">
    <!--系统统一缓存策略的缓存时间-->
    <add key="CacheTimeOut" value="60">
  </add>
<connectionstrings>
</connectionstrings>
</add>
</appsettings>
</memcached>
</enyim.com>
</sectiongroup>
</configsections>

这里可能你不太明白的是为什么在appSettings中加一个CacheStrategy，其实这个是为了抽象缓存接口，我们可以采用 Memcached缓存方案，也可以采用.NET自带的缓存方案，也可以是其他的缓存方案，所以还是让程序在运行时自动加载某种方案吧。这个我在最后会把 源代码发上来，你一看就明白怎么回事了。另外，配置中的IP自己设置，这种常识就不多说了。

测试工作

OK，客户端也配置完成了，让我们来看看测试效果吧。在网站A，B中各设置两个按钮，一个用来设置缓存，一个用来获取缓存，按钮事件如下：

网站A设置缓存按钮代码：

protected void Button1_Click(object sender, EventArgs e)
{
     MyCache.Core.WebCache.Add("Test", "我是Test，我的值是A 来自 WEBA");
}

protected void Button2_Click(object sender, EventArgs e)
{
     Response.Write(MyCache.Core.WebCache.Retrieve("Test"));
}

protected void Button1_Click(object sender, EventArgs e)
{
     MyCache.Core.WebCache.Add("Test", "我是Test，我的值是B 来自 WEBB");
}

protected void Button2_Click(object sender, EventArgs e)
{
     Response.Write(MyCache.Core.WebCache.Retrieve("Test"));
}

这说明我们在网站A中设置的缓存已经可以被网站A和网站B同时获取，OK，测试成功了。

当然，我们在网站B中设置缓存也是一样，这里就不再赘述了。

最后附上测试源码，源码可以用vs2005及以上版本打开，点击下载源码。希望本文能帮到一部分朋友。