豆瓣网技术架构发展历程

http://www.xpzhu.com/index.php/article/view/id/26

不是一天建成的，豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。洪强宁，2002 年毕业于清华大学，现任北京豆瓣互动科技有限公司首席架构师。洪强宁和他带领的技术团队致力于用技术改善人们的文化和生活品质，在网站架构、性能、可伸缩性上进行深入研究。豆瓣网曾获软件中国2006年度最佳技术应用网站。

校内网CTO黄晶讲述网站架构变迁

每个网站的发展都会按照一个大致相同的路线去完成，当然这里说的是每个相对成功的网站。

第一阶段：

这一阶段没有太大的访问量，甚至只有一台服务器就搞定了所有的访问。DB 和前端的代码全都在一起，压力不高。忆者注：我觉得在alexa 没进五万的时候，只要不是特殊的应用，基本都在此列吧。

第二阶段：

网站初具规模，DB压力大增，单独的一台DB已经满足不了现在的访问量，开始考虑读写分离的Master-slave 库，使用三个及以上的服务器。忆者注：这时网站的alexa基本上会在1-3万的位置，每天的ip在5-10w的样子，当然，DB我们都认为是MySql。

第三阶段：

访问量继续增加，增加到了DB的压力在Master的机器上非常的明显了，Master开始出现吃不消的情况，出现写耗尽。主从也已经不能满足要求，需要进一步解决负载问题，此时要引入Mysql Proxy 程序，进行中间层代理，实现负载均衡，易于扩展。忆者注：这时网站已经不可限量了，先恭喜下你的网站能用到这段。

第四阶段：

网站继续发展，进而出现了数据量的成倍增长，原来的N台DB都出现了一个问题，数据量巨大，无法完成正常速度的读写。此时，需要对网站按功能进行垂直划分，比如用户注册登录是一部分、UGC又是另一部分。与此同时，对数据本身进行水平划分，也就是Hash散表或者是散库。

第五阶段：

真的没了。再往下玩就灭了。

其实再进一步第五第六阶段，就是无法预想的未来了，也许有什么突飞猛进的科学技术发明也说不好。

技术的选择

一直以来，豆瓣在技术上都给人很前卫的感觉，看起来好像什么新用什么，其实是不是的，他们一直是“用已掌握的技术解决问题”，现有的东西如果够用，那么就没必要一定迁移到新的上面去，而转换往往是为了解决当前问题。另外，换用新的东西，要有足够的驾驭能力，从演讲中得知，豆瓣曾有几次在临上线前发现基础库的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 系统也在用。