易栈网-膘叔

架构这个东西，不能一味的盲目抄袭，因为每种新架构的出现往往都有其特定的历史背景，要么是数据访问量太大、要么（想写的一些内容因为存储关系丢失了，一下子又没有想起来，下面是重写的，但内容已经和原来想的不太一样了）

高春辉就在他的勃客里认为，主从数据库不行了，未来的数据存储走向应该不会再是主从，他这么说：

文末，他推荐了一篇InfoQ上的文章，在这里我也进行转载一下，是关于FriendFeed实现基于MySQL的无模式存储，不过他这种架构也不是能拿来就要用的，也需要根据目前的实际情况，只能进行参考。这是一篇翻译文章：

作者 Dave West译者 王丽娟 发布于 2009年4月4日 下午8时7分

对于迅速增长的网站所遇到的问题——“用灵活的模式存储数据、即时创建新的索引”，FriendFeed的Bret Taylor介绍了一种“无模式的解决方案” 。问题本身源自一些需求：需要不断增加新功能，不断更新底层的数据库结构和数据库中存储的数百万条已有记录，还要同时支持新旧功能。FriendFeed的办法是基于MySQL建立一个无模式的解决方案，而不是迁移到别的技术基础上去。Bret描述了基本问题：

尤其是有一两千万行数据的时候，每次修改模式、往数据库中添加索引都会数小时完全锁定数据库。删除旧索引也需要同样长的时间，但不删除又会影响性能，因为 数据库在每次执行INSERT操作时都会继续读写这些不用的块，而重要的块却没有足够的内存。经过一些复杂的操作过程可以克服以上困难（比如在从机上创建 新索引，然后调换从机和主机），但这些操作过程都很容易出错，也都是重量级的，因此会使我们因为害怕改变模式/索引而不敢增加新功能。由于我们的数据库都 是严重分片的，像JOIN这些MySQL的关系型功能对我们毫无用处，所以我们决定看看RDBMS之外的领域。

研究了几个可行的解决方案后，他们决定基于MySQL的自定义一种“无模式”持久化方案，而不是彻底改换门庭。

他们的解决方案是把主要数据和这些数据的索引分离开来。“我们的数据存储储存了无模式的属性包……我们在单独的MySQL表中存储索引，从而在这些实体中索引数据。”这是以容量来换效率。

结果我们比以前多了很多的表，但添加和删除索引却很容易。我们大力优化了填充新索引的进程（我们称之为“Cleaner”），以便该进程能快速填充新索引，而不会让站点中断。

分离数据和索引引起了一致性和原子性问题。他们没有建立严格的事务规则，而是把数据库表推到最简，索引只用来引用，发生实际的数据库读操作的时候才 施加数据过滤。他们改进了持续更新表的自动化进程，让这个“Cleaner”进程不停地对优先级高的被更新实体进行更新和索引修正。尽管可能出现不一致， 但消除不一致的时间平均不到两秒钟。

Bret用平均页面延迟这一指标描述了以下走向。

• 整体来说——尽管有增加的趋势，但还是有显著的减少。
• 过去二十四小时——即使在高峰时段也保持稳定。
• 前一周——明显减少。

Bret的帖子有很多回复。有一种观点认为“对于模式演变，现代的RDBMS不像MySQL局限那么大”，这种观点忽略了选择背后的成本问题。其它读者则回复了更多种不同的解决办法。

有意思的是，并没有人指出FriendFeed的解决方案与古老的ISAM技术（Indexed Sequential Access Method，索引顺序存取法）之间的相似性。ISAM用的是同样的基本架构——分离数据和索引，同时在数据发生变化时自动更新索引。

查看英文原文：FriendFeed Implements Schema-less Storage Atop MySQL

新版本的ubuntu要出来了。每年的4月10月就是出新版本的时候。
这不，网上都开始有倒计时了

装一下时髦，放个代码

最近一段时间各个网站都在公布自己的架构体系等信息，在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 中文站会发布，我这里就不掠美了。

这个大话可不是大话设计模式的那个大话。

它是大话西游的大话。。。

多少年了。。再次回味一下：

其实，我觉得大话西游是一个悲剧片，不光是紫霞的，也是至尊宝的。
片中，至尊宝一出场JJ就被踩烂，而且是烧焦的
他为了掩饰自己这个缺点，不停的在借寻找MM的来隐藏自己的缺陷，然而当他遇到紫霞的时候，他不可避免的爱上了他，然而，身体的缺陷却让他很自卑，于是，当紫霞进入他身体看他的心的时候，只发现了一滴眼泪。那是周星星被踩断的时候，心中无奈流下的泪水。。。

剩下的以后补充

身体好了点了，HP、MP恢复了80%

基本上又可以正常的编码了。。
哦，不对，我是编辑。。。。。

最近看上了reborn组合。清纯可爱，yeah...