dennis_zane

Ruby写Servlet的小例子

dennis_zane — Wed, 23 Jul 2008 12:05:38 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/218517 发表时间: 2008年07月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Ruby也能写servlet?是的，没开玩笑，而且挺方便的，因为Ruby的标准库就自带了一个webrick，webrick本身又有一个serlvet容器，随时随地启动一个web server，实在是很方便。
先看个最简单的例子，输出hello到浏览器：

require 'webrick'
require 'net/http'
include WEBrick

class HelloServlet < HTTPServlet::AbstractServlet
  def hello(resp)
    resp["Content-Type"]="text/html;charset=utf-8"
    resp.body="hello,ruby servlet"
  end
  private :hello
  def do_GET(req,resp)
    hello(resp)
  end
  def do_POST(req,resp)
    hello(resp)
  end
end
if $0==__FILE__
  server=HTTPServer.new(:Port=>3000)
  server.mount("/hello",HelloServlet)
  trap("INT"){ server.shutdown }
  server.start
end

是不是跟java很像？所有的serlvet都要继承自HTTPServlet::AbstractServlet，并实现do_GET或者do_POST方法。在这行代码：

server=HTTPServer.new(:Port=>3000)

我们启动了一个HTTP Server，端口是3000，然后将HelloServlet挂载到/hello这个路径上，因此，执行这个脚本后，可以通过 http://localhost:3000/hello调用HelloServlet，简单地只是显示字符串" hello,ruby servlet "。
这个简单的例子没有任何交互，并且显示的html也是写死在脚本中，显然更好的方式应该通过模板来提供，可以使用Ruby标准库的erb模板。再给个有简单交互的例子，现在要求用户输入姓名，然后提交给HelloServlet，显示"hello,某某某"。嗯，来个最简单的提交页面：

注意到，我们采用POST方法提交。再看看erb模板：


    
    
      hello,<%=name%>

其中的name是我们将要绑定的变量，根据用户提交的参数。最后，修改下HelloServlet：

require 'webrick'
require 'net/http'
include WEBrick

class HelloServlet < HTTPServlet::AbstractServlet
  def do_GET(req,resp)
    do_POST(req,resp)
  end
  def do_POST(req,resp)
    name=req.query["name"]
    #读取模板文件
    template=IO.read(File.dirname(__FILE__)+"/hello.html")
    message=ERB.new(template)
    resp["Content-Type"]="text/html;charset=utf-8"
    resp.body=message.result(binding)
  end
end
if $0==__FILE__
  server=HTTPServer.new(:Port=>3000)
  server.mount("/hello",HelloServlet)
  trap("INT"){ server.shutdown }
  server.start
end

与前一个例子相比，不同点有二，一是通过req.query[ " name " ]获得用户提交的参数name，二是resp的body是由模板产生，而不是写死在代码中。在一些临时报表、临时数据的展示上，可以充分利用Ruby的这些标准库来快速实现。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

工作的几个tip

dennis_zane — Mon, 07 Jul 2008 20:47:58 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/212483 发表时间: 2008年07月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

1、如果用java6的ScriptEngineManager来调用JRuby，并且脚本使用到了Ruby的标准库（比如我用到了YAML库），如果没有正确设置，是会找不到标准库的。通过打印$:变量可以看到文件的加载路径，比如在某台机器上的打印的结果：
puts $:
输出：
.
/root/.jruby/lib/ruby/site_ruby/1.8
/root/.jruby/lib/ruby/site_ruby
/root/.jruby/lib/ruby/1.8
/root/.jruby/lib/ruby/1.8/java
lib/ruby/1.8
......略

显然，默认会到当前用户的主目录下寻找.jruby隐藏目录，将此目录作为Ruby的安装目录，因此，可以在~user/.jruby放置一个jruby实现，一劳永逸地解决问题，不然就要自己手工添加完整的路径到$:变量中。

2、nio的临时selector的使用，了解grizzly的都知道，Grizzly框架有一个比较与众不同的地方在于使用临时selector注册channel进行读或者写。这个带来什么好处呢？一个是，通常我们可能将read派发到其他线程中去，如果一次没有读完，那么就得继续注册OP_READ到主selector上；注意，nio在一些平台上有个问题，就是SelectionKey.interestOps方法跟Selector.select方法会有并发冲突，产生奇怪的现象，因此，你会看到大多数的nio框架都会保证SelectionKey.interestOps跟Selector.select的调用在同一个线程；在没有读完继续注册这个场景下，免不了线程间的context switch，如果采用一个临时selector注册并读取，就可以避免这个切换开销。另外，对于write调用，通常你可能这样写：

while (byteBuffer.hasRemaining()) {
  int len = socketChannel.write(byteBuffer);
  if (len < 0){
   throw new EOFException(); 
  }
}

在负载比较高的时候，write返回0的次数会越来越多，while循环将空耗多次导致CPU占用偏高，这个问题在win32上比较严重，同样可以采用临时selector的解决（Cindy2.x是留在队列，等待下次写）。下例是采用临时Selector进行读的例子：

 Selector readSelector = SelectorFactory.getSelector();
                SelectionKey tmpKey = sc.register(readSelector,
                        SelectionKey.OP_READ);
                tmpKey.interestOps(tmpKey.interestOps() | SelectionKey.OP_READ);
                int code = readSelector.select(1000);
                tmpKey.interestOps(tmpKey.interestOps()
                        & (~SelectionKey.OP_READ));
                if (code > 0) {
                    do {
                        n = sc.read(in);
                    } while (n > 0 && in.hasRemaining());
                    in.flip();
                    decode();
                    in.compact();
                }
                SelectorFactory.returnSelector(readSelector);

这样的方式，某种意义上可以认为是non-blocking模式下的阻塞读，在网络条件稳定的情况下（比如内网），能带来比较高的效率。

3、spymemcached ，是另一个memcached的java client实现，采用nio。最近遇到的问题是它跟原来的MemcachedClient 的兼容问题，用它去操作MemcachedClient存储的数据。spymemcached是通过Transcoder来实现序列化，Transcoder的WhalinTranscoder实现类兼容了Greg Whalin的MemcachedClient：

private Transcoder whalinTranscoder = new WhalinTranscoder();


Future f = memcachedClient.asyncGet(id, whalinTranscoder);

各个方法都有重载的版本用以指定Transcoder。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

值的纪念的一天

dennis_zane — Sun, 29 Jun 2008 16:08:41 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/209371 发表时间: 2008年06月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

沸沸扬扬的华南虎案（更想说是闹剧）终于告一段落，在广大网民的火眼金睛下，假老虎终究没有变成真老虎，没有上演指“画”为“虎”的现代成语故事。尽管处理结果有那么点抓小放大的意思，但还是值的纪念的一个日子。

更正：我还是太乐观了，贵州某地发生的事情，让我无法平静，我能做些什么？

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

关于加班

dennis_zane — Mon, 23 Jun 2008 01:29:06 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/206964 发表时间: 2008年06月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

    加班在国内的公司好像是司空见惯的事情，更司空见惯的是加班不给加班费。从业三年，加班次数也不少，不过最长的一次是连续加了一个月的班，天天10点多才回家，比起某些同学深更半夜还在加班的差了些。在目前的公司，除了刚开始偶尔加班外，现在我基本就是下班就走人了，还没有因为我负责的模块延期导致的项目的延期，相反，自信工作的效率还是比较高的，自然上班时间能搞定的事情，何必拖到下班后？
    不排除有些人喜欢安静的环境，下班后，人少了，一个人敲代码感觉更好，效率更高。这其实颠倒了问题的本质，本质是公司没有为员工创造一个舒适的工作环境，“家具警察”们是绝不乐意给你安排一个私人小空间的。问题是，代码不是生活的全部，如果天天这样晚上在公司加班，可以想见这人的生活该如何枯燥，而生活枯燥的人很容易失去想象力和直觉，并且心理上难免会有点毛病。公司不应该鼓励加班，公司应该鼓励的是大家在上班期间高效地完成工作，然后尽快回家去“生活”。其实吧，如果我们上班少看点新闻，少开点小差，这个效率绝对是不低的。
    听闻有领导对我们部门不满，说我们部门总是下班后人都走光了：）这样的观点真是奇怪，难道加班就能显示这个部门很努力、很负责？况且，我看到很多加班的同学更多是在玩游戏或者干自己的事情，公司领导们难道看不到这一点？或者他们只要看见有人在那，心里就比较舒服点。这其实很奇怪的，我认为经常加班的部门绝对是有问题的，而且很大程度上是项目管理不当引起的。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

TCP的TIME_WAIT状态

dennis_zane — Mon, 23 Jun 2008 01:27:58 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/206963 发表时间: 2008年06月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

    主动关闭的Socket端会进入TIME_WAIT状态，并且持续2MSL时间长度，MSL就是maximum segment lifetime(最大分节生命期），这是一个IP数据包能在互联网上生存的最长时间，超过这个时间将在网络中消失。MSL在RFC 1122上建议是2分钟，而源自berkeley的TCP实现传统上使用30秒，因而，TIME_WAIT状态一般维持在1-4分钟。
    TIME_WAIT状态存在的理由：
1）可靠地实现TCP全双工连接的终止
    在进行关闭连接四路握手协议时，最后的ACK是由主动关闭端发出的，如果这个最终的ACK丢失，服务器将重发最终的FIN，因此客户端必须维护状态信息允许它重发最终的ACK。如果不维持这个状态信息，那么客户端将响应RST分节，服务器将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。因而，要实现TCP全双工连接的正常终止，必须处理终止序列四个分节中任何一个分节的丢失情况，主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。

2）允许老的重复分节在网络中消逝
    TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个原来的迷途分节就称为lost duplicate。在关闭一个TCP连接后，马上又重新建立起一个相同的IP地址和端口之间的TCP连接，后一个连接被称为前一个连接的化身（incarnation)，那么有可能出现这种情况，前一个连接的迷途重复分组在前一个连接终止后出现，从而被无解成从属于新的化身。为了避免这个情况，TCP不允许处于TIME_WAIT状态的连接启动一个新的化身，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个TCP连接的时候，来自连接先前化身的重复分组已经在网络中消逝。

新的SCTP协议通过在消息头部添加验证标志避免了TIME_WAIT状态。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

NIO的SelectableChannel关闭的一个问题

dennis_zane — Wed, 18 Jun 2008 01:53:06 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/204969 发表时间: 2008年06月18日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

SocketChannel和ServerSocketChannel，两者的父类是SelectableChannel，它在jdk中的文档有这么段话：

Once registered with a selector, a channel remains registered until it is deregistered.This involves deallocating whatever resources were allocated to the channel by the selector.
A channel cannot be deregistered directly; instead, the key representing its registration must be cancelled. Cancelling a key requests that the channel be deregistered during the selector's next selection operation.

也就是说关闭一个已经注册的SelectableChannel需要两个步骤：

1）取消注册的key，这个可以通过SelectionKey.cancel方法，也可以通过SelectableChannel.close方法，或者中断阻塞在该channel上的IO操作的线程来做到。

2）后续的Selector.selectXXX方法的调用才真正地关闭 本地Socket。

因而，如果，如果在取消SelectionKey后没有调用到selector的select方法（因为Client一般在取消key后，我们都会终止调用select的循环，当然，server关闭一个注册的channel我们是不会终止select循环的），那么本地socket将进入CLOSE-WAIT 状态（等待本地Socket关闭）。简单的解决办法是在 SelectableChannel.close方法之后调用Selector.selectNow方法，类似:

   Selector sel;
   SocketChannel sch;
   // …
   sch.close();
   sel.selectNow();

Nio编程有很多这样细节性的东西需要注意，通常情况下还是利用成熟的框架为妙。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

java语言的演化——读JavaOne ppt笔记

dennis_zane — Wed, 18 Jun 2008 00:22:00 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/204958 发表时间: 2008年06月18日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

JavaOne2008上有个session《Upcoming Java Programming Language Features》，讲了即将到来的jdk7可能引入的新的语言特性，比较开眼界的是jsr308对Annotation的扩展使用，更多地作为断言或者说checker使用以便减少bug。在ppt前面，我觉的更有意思的是对java语言演化的讲述，做个笔记。

1 、应用 VS. 语言

应用是特性越多越好，应用是 rich 的；而语言是 pure 的，更少的、普通的特性更好。

2 、添加一个 java 语言特性的三个前提：尊重过去、着眼未来以及顾及模型。

无论是增加、减少或者改变一个 feature 都可能 broken 已经存在的代码，一个新增加的 feature 必须兼容已经存在的代码，兼容是个沉重的包袱，就 java 语言而言，我相当认同尊重过去 这一点，哪怕加入闭包这样的特性也不应当以损坏兼容性为代价，更好的选择是将这些特性让 jvm 上的新语言去实现（比如JRuby、Scala）， java 语言作为成熟的工业语言本身不应当做太大的改变。而着眼未来，也就是说新的语言特性应该为未来的语法扩展留有空间，它的语法 / 语义不应当跟现存的或者潜在的特性相冲突，以便可以持续地演化。再谈顾及当前的模型，一门语言代表着一种计算模型，比如 simula 是 OO 模型（ classes) ， Erlang 就是 inter-process communication 的模型 (actor ）。 Java 语言也有一个简单的模型：首先它是“高层”语言，是一门通用、并发、基于类的 OO 语言，其次，它跟 API 、 JVM 有良好的结合。 Java 语言模型有四个原则：

a) 鼓励 high-level 实践，通过抽象来隐藏偶然复杂度。简而言之： do the right thing 。

b) 追求清晰，程序被读的时候远远多于写。简而言之： do the thing right.

c) 青睐静态类型，静态类型能增进对代码的信心，静态类型能证明 bug 在编译时的不存在，而测试和动态类型能证明 bug 的存在。我的观点是，大多数难以寻找和解决的 bug 都是 runtime 的，静态类型在此方面能给出的帮助有限，充分并且适宜的测试更加能增强你对应用的信心。

d) 语言比之 API 的更广泛。 one language,many api 。 API 来去匆匆，而语言却是 forever ，因而将语言和 API 分离是明智的，一些特性可以做为库来实现， jdk5 并发库的引入就很好， jdk7 在并发方面同样将引入 fork/join 模型。

java语言的演化也当遵循这四个原则。再看看传说中的闭包语言，当它跟泛型结合的时候写出来的东西还谈得上清晰吗？闭包的实现能否解决兼容性问题也是个疑问。就四个提案，C3S需要引入method关键字（类似lambda)，FCM的#号看起来比较怪异，在我看来，CICE和BGGA更符合胃口，CICE对 java语言的变动应该最小，学习曲线也比较平缓，BGGA的=>符号更有函数式语言的味道。闭包的引入，某种程度上能减少敲击键盘的次数并实现一些高阶功能，特别是在聚合操作（如filter、map等）和单抽象方法类（如Runnable,Callable）的使用上，但是在现代IDE的自动化帮助下，这个带来的价值是值的怀疑的。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

JRuby中调用java带可变参数的方法

dennis_zane — Sat, 14 Jun 2008 22:41:18 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/203341 发表时间: 2008年06月14日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天同事遇到的问题，用JRuby调用一个java方法，该方法使用了jdk1.5的可变参数。我一开始以为只要简单地将可变参数表示为数组即可，例如下面的两个java类：

public class Echo{
    public void echo(String name){
       System.out.println(name);
    }
}
public class Test{
    public void hello(String name,Echoargs){
        System.out.println("hello,"+name);
        for(Echo e:args){
            e.echo(name);
        }
    }
}

我想在jruby中调用Test的hello方法，该方法有个可变参数args。所谓可变参数经过编译后其实也就是数组，这个可以通过观察字节码知道，那么如果用数组来调用可以不？

require 'java'
require 'test.jar'
include_class 'Test'
include_class 'Echo'
t.hello("dennis")  #报错，参数不匹配
t.hello("dennis",[])  #报错，类型不匹配

很遗憾，这样调用是错误的，原因如上面的注释。具体到类型不匹配，本质的原因是JRuby中的数组与java中对数组的字节码表示是不一致的，JRuby 中的数组是用org.jruby.RubyArray类来表示，而hello方法需要的数组却是是[LEcho。解决的办法就是将JRuby的数组转成 java需要的类型，通过to_java方法，因而下面的调用才是正确的，尽管显的麻烦：

require 'java'
require 'test.jar'
include_class 'Test'
include_class 'Echo'
t=Test.new
t.hello("dennis",[].to_java("Echo"))
e1=Echo.new
t.hello("dennis",[e1].to_java("Echo"))
e2=Echo.new
t.hello("dennis",[e1,e2].to_java("Echo"))

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

理发二三事

dennis_zane — Fri, 13 Jun 2008 21:55:30 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/203115 发表时间: 2008年06月13日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

头发乃人之元，很多人看人，第一眼看的就是你的头发，当然看MM 的部位可能不一样。我的头发从来都是像野草一样，从来没放心思在上面，都是理一次头发大半年不管他，长的跟杂草似的难受，然后回家找小区内的师傅理发——或者说剃头，而且发型从来都是板寸头，短短的，免的大半年不回家还得在外面理发。因而，我的理发时间跟我的回家时间一样。

小时候，那时候住在老家，没有专门的理发店，也可能是离我家的小村庄很远。有个走村串户的剃头匠，大概几个月能在村里见他一次，带着一身行头，谁家有人要剃头，就请他过去。记的那时是没用电的理发工具，一把类似夹子的东西，老师傅手工在各式各样的脑袋上推来推去，然后搞些肥皂水就着自家的井水冲洗。再然后，很久没再见到这位老师傅，隔壁村开始开了家理发店，然后大人们就带着我们走路或者骑着自行车去隔壁村剃头了，记的那位师傅还是我们大队的干部，隔壁是猪肉店，至于剃头的细节却是记不清了。再后来隔壁村又开了一家理发店，是个小青年开的，印象特别深的一次是我奶奶带我过去理发，小青年说如果我帮他打一桶井水，钱可以减半。我帮他打了桶井水，然后真给我减半了，就着自己打的井水冲洗我的不规则的大脑袋。后来，跟父母搬到了县城，去外地读书，就再也没在老家理发过了，好几年之后路过小青年开的那家店，装修了，蓝色的玻璃后面，小青年变成了师傅，指导着自己的徒弟在理发，我想，大概他也记不得当年那个给他打水的小屁孩了。

进城了，我理发就固定在小区的周师傅这了。上大学，基本是五一、十一和春节回家的时候剃一次，哪怕再长，还是不愿意在福州理发，分不清是习惯还是莫名其妙的坚持了。其实挺不好意思的，每次都留那么长的头发，周师傅也还是固定收我5 块钱，不过今年涨价了，7 块。下午剃头的时候，周师傅的女儿找他要100 来块钱，旁边的人问周师傅她拿去做啥呢？周师傅说去染发，语气有点黯然。父亲理的老式发型，女儿是不会喜欢的。我的头发就这样随着我离家的远近轮回着，现在在广州，回家还是容易的，以后去哪还是不知道的事情，希望还能半年回家一次理发。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Hadoop分布式文件系统：架构和设计要点(翻译)

dennis_zane — Thu, 05 Jun 2008 14:26:24 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/200508 发表时间: 2008年06月05日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Hadoop分布式文件系统：架构和设计要点

一、前提和设计目标
1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。
2、跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
3、HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。
4、 HDFS应用对文件要求的是write-one-read-many访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。
5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。
6、在异构的软硬件平台间的可移植性。

二、Namenode和Datanode
    HDFS采用master/slave架构。一个HDFS集群是有一个Namenode和一定数目的Datanode组成。Namenode是一个中心服务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在内部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。Namenode执行文件系统的namespace操作，例如打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创建、删除和复制。Namenode和Datanode都是设计成可以跑在普通的廉价的运行linux的机器上。HDFS采用java语言开发，因此可以部署在很大范围的机器上。一个典型的部署场景是一台机器跑一个单独的Namenode节点，集群中的其他机器各跑一个Datanode实例。这个架构并不排除一台机器上跑多个Datanode，不过这比较少见。

单一节点的Namenode大大简化了系统的架构。Namenode负责保管和管理所有的HDFS元数据，因而用户数据就不需要通过Namenode（也就是说文件数据的读写是直接在Datanode上）。

三、文件系统的namespace
   HDFS支持传统的层次型文件组织，与大多数其他文件系统类似，用户可以创建目录，并在其间创建、删除、移动和重命名文件。HDFS不支持user quotas和访问权限，也不支持链接（link)，不过当前的架构并不排除实现这些特性。Namenode维护文件系统的namespace，任何对文件系统namespace和文件属性的修改都将被Namenode记录下来。应用可以设置HDFS保存的文件的副本数目，文件副本的数目称为文件的 replication因子，这个信息也是由Namenode保存。

四、数据复制
    HDFS被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成block序列，除了最后一个block，所有的block都是同样的大小。文件的所有block为了容错都会被复制。每个文件的block大小和replication因子都是可配置的。Replication因子可以在文件创建的时候配置，以后也可以改变。HDFS中的文件是write-one，并且严格要求在任何时候只有一个writer。Namenode全权管理block的复制，它周期性地从集群中的每个Datanode接收心跳包和一个Blockreport。心跳包的接收表示该Datanode节点正常工作，而Blockreport包括了该Datanode上所有的block组成的列表。

1、副本的存放，副本的存放是HDFS可靠性和性能的关键。HDFS采用一种称为rack-aware的策略来改进数据的可靠性、有效性和网络带宽的利用。这个策略实现的短期目标是验证在生产环境下的表现，观察它的行为，构建测试和研究的基础，以便实现更先进的策略。庞大的HDFS实例一般运行在多个机架的计算机形成的集群上，不同机架间的两台机器的通讯需要通过交换机，显然通常情况下，同一个机架内的两个节点间的带宽会比不同机架间的两台机器的带宽大。
    通过一个称为Rack Awareness的过程，Namenode决定了每个Datanode所属的rack id。一个简单但没有优化的策略就是将副本存放在单独的机架上。这样可以防止整个机架（非副本存放）失效的情况，并且允许读数据的时候可以从多个机架读取。这个简单策略设置可以将副本分布在集群中，有利于组件失败情况下的负载均衡。但是，这个简单策略加大了写的代价，因为一个写操作需要传输block到多个机架。
    在大多数情况下，replication因子是3，HDFS的存放策略是将一个副本存放在本地机架上的节点，一个副本放在同一机架上的另一个节点，最后一个副本放在不同机架上的一个节点。机架的错误远远比节点的错误少，这个策略不会影响到数据的可靠性和有效性。三分之一的副本在一个节点上，三分之二在一个机架上，其他保存在剩下的机架中，这一策略改进了写的性能。

2、副本的选择，为了降低整体的带宽消耗和读延时，HDFS会尽量让reader读最近的副本。如果在reader的同一个机架上有一个副本，那么就读该副本。如果一个HDFS集群跨越多个数据中心，那么reader也将首先尝试读本地数据中心的副本。

3、SafeMode
    Namenode启动后会进入一个称为SafeMode的特殊状态，处在这个状态的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳包和Blockreport。Blockreport包括了某个Datanode所有的数据块列表。每个block都有指定的最小数目的副本。当Namenode检测确认某个Datanode的数据块副本的最小数目，那么该Datanode就会被认为是安全的；如果一定百分比（这个参数可配置）的数据块检测确认是安全的，那么Namenode将退出SafeMode状态，接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些block复制到其他Datanode。

五、文件系统元数据的持久化
    Namenode存储HDFS的元数据。对于任何对文件元数据产生修改的操作，Namenode都使用一个称为Editlog的事务日志记录下来。例如，在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示；同样，修改文件的replication因子也将往 Editlog插入一条记录。Namenode在本地OS的文件系统中存储这个Editlog。整个文件系统的namespace，包括block到文件的映射、文件的属性，都存储在称为FsImage的文件中，这个文件也是放在Namenode所在系统的文件系统上。
    Namenode在内存中保存着整个文件系统namespace和文件Blockmap的映像。这个关键的元数据设计得很紧凑，因而一个带有4G内存的 Namenode足够支撑海量的文件和目录。当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作用（apply)在内存中的FsImage ，并将这个新版本的FsImage从内存中flush到硬盘上,然后再truncate这个旧的Editlog，因为这个旧的Editlog的事务都已经作用在FsImage上了。这个过程称为checkpoint。在当前实现中，checkpoint只发生在Namenode启动时，在不久的将来我们将实现支持周期性的checkpoint。
    Datanode并不知道关于文件的任何东西，除了将文件中的数据保存在本地的文件系统上。它把每个HDFS数据块存储在本地文件系统上隔离的文件中。 Datanode并不在同一个目录创建所有的文件，相反，它用启发式地方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录。在同一个目录创建所有的文件不是最优的选择，因为本地文件系统可能无法高效地在单一目录中支持大量的文件。当一个Datanode启动时，它扫描本地文件系统，对这些本地文件产生相应的一个所有HDFS数据块的列表，然后发送报告到Namenode，这个报告就是Blockreport。

六、通讯协议
    所有的HDFS通讯协议都是构建在TCP/IP协议上。客户端通过一个可配置的端口连接到Namenode，通过ClientProtocol与 Namenode交互。而Datanode是使用DatanodeProtocol与Namenode交互。从ClientProtocol和 Datanodeprotocol抽象出一个远程调用(RPC），在设计上，Namenode不会主动发起RPC，而是是响应来自客户端和 Datanode 的RPC请求。

七、健壮性
    HDFS的主要目标就是实现在失败情况下的数据存储可靠性。常见的三种失败：Namenode failures, Datanode failures和网络分割（network partitions)。
1、硬盘数据错误、心跳检测和重新复制
    每个Datanode节点都向Namenode周期性地发送心跳包。网络切割可能导致一部分Datanode跟Namenode失去联系。 Namenode通过心跳包的缺失检测到这一情况，并将这些Datanode标记为dead，不会将新的IO请求发给它们。寄存在dead Datanode上的任何数据将不再有效。Datanode的死亡可能引起一些block的副本数目低于指定值，Namenode不断地跟踪需要复制的 block，在任何需要的情况下启动复制。在下列情况可能需要重新复制：某个Datanode节点失效，某个副本遭到损坏，Datanode上的硬盘错误，或者文件的replication因子增大。

2、集群均衡
   HDFS支持数据的均衡计划，如果某个Datanode节点上的空闲空间低于特定的临界点，那么就会启动一个计划自动地将数据从一个Datanode搬移到空闲的Datanode。当对某个文件的请求突然增加，那么也可能启动一个计划创建该文件新的副本，并分布到集群中以满足应用的要求。这些均衡计划目前还没有实现。

3、数据完整性
从某个Datanode获取的数据块有可能是损坏的，这个损坏可能是由于Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端软件实现了HDFS文件内容的校验和。当某个客户端创建一个新的HDFS文件，会计算这个文件每个block的校验和，并作为一个单独的隐藏文件保存这些校验和在同一个HDFS namespace下。当客户端检索文件内容，它会确认从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode获取该block的副本。

4、元数据磁盘错误
    FsImage和Editlog是HDFS的核心数据结构。这些文件如果损坏了，整个HDFS实例都将失效。因而，Namenode可以配置成支持维护多个FsImage和Editlog的拷贝。任何对FsImage或者Editlog的修改，都将同步到它们的副本上。这个同步操作可能会降低 Namenode每秒能支持处理的namespace事务。这个代价是可以接受的，因为HDFS是数据密集的，而非元数据密集。当Namenode重启的时候，它总是选取最近的一致的FsImage和Editlog使用。
   Namenode在HDFS是单点存在，如果Namenode所在的机器错误，手工的干预是必须的。目前，在另一台机器上重启因故障而停止服务的Namenode这个功能还没实现。

5、快照
   快照支持某个时间的数据拷贝，当HDFS数据损坏的时候，可以恢复到过去一个已知正确的时间点。HDFS目前还不支持快照功能。

八、数据组织
1、数据块
    兼容HDFS的应用都是处理大数据集合的。这些应用都是写数据一次，读却是一次到多次，并且读的速度要满足流式读。HDFS支持文件的write- once-read-many语义。一个典型的block大小是64MB，因而，文件总是按照64M切分成chunk，每个chunk存储于不同的 Datanode
2、步骤
    某个客户端创建文件的请求其实并没有立即发给Namenode，事实上，HDFS客户端会将文件数据缓存到本地的一个临时文件。应用的写被透明地重定向到这个临时文件。当这个临时文件累积的数据超过一个block的大小（默认64M)，客户端才会联系Namenode。Namenode将文件名插入文件系统的层次结构中，并且分配一个数据块给它，然后返回Datanode的标识符和目标数据块给客户端。客户端将本地临时文件flush到指定的 Datanode上。当文件关闭时，在临时文件中剩余的没有flush的数据也会传输到指定的Datanode，然后客户端告诉Namenode文件已经关闭。此时Namenode才将文件创建操作提交到持久存储。如果Namenode在文件关闭前挂了，该文件将丢失。
   上述方法是对通过对HDFS上运行的目标应用认真考虑的结果。如果不采用客户端缓存，由于网络速度和网络堵塞会对吞估量造成比较大的影响。

3、流水线复制
    当某个客户端向HDFS文件写数据的时候，一开始是写入本地临时文件，假设该文件的replication因子设置为3，那么客户端会从Namenode 获取一张Datanode列表来存放副本。然后客户端开始向第一个Datanode传输数据，第一个Datanode一小部分一小部分（4kb)地接收数据，将每个部分写入本地仓库，并且同时传输该部分到第二个Datanode节点。第二个Datanode也是这样，边收边传，一小部分一小部分地收，存储在本地仓库，同时传给第三个Datanode，第三个Datanode就仅仅是接收并存储了。这就是流水线式的复制。

九、可访问性
    HDFS给应用提供了多种访问方式，可以通过DFSShell通过命令行与HDFS数据进行交互，可以通过java API调用，也可以通过C语言的封装API访问，并且提供了浏览器访问的方式。正在开发通过WebDav协议访问的方式。具体使用参考文档。
十、空间的回收
1、文件的删除和恢复
    用户或者应用删除某个文件，这个文件并没有立刻从HDFS中删除。相反，HDFS将这个文件重命名，并转移到/trash目录。当文件还在/trash目录时，该文件可以被迅速地恢复。文件在/trash中保存的时间是可配置的，当超过这个时间，Namenode就会将该文件从namespace中删除。文件的删除，也将释放关联该文件的数据块。注意到，在文件被用户删除和HDFS空闲空间的增加之间会有一个等待时间延迟。
    当被删除的文件还保留在/trash目录中的时候，如果用户想恢复这个文件，可以检索浏览/trash目录并检索该文件。/trash目录仅仅保存被删除文件的最近一次拷贝。/trash目录与其他文件目录没有什么不同，除了一点：HDFS在该目录上应用了一个特殊的策略来自动删除文件，目前的默认策略是删除保留超过6小时的文件，这个策略以后会定义成可配置的接口。

2、Replication因子的减小
    当某个文件的replication因子减小，Namenode会选择要删除的过剩的副本。下次心跳检测就将该信息传递给Datanode， Datanode就会移除相应的block并释放空间，同样，在调用setReplication方法和集群中的空闲空间增加之间会有一个时间延迟。

参考资料：
HDFS Java API: http://hadoop.apache.org/core/docs/current/api/
HDFS source code: http://hadoop.apache.org/core/version_control.html

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

两段java代码的比较

dennis_zane — Sat, 31 May 2008 17:36:19 +0800

作者: dennis_zane 链接：http://dennis-zane.javaeye.com/blog/198999 发表时间: 2008年05月31日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

第一个程序：

import java.util.ArrayList;
import java.util.List;

public class TailRecursionTest {
    public static void main(String[] args) {
        TailRecursionTest t = new TailRecursionTest();
        for (int i = 0; i < 10000; i++)
            t.a(0);
    }

    public void a(int j) {
        j++;
        List list = new ArrayList(100000);
        // 对list进行处理
    }
}

没啥特殊的，仅仅是为了测试，我们将a方法调用10000次，a方法创建一个有100000个元素的list的局部变量。
第二个程序：

import java.util.ArrayList;
import java.util.List;

public class TailRecursionTest2 {
    public static void main(String[] args) {
        TailRecursionTest2 t = new TailRecursionTest2();
        t.a(0);
    }

    public void a(int j) {
        System.out.println(j);
        j++;
        if (j == 10000)
            return;
        List list = new ArrayList(100000);
        // 对list进行处理
        a(j);
    }
}

也没啥特殊的，就是将循环换成了递归，a方法做的事情没变。两个都跑一下，程序1顺利结束，程序2出问题了，啥问题？如下：

161
162
163
164
165
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.ArrayList.(Unknown Source)
    at TailRecursionTest2.a(TailRecursionTest2.java:17)
    at TailRecursionTest2.a(TailRecursionTest2.java:20)
    at TailRecursionTest2.a(TailRecursionTest2.java:20)
    at TailRecursionTest2.a(TailRecursionTest2.java:20)
    at TailRecursionTest2.a(TailRecursionTest2.java:20)

我倒，才运行166次了，heap就满了。问题在哪呢？oh,yep，你肯定想到了，是不是重复创建list这个大集合引起的呢？它不是局部变量吗？怎么也会溢出？是的，list是局部变量，在a的方法栈里引用着，指向heap上的大对象，更关键的问题在于，java是没有尾递归优化的，递归方法是不会使用同一个栈帧，每一次递归调用，都将压入新的栈帧，并且这个栈帧上又new了一个list变量，引用着heap上新的一个大集合。随着栈深度的增加， jvm里维持着一条长长的方法调用轨迹以便你能回来，在方法没有返回之前，这些list变量一直被各自的栈帧引用着，不能被GC，你说，能不OOM吗？

也许，你想到了个补救方法来挽救程序2，就是每次在处理完list后，我把它设置为null，不让栈帧继续引用着它，咱编写对gc友好的代码，这不就行了，试试：

import java.util.ArrayList;
import java.util.List;

public class TailRecursionTest2 {
    public static void main(String[] args) {
        TailRecursionTest2 t = new TailRecursionTest2();
        t.a(0);
    }

    public void a(int j) {
        System.out.println(j);
        j++;
        if (j == 10000)
            return;
        List list = new ArrayList(100000);
        // 对list进行处理
        list = null;  //gc友好
        a(j);
    }
}

得意洋洋，我跑一下看看，这次跑到4000多次，但是：

......
4289
4290
4291
4292
java.lang.StackOverflowError
    at sun.nio.cs.ext.DoubleByteEncoder.encodeArrayLoop(Unknown Source)
    at sun.nio.cs.ext.DoubleByteEncoder.encodeLoop(Unknown Source)
    at java.nio.charset.CharsetEncoder.encode(Unknown Source)

没办法啊，人家sun的jdk就是不支持尾递归优化(据说传闻在jdk5的某个版本是有尾递归优化的），很不给你面子的栈溢出了。ibm的jdk据说支持尾递归优化，上面这个程序在ibm的jdk上可能可以正常结束，未经测试。

总结：在java里，递归最好咱还是别用，老老实实地while、for；就算递归了，最好递归方法不要new太大的对象，除非你能确定递归的深度不是那么大，否则OOM和堆栈溢出的阴影将笼罩着你。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐