为七牛云图床的上传生成markdown格式日志

博客迁移到hexo后,使用七牛云作为图床,日常就用它的命令行工具qrsync上传图像,上传成功后会显示日志。有点不爽的是日志中只是显示上传到服务器上的相对路径的文件名称,在写markdown 格式时,还需要自己去补充类似“![]”,然后再补充完整url信息。

于是就在日志信息后加一个sed的脚本做替换,帮自动生成markdown格式,书写自然就方便了。

1
/Users/yangbin/bin/qrsync /Users/yangbin/bin/qiniu-conf.json 2>&1 |sed -e 's/\(=> xbin999:\)\(.*\)/=> ![](http:\/\/xbin999.qiniudb.com\/\2\)/'

另一种只显示结果文件格式的可以参见gist

编写markdown文档直接发布到wordpress上



我现在用nvALT来书写markdown文档,有时想把写好的文章发布到自己的博客上,比较土的方式往往是先预览,然后打开博客编辑,复制粘帖。

想想是不是可以简化一下,能直接把写好的markdown文档发布到wordpress博客上。试了一下,分三步走:

1. 可以把nvALT的存储模式设置成普通文本文件(Plain Text Files ),这样写好的内容就会以单个文件形式保存在设置的目录中。
2. 然后使用flavor 讲文件转换成html文件,需要安装ruby 和json。
3. 发布到wordpress上,这个原来想偷点懒,直接基于wordpress提供的发布邮件账号,通过邮件发出即可,但后来发现直接基于命令行上的mail命令,不支持html文本。只好另外想办法,找个API来直接调用接口发布。wordpress支持xmlrpc,有个简单的例子Simple WordPress Posting from Ruby via XMLRPC,直接搬来使用即可。
4. 最后做的事情就是把flavor和上面的例子串接一下,代码放在github上。
这篇文档就是以这个方式完成发布的,测试的过程中碰到几个问题:
运行flavor时报错

~/.rvm/gems/ruby-1.9.3-p125/gems/json-1.7.5/lib/json/ext/parser.bundle: [BUG] Segmentation fault
ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0]
</pre> 这个原因是flavor.rb指定了/usr/bin/ruby,和我的rvm环境不一致,修改ruby运行环境即可。 * 命令行下mail 运行时报错 <pre>sendmail: fatal: chdir /Library/Server/Mail/Data/spool: No such file or directory

这里需要设置mac下的mail环境,有篇详细的说明
* 中文字符的问题

xmlrpc/create.rb:46:in `join’: incompatible character encodings: UTF–8 and ASCII–8BIT (Encoding::CompatibilityError)

这里需要讲flavor调用github解析返回的结果做强制编码html.force_encoding(“UTF–8”).encode(“UTF–8”)。

采用markdown来编写文档

很多时候记会议纪要,用word写吧,觉得太笨重,慢;用文本写,写标题1, 2, 3, … 结果前后一调整,或者插入/删除一行就要去重新调整序号,实在难受。随它去呢,又让我这种偏执的人感到别扭。

讨厌在书写的时候要考虑格式的设置,markdown确实是一个很好的解决方法,好好学学,强迫自己习惯markdown的编写。最基本的编写也就那么几个:

  1. 用几个#号来标识标题。
  2. 段落的写法,第一个是数字,那就按数字1,2,3排,非数字就是符号排的段落,第一个字符用-, *, + 都可以。
  3. 链接的写法,最简单的就是中括号里写文字,后面小括号里写链接,相同主机内可以使用相对路径。
  4. 对写代码的人来说,还有一个要记住的是用反引号`把代码给括起来。
    我觉得有这么几招就差不多了,顶多用两个星号搞搞粗体、一个星号斜体,详细的使用帮助可以参见markdown语法说明

“工欲善其事,必先利其器。”

首先,我得选择一个文本编写工具来替代Stickies,支持markdown,简单一点,能自动保存。Mou 不够简单,还是觉得nvALT 不错,简洁得很,同时支持Simplenote 的云服务。(Simplenote 同时提供iphone/ipad下的客户端应用,虽然Simplenote 在国内访问貌似不畅。)

其次需要能把markdown文件转成html文件,将格式内容进行保存或者发布到博客中(我一般还是会保存在Evernote中,话说Evernote什么时候能支持markdown啊)。nvALT 本身能提供预览并保存html文件。另外mac下还有两个不错的工具:

  • 一个是chrome扩展Markdown here 对于使用gmail的人来说有帮助,先用markdown写邮件,然后使用该插件Markdown Toggle做一次转换即可;
  • 一个是md ,提供了mac OS下的一堆服务,让你在文本编辑下右键菜单出现一堆常用的markdown服务。
    最后再推荐gollum ,基于git 的个人wiki管理工具,和nvALT 配合(nvALT 本身也能提供页面的跳转,够强大吧),一个写markdown文件,一个提供wiki页面和搜索。

先写这么多,等使用时间长了,有心得再做更新,这篇文章就是基于nvALT 写的。

《高可用性的HDFS-HADOOP分布式文件系统深度实践》读书笔记

最近有项目在用HADOOP,比较关心NameNode的HA机制,翻了《高可用性的HDFS》,感觉整体内容并不多,较多的是代码、环境安装和测试,不过对于我这个门外汉来说,快速入门吧。以下是笔记:

HDFS的HA主要由NameNode的HA决定,NameNode的可靠性主要取决于自身计算机硬件系统的可靠性、系统软件以及HDFS软件的可靠性;NameNode的可维护性则取决于元数据的可靠性以及NameNode服务恢复时间。

比较成熟的HA解决方案有:

  • Hadoop的元数据库备份方案
  • Hadoop的Secondary NameNode方案
  • Hadoop的Checkpoint Node方案
  • Hadoop的Backup Node方案
  • DRDB方案
  • Facebook的Avatarnode方案
    元数据备份方案和DRRB方案不能单独使用,因为在系统的运行期间,没有相应的checkpoint机制,会造成日志的无限制增长。

Hadoop的元数据库备份方案

hadoop的自身failover机制,配置dfs.name.dir,将元数据保存到多个目录(一个本地,一个远程,通过NFS进行共享)

  • hadoop自带机制,成熟可靠,元数据有多个备份,写多份效率低;
  • 没有做到热备,需要重启NameNode,恢复时间与文件系统规模成正比;

Hadoop的Secondary NameNode方案

启动一个Secondary NameNode节点,定期从NameNode下载元数据信息(元数据镜像fsimage和操作日志edits),然后将fsimage和edits进行合并,生成新的fsimage,本地保存再推送到NameNode,再重置edits。

  • 定期做checkpoint,Secondary NameNode不是最新数据,存在一致性问题;
  • 没有热备;

Hadoop的Checkpoint Node方案

原理同上,但采用checkpoint机制进行备份。

Hadoop的Backup Node方案

不成熟,0.21以上版本支持,特性开发中

最终目标是为HDFS提供NameNode的热备节点,减少服务恢复时间,实现原理:通过同步更新机制,在BackupNode节点中保存一份与NameNode完全一致的内存镜像,并且当NameNode无法提供服务时,能自动接管。

三个阶段:

  • Checkpoint Node,定期checkpoint到磁盘;
  • Backup Node,改进checkpoint机制,同步更新backup node内存,backup node利用自身镜像做checkpoint;
  • Standby Node,实现热备。
    目前0.21.0实现了第一、二阶段。

在第二阶段的Backup Node中,采用了日志池(journal spool)的机制,用于缓存NameNode发送过来的来不及处理的日志记录。

DRDB方案

  • 元数据有多个备份,并且保持最新状态
  • 备份工作由DRDB完成,NameNode无需同步写多个备份目录,效率由于hadoop元数据备份方案;
  • 没有热备,备份节点切换时间长

Facebook的AvatarNode方案

Facebook提出并实现了HDFS的热备。Active Node作为Primary NameNode对外提供服务,Standby Node处于Safe mode模式,内存中保存Primary NameNode最新的元数据信息。Active Node和Standy Node通过NFS共享存储进行交互。DataNode同时向Active Node和Standby Node发送Block location信息。

  • 提供热备,切换时间短;
  • facebook的代码版本;
  • Primary AvatarNode和Standby Node都继承自NameNode,Primary AvatarNode对外提供服务;
  • Standyby AvatarNode也运行一个NameNode进程,并与Primary AvatarNode的内存元数据保持同步,两者通过NFS进行元数据同步;
  • DataNode将Primary AvatarNode和Standby AvatarNode视之为两个NameNode,分别上报Block信息等;
  • Clients是Facebook提供的AvatarNode客户端;
  • NFS理论上是一个新的单一故障点(应该可以用SYMANTEC CFS代替
    注:BackupNode类似于同步写,日志要等待BackupNode更新后再将日志记录写到磁盘;而AvatarNode则是异步写,将日志写入NFS共享目录即结束。

Block更新同步问题:客户端写入一个文件A,写入成功后,Data Node分别向Primary和Standby报告Block位置信息,但由于同步周期未到,Standby里没有文件A的信息,此时Standby会循环检查对应关系,直到收到Primary送过来的日志有关于文件A与Block的对应关系信息。

关于源代码:

  • Patch方式,直接作用于hadoop官方版,支持0.20;
  • Facebook维护的hadoop分支;

元数据解析

元数据有三类重要信息:

  • 文件和目录自身的属性信息,例如文件名,目录名,父目录信息,文件大小,创建时间,修改时间等;
  • 文件内存存储相关信息,例如文件分块,副本个数,每个副本所在的DataNode信息等;
  • HDFS中素有DataNode的信息,用于DataNode管理;
    从来源上讲,元数据主要来源于NameNode磁盘上的元数据文件,包括元数据镜像fsimage和元数据操作日志edits两个文件。

INode

文件和目录的抽象,所有INode信息完全位于内存。(类FSImage是内存元数据和磁盘元数据文件之间的桥梁,做内存数据持久化和磁盘文件加载)。

  • HDFS没有采用定期导出元数据的办法,而是采用FSImage+edits的备份机制。
  • HDFS启动时会读取元数据镜像文件和日志文件到内存,进行合并形成最新的内存元数据,再保存到磁盘,形成新的磁盘镜像文件和日志文件。需要消耗一定的时间做合并
  • 运行过程中HDFS不再从内存中到处元数据,而只是记录日志文件。

Block

按照文件大小划分成块,默认Block大小为64MB。

磁盘元数据文件

  • fsimage:元数据镜像文件,存储的是某一时刻NameNode内存元数据信息,包括所有的INode信息、正在写入的文件信息以及其他的一些状态信息;
  • edits:日志文件,保存了该时刻以后元数据的操作记录;
  • fstime:保存了最近一次Checkpoint的时间;
  • VERSION:标志性文件,最后创建,表明前三个文件创建成功。
  • fsimage, edits都有两个状态,以文件名区分。fsimage.ckpt表示checkpoint过程中上传到NameNode的fsimage文件,checkpoint结束时重明明;edits.new同样如此。

几个统计数据

  • facebook集群存储了1.5亿个文件,加载namenode元数据和等待块位置映射信息上报这两个阶段各自耗费的时间大概都在20分钟左右;
  • 在yahoo运行的15个集群中,三年时间内,只有3次NamoNode的故障与硬件问题有关。

关于hadoop的版本

hadoop version

  • Facebook Hadoop分支的版本是再0.20-append基础上,加入自身特性发展起来的;
  • Clourera CDH3
    BTW. 这是第一篇用Mou编写的markdown格式的文章,挺方便的,要是支持直接发布到wordpress上就更好了。