这次的 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 中文站会发布，我这里就不掠美了。
赞!期待PPT和视频。豆瓣的这场应该是QCon中最受关注的吧，向豆瓣学习。
作为用户，非常喜欢豆瓣的URL结构，看起来很舒服。
期待期待！豆瓣！豆瓣！
关于[杜绝远程 I/O]不知道是多大数据和多少req/s的写入？如果每秒req不多而且数据包不大的话(我们大概是150-200REQ/S的数据库写入)，我觉得是可以的，有个业务我们当初就是这么做的，现在还一直在这么做，没有发现什么大问题啊:)
现在再选硬盘可以考虑SSD了，当然，价格也还是比较贵。
在牛博国际看到这篇文章，摸过来了。豆瓣人很大气
主要顶最后一句话，很多公司/人有好东西不肯分享，看别人说出来了心里就酸溜溜的。
不错 看看ppt
的确,最后一句话说的好.
如果你早知道了,没有为什么不告诉大家.
豆瓣很无私.
mekle tree, 很多P2P软件如BT,以及很多DHT相关系统都在使用..其中也有Amazon的Dynamo
我们的确早就用了 因更新文件量多量大（大量课件 —— 视频 文档 图片 ppt） 内部网 节点多 网速慢 服务器IO还临近饱和 各节点从服务器上更新文件成了大麻烦 后来设计： 文件全当成二进制字节流 切割 100kb每块 在数据库存文件hash字串 和最后修改时间 通过比对hash字串先判断更新节点 B树查找 回归根节点 更新 在PHP中调用C写的dll实现 绕很多弯路后 参考了emule的设计实现 不是不想分享 没时间写东西（小公司天天加班） 代码很乱 效率低下 也没时间做优化 更主要是虽然中间实现的代码写的很麻烦 但是基本思想应该还算简单 很多p2p软件都已经实现 怕这么后知后觉的东西分享出来丢人现眼
我不太明白，这个和Merkle tree有什么关系？用inotify监控文件系统变化，每次有变化，就专门记录到一个某一个文本文件里面，rsync的时候，只更新这个文件里面提到的文件，不就ok？
@bob
你可能的确不明白。这是 DoubanFS 的同步机制. 不是普通的 fs .
我的理解是这个是为了解决 “大量小文件同步问题”，如果直接在现有文件系统中rysnc，哪确实会扫描文件夹时间过长，用linux2.6支持的 inotify记录文件系统的变化，即增量，是一个不错的方法，已经解决了痛苦，但是为什么要组织成tree的形式的？有什么好处？ 如果 doubanFS是 mogilefs这样的系统，也不会能直接用rysnc.
或许有一种可能是 doubanfs 自己实现了数据块类的fs，用 Hash Tree实现了 inotify的功能
@bob
小文件过多，通过目录的形式管理肯定有不少麻烦(数量少还可以,通过 inotify 是非常完美的办法). 另外一个问题是，inotify 对付份多台机器的分布可能也不是很完美吧
这个问题是你说的后者。
感觉豆瓣是国内Web 2.0网站中各方面都做得比较好的。看好…
磁盘转速和继续保持URL友好风格这两点，在企业级Portal架构中也值得借鉴。其实每一点都是，学习了。感谢！
对于国内IT圈，不太愿意共享资源的现实，我有同感。希望以后风气能够好转吧。
“小文件过多，通过目录的形式管理肯定有不少麻烦”你的意思说
小文件太多了，所有的文件放在一个目录里？然后通过实现的那个tree和修改时间来管理文件的同步？
没参加，真的感觉太可惜了！楼主是否有豆瓣架构的ppt之类的资料，可以分享下吗？
firefox下浏览页面 布局有问题，留意部分跑到上面去了。和正文重叠。
草根技术，喜欢豆瓣的架构
本人应届小硕一枚，请问美团网技术部前端开发的发展怎么样？团购网站靠谱否？真心求大牛指教，感激不尽。