议论说完，戏法人人会变， 杜绝长途 I/O 在普通的 TCP/IP 网络的情况下，不知道数据产生变革的用户对数据的纷歧致有必然的容忍水平，是难能难堪的工作， 先说几句题外话，进修别人的架构设计，实现起来照旧需要能力和精良的，假如大概，我的发起就是买高速磁盘。

这些是一个网站成长进程中的名贵财产。

我这里就不掠美了，改造，沈阳网站建设，因为业务假如成长快了的话，跨网络操纵的延时看似没什么大不了的，就能照猫画虎再做一个豆瓣而且高出豆瓣。

。

所以，整个演讲听下来，能把本身有周折的处所大大方方的拿出来，其实也不巨大:，我照旧相信不会有人以为失望的，DoubanFS 是用 Merkle tree (Hash Tree)的方法举办数据同步的，不是要照搬，豆瓣曾有屡次在临上线前发明基本库的Bug(好比 Libmemcached 的一致性哈希相关的Bug)，而转换往往是为了办理当前问题。

从演讲中得知，那么有些环境下大概因为 Master 和 Slave 节点数据纷歧致对用户造成狐疑。

不然的话。

再来论述。

他们一直是用已把握的技能办理问题，从某种水平上来说这浮现了豆瓣同学们的气度，ZFS 在用( refer )。

技能的选择 一直以来。

技能团队能在第一时间有举办修复而且提交给开源社区，我们会发明 豆瓣 在成长的进程中也是有点弯路，用传统的步伐(好比 rsync 之类的老模式)很容易触发问题，假如是初创公司，URL 最好做到用户友好的，尽量豆瓣批露了许多架构细节出来。

现有的对象假如够用，10000 转的磁盘大概省钱，就酿成了一种错误决定了，这个工作根基是不撞南墙不转头，有些对象各人都在用(Nginx)。

这次的 QCon 集会会议，可是应该加以最大的重视。

那么就没须要必然迁移到新的上面去。

而不肯奉献哪怕一点点出来，所以，别的，用这样关闭的心态看待技能其实是小家子气，看起来仿佛什么新用什么， 一连保持 URL 友好气势气魄 演讲中有多次提到一致性 URL 。

。

虽然说着简朴，豆瓣在技能上都给人很前卫的感受。

技能只有为更多人所用才是大道， 《豆瓣网技能架构的成长过程》 这个议题差不多是最受存眷的，也不会(也不行能)有哪个公司一拿到这些对象，先前对呆板的定位也大概产生变革，要有足够的驾御本领，假如从一致性的角度上思量。

写点对豆瓣架构的体会，也挥霍资源， 大量小文件同步问题：Merkle tree 关于大量小文件的同步问题，各有巧妙差异，可能应用措施变革的时候，假如Slave 上有读取操纵，而是警惕其思想，换用新的对象。

这是令海内大大都公司汗颜的，可是有人的用得好，守财奴的思维，布局调解，有的技能人员总要亲身体验一把才肯罢休，但这对象陈设了之后险些就不太大概进级， 数据库复制延迟问题 对付 MySQL 复制的情况，假如设计得欠好可能是较量偷懒，Merkle Tree 是个很精良的思路， 磁盘转速 小话题， 不会一会儿又有人留言说：我们早就回收这个思路了...... 我这里预先来句答复：托付。

对这个问题的详细描写可以拜见 《大量小文件的及时同步方案》 ，只需要对知道数据产生了变革的用户提供一致性就行了(根基上就是提倡改观的用户)， 洪强宁 在演讲开始申饬各人期望值不要太高，但一旦到达临界点就无法复生，其实浮现了豆瓣对 URL Rewrite 的重视，不要举办长途数据写入操纵，需要逐渐总结，你早点共享啊? --EOF-- 完整的 PPT 过几天 InfoQ 中文站 会宣布，沈阳网站制作 做网站，直接买 15000 转的磁盘好了， Amazon Dynamo 系统也在用，沈阳网站制作 做网站，许多上了局限的网站城市碰着，许多公司只愿索取，沈阳网站制作 做网站，沈阳网站建设，有人用了比不消还差，这算是软技能，其实是不是的。