前提说明：研究的hadoop版本1.0.3
checkpoint的触发条件：
- 默认1小时进行一次merge；
- edits的文件大小超过大致64M
以上两个条件，满足任意一个即可，每隔5分钟进行一次条件检查。
checkpoit流程：
- 在SNN（secondary namenode）服务器上检查fs.checkpoint.dir fs.checkpoint.edits.dir配置的文件路径，如果不存在则创建
- 在SNN服务器上修改current文件夹名称为： lastcheckpoint.tmp，并且重新创建一个空的current文件夹
- 通过http请求调用NN（namenode）检查edits.new文件是否已经存在，如果已经存在则检查所有的存放edits文件的文件夹中是否均包含edits.new文件，如果有一个不包含则抛出：Inconsistent existence of edits.new异常，如果均包含，则会输出warn级别的日志，提示：Cannot roll edit log,edits.new files already exists in all healthy directories:并且return。如果不存在则停止edits文件的写入，创建一个临时的edits文件：edit.new，在merge过程中产生的edit log均记录在edit.new中
- 从node下载edits和fimage文件
- Load fimage文件，全部加载到内存，解析完后转换成INode对象到目录树中，节点集合采用ArrayList类型，在集合中定位某个INode时采用Collections的binarySearch()方式实现
- Load edits文件，边读边merge（修改load fimage后的inode对象列表），edits文件的读取采用：DataInputStream类
- 持久化merge后的fimage文件，并创建空的edits文件
- 上传合并后的fimage文件到NN节点，取名：fsimage.ckpt，并放置到current目录中，删除fsimage文件，并更名fsimage.ckpt为fsimage文件，修改edits.new为edits
- 修改lastcheckpoint.tmp目录为previous.checkpoint（存放上次checkpoint的数据）
顺便说三句：
- NameNode启动时先执行edits文件的merge，如果有edits.new则也会执行merge，确保能还原到最新的元数据
- 线上服务器merge一个6.4G的edits文件（fimage文件40M），共耗时28分钟
- 单独启动SNN的命令：hadoop-daemon.sh start secondarynamenode。