易栈网-膘叔

最近一段时间各个网站都在公布自己的架构体系等信息，在dbanotes上也看到了作者写的关于豆瓣网的一些资料，并加以了分析。反正不管是什么网站的架构，我都保留了下来。作为参考，文末，说infoQ会公布PPT，那就等公布了我再下载下来。

作者：Fenng 发布在 dbanotes.net

这次的 QCon 会议，《豆瓣网技术架构的发展历程》这个议题差不多是最受关注的。洪强宁在演讲开始告诫大家期望值不要太高，我还是相信不会有人觉得失望的。

先说几句题外话，整个演讲听下来，我们会发现豆瓣在 发展的过程中也是有点弯路，这些是一个网站发展过程中的宝贵财富，能把自己有周折的地方大大方方的拿出来，是难能可贵的事情。尽管豆瓣批露了很多架构细节 出来，也不会(也不可能)有哪个公司一拿到这些东西，就能照猫画虎再做一个豆瓣并且超过豆瓣。从某种程度上来说这体现了豆瓣同学们的气度，这是令国内大多 数公司汗颜的。很多公司只愿索取，而不愿奉献哪怕一点点出来，用这样封闭的心态对待技术其实是小家子气，守财奴的思维。技术只有为更多人所用才是大道。

议论说完，再来叙述。写点对豆瓣架构的体会。戏法人人会变，各有巧妙不同。有些东西大家都在用(Nginx)，但是有人的用得好，有人用了比不用还差。所以，需要逐渐总结，改进。学习别人的架构设计，不是要照搬，而是借鉴其思想。

技术的选择

一直以来，豆瓣在技术上都给人很前卫的感觉，看起来好像什么新用什么，其实是不是的，他们一直是"用已掌握的技术解决问题"，现有的东西如 果够用，那么就没必要一定迁移到新的上面去，而转换往往是为了解决当前问题。另外，换用新的东西，要有足够的驾驭能力，从演讲中得知，豆瓣曾有几次在临上 线前发现基础库的Bug(比如 Libmemcached 的一致性哈希相关的Bug)，技术团队能在第一时间有进行修复并且提交给开源社区。否则的话，就变成了一种错误决策了。

磁盘转速

小话题。如果可能，直接买 15000 转的磁盘好了。10000 转的磁盘可能省钱，但这东西部署了之后几乎就不太可能升级。所以，如果是初创公司，我的建议就是买高速磁盘，因为业务如果发展快了的话，先前对机器的定位也可能发生变化。

杜绝远程 I/O

在普通的 TCP/IP 网络的环境下，不要进行远程数据写入操作。跨网络操作的延时看似没什么大不了的，但一旦达到临界点就回天乏术。这个事情基本是不撞南墙不回头，有的技术人员总要亲身体验一把才肯罢休。

持续保持 URL 友好风格

演讲中有多次提到一致性 URL ，其实体现了豆瓣对 URL Rewrite 的重视，结构调整，或者应用程序变化的时候，URL 最好做到"用户友好"的。这算是"软技术"，但是应该加以最大的重视。

数据库复制延迟问题

对于 MySQL 复制的环境，如果Slave 上有读取操作，那么有些情况下可能因为 Master 和 Slave 节点数据不一致对用户造成困惑。如果从一致性的角度上考虑，其实也不复杂:，只需要对"知道数据发生了变化的用户"提供一致性就行了(基本上就是发起变更 的用户)，不知道数据发生变化的用户对数据的不一致有一定的"容忍程度"，当然说着简单，实现起来还是需要技巧和精巧的。

大量小文件同步问题：Merkle tree

关于大量小文件的同步问题，很多上了规模的网站都会遇到，如果设计得不好或者是比较偷懒，用传统的办法(比如 rsync 之类的老模式)很容易触发问题，也浪费资源。DoubanFS 是用 Merkle tree(Hash Tree)的方式进行数据同步的。对这个问题的具体描述可以参见《大量小文件的实时同步方案》。Merkle Tree 是个很精巧的思路，ZFS 在用(refer)，Amazon Dynamo 系统也在用。

不会一会儿又有人留言说：我们早就采用这个思路了...... 我这里预先来句回答：拜托，你早点共享啊?

--EOF--

完整的 PPT 过几天 InfoQ 中文站会发布，我这里就不掠美了。

以下内容来自于两个博客的内容合并。
首先是来自于冰山上的博客的关于atime、mtime与ctime的介绍（我估计作者也是COPY来的，因为最后两段明显单词断行了，没有修改）：

原文：http://xinsync.xju.edu.cn/index.php/archives/4683

atime 访问时间(access time)：访问时间是文件最后一次被读取的时间。因此阅读一个文件会更新它的访问时间，而它的改变时间并没有变化(有关文件状态的信息没有被改变)，它的修改时间也同样没有变化(文件内容本身没有被改变)；

mtime 修改时间(modification time)：文件内容最后被修改的时间。如 echo “Hello” >myfile ，则myfile的mtime被改变，同时ctime和atime也被改变；

ctime 改变时间(change time)：文件状态（status）最后被改变的时间。如 chmod a+w myfile ，则myfile的ctime被改变，atime和mtime都不变；

参考：

st_atime
Time when file data was last accessed. Changed by  the following   functions:   creat(),   mknod(),   pipe(), utime(2), and read(2).

st_mtime
Time when data was last modified. Changed by the  fol-lowing  functions:  creat(), mknod(), pipe(), utime(),and write(2).

st_ctime
Time when file status was last changed. Changed by the following   functions:   chmod(),   chown(),  creat(),link(2),  mknod(),  pipe(),  unlink(2),  utime(),  and write().

然后下面的内容又来自于知道分子的博客：http://hutuworm.blogspot.com/2009/03/blog-post_31.html

Linus 大神最近将一项名为 relatime 的特性设定为内核默认行为。（参阅：Matthew Garrett，Reducing disk use）

UNIX 文件系统中的 ctime、mtime、atime 属性分别记录了文件的创建时戳、修改时戳和访问时戳。每当有进程创建、修改、访问某个文件时，文件系统就会保存相应的时戳。对于一般用户而言，文件系统自 动记录这些时戳所花费的时间根本不值一提，完全可以忽略不计。但对于某些特定用途的生产服务器，比如存储大量小图片文件的服务器（写少读多），若每次读取 一个文件都要修改该文件的 atime——想像中的单纯读取操作，实际上却是一读一写——如果这些服务器访问量还挺大，那么这个过程中的消耗则无疑值得斤斤计较、细细考究了。

以 往我们为了节省不必要的 atime 改写，常常采用的方法，是通过 mount 选项 noatime 挂载文件系统，完全摈弃该属性。但随之而来的问题是，某些依赖于 atime 属性的系统程序无法正常工作。而 relatime 补丁的改进之处在于，仅当 atime 比 ctime 或 mtime 更早，或者早于当前时间 24 小时以上，系统才会去修改 atime，由此就大幅度减少了 atime 改写操作，提升了文件系统性能。该项功能已在 Fedora 和 Ubuntu 去年的新版本中发布。

其 实，可以节省的地方还有很多。上周小算了一笔账，某个页面引用的 js 和 css 文件 Expire 时间为 900 秒，一部分图片的 Expire 时间为 12 小时，另一部分图片的 Expire 时间为 4 天——假设该页面内容不变、访问量不变，那么一年的相关静态文件总下载量为数万 GB；如果把这些静态文件的 Expire 时间统一调整为一个月，那么总下载量可以下降一个数量级，降到几千 GB；如果胆子大一点、步子快一点，统一调整为一年，那么总下载量还可以再降一个数量级，降到几百 GB。阿米豆腐，这样的估算结果真是令人咋舌。

这两天又看了三篇跟性能优化相关的报道。一篇报道是 Linux Magazine 采访 Theodore Ts'o，其中提到 Google 的工程师向 Ext4 文件系统开发者提交了一个取消日志补丁，以获得更高的性能，可以看出，这个功能对于 Google 非常重要。一篇报道是 Red Hat 官方新闻，说 RHEL 5.3 开始支持 Intel 的 QuickPath 内存技术，运行内存密集型的应用可以获得两倍性能提升——显然这得归功于 Nehalem CPU 的崭新架构和超强性能。另一篇报道是 Linux Kernel 2.6.24 到 2.6.29 横向测试，OpenSSL 在 2.6.29 内核上测得性能比前几个版本高出一倍：


无论如何，关注这些信息，稍微算一算，我们就知道随便从其中找一项出来优化，可以提升多少性能、节省多少资源。虽说咱不差钱，但能省干嘛不省呢？

原文来自：http://blog.s135.com/post/407/，本文纯粹是转载。
不过，我看到张宴博客里介绍的时候，很是惊讶于google docs的功能，原来，google docs居然也能够象其他那些Webshare网站那样显示PPT或者PDF？点击放大后，还能够下载成PDF或者PPT，而且效果不错，感觉就象FLASH一样。看来什么时候是需要学习一下如何使用了，因为google的速度不错，在与很多人分享资料的时候就比较方便了

更多看全文

» 阅读全文

最近关于SVN的资料，一直都是粘贴网上的信息到勃客上来。
现在再放上SVN中文资料。可以对照着看看。。。

同样，是一篇摘录，笔记。勿怪。。。
原文：http://www.cnblogs.com/chenlong828/archive/2008/09/22/1296193.html
作者：dreamland

查阅了一下网络和博客园，发现还没有一个明确地指导源码管理提交准则的相关文章，因此斗胆整理了一部分自己平时开发管理的心得，加上查阅了部分英文资料写了一个不算很完善的SVN提交准则。

负责而谨慎地提交自己的代码

SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交。

如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。

如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。

保持原子性的提交

每次提交的间歇尽可能地短，以一个小时，两个小时的开发工作为宜。如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。

不要提交自动生成的文件

Visual Studio在生成过程中会产生很多自动文件，如.suo等配置文件，Debug,Release,Obj等编译文件，以及其他的一些自动生成，同编译代码无关的文件，这些文件在提交的时候不应该签入，如果不小心签入了，需要使用Delete命令从仓库中删除。

不要提交不能通过编译的代码

代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库或者没有放入GAC（针对.Net Framework）中，项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。

不要提交自己不明白的代码

代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。

提前宣布自己的工作计划

在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。

对提交的信息采用明晰的标注

+) 表示增加了功能

*) 表示对某些功能进行了更改

-) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。

b) 表示修正了具体的某个bug