主题:【半原创】Flickr 网站架构研究(1) -- 西电鲁丁
鲜花已经成功送出。
此次送花为【有效送花赞扬,涨乐善、声望】
[返回] [关闭]
每个shard上的数据库结构看起来都差不多,shard A上面如果有某些表,表里存着一些客户的某些类型的数据(评论啦,照片的metadata啦等等),那么shard B上也是这么一套,只不过是针对另一些客户。文章中也说“Shard只适用于不需要join操作的表”,也就是说各客户之间的交互应该是很少的。如果是办一个用户之间交互很多的,比如Facebook这样的网站,这个架构就完全不适合了。这时候可能要把数据库纵向剖开,关于论坛的数据库在一个服务器上,在线聊天的又在另一个上……
客户之间的交互主要靠数据冗余,即两边各放一份,牺牲空间换效率;把不同的表放在不同的数据库上只适合于不太大的表;没看到太多的关于Facebook的介绍,(暂时也没有时间,先完成这个系列再说,坑里不再挖坑)不过Facebook的规模比Flickr要大得多,根据2008年的数据,Flickr的服务器数量大约是几百台,而Facebook是上万台,光Memcached服务器就有6,7百台,也可能是象你说的,不过应该更进一步,关于论坛的数据库在一个Shard集群(包括中央数据库和多个Shard)上,在线聊天的又在另一个上……
Shard+Memcached基本上是各大网站的事实标准了。
在IT领域想做出一点成就,首先要认准方向。
什么方向容易出成果?要么做大,要么做小。
像云计算类似的技术,就是“大”的技术。上万台servers的集群,能不能协调作战,充分发挥能力,这就是做大的功夫。
Yahoo网站的开通,使大家认识到了大型网站的技术难度。但是直到Amazon和Ebay发轫以后,大家才看到大型网站的技术方向。Google,Flickr,Facebook等等后起的大型网站,把做大的技术又大大推进了一步。
研究Flickr的架构,与Google的技术横向比较,是一个苦活,但是惟其艰苦,越发彰显其价值。
这个系列写得好,值得反复阅读,细细体会。过几天,我写篇读后感,一来与鲁丁兄交换想法,二来表达对兄台与大家分享这么有意义的文章的感激。
Flickr(服务器规模几百台),Facebook(上万台),Google(几十万台)应该是比较典型的大型网站,比起后两者,Flickr只能算小弟弟,所以研究起来也是相对最”容易“的。文章的主要信息来源包括我曾经在河里推荐的 "http://highscalability.com/"和Cal Henderson 的书”Building Scalable Web Sites“,一些细节是我自己的推测和其他网站资源的参考和印证,不一定完全正确,但正如我前面所说,主要是抛砖引玉,希望引得各位大牛参与讨论,可以共同学习,提高。
1.
- 6-disk 15K RPM RAID-10.
- 2U boxes.
RAID 放在何处?2U boxes在何处?能不能在上图中标一下?
2.
- 运行私有的,适用于海量文件存储的Flickr File System
为什么需要重新发明一套Flickr FS,它与NFS之类有什么区别?
3.
只见到Master-Master,但是没有见到Master-Slave。猜想一下,如果Master是照片的元数据,那么Slave应该是照片本身,而照片是存在NetApp + Flickr FS里的。猜想正确吗?
总体感觉,这个架构的针对性非常强。如果flickr的业务发生重大变化,这套架构似乎就得动大手术了。
读了第二篇,发现先前的理解出错了。Master也好,Slave也好,读写的对象都是元数据。
再次看看结构图。是不是可以这样理解,
1. 在“Dual tree central DB”那个框中,描绘了双Master以及Slaves,只不过没有具体把各个Master与它所管辖的Slaves,用连线串在一起。
2. "Master-master shards" 这三个框没有画完整。最好画成“Shards”,每一个shard的框中,不仅有两个Masters,还有所属的Slaves。
另外,又想到一个问题。
- 中间层缓存服务器,用于缓存数据库的SQL查询结果等。
当数据库中的相关数据更新以后,Memcached 如何随即更新?会不会也像Master向Slaves同步那样,当Memcached cluster规模大了以后,就各个Memcached node,无法及时保持一致?
1。 这个RAID-10根据我的理解应该是服务器的内置SCSI硬盘;2U是指刀片服务器的厚度,1U等于4.45厘米,2U就是8.9厘米,大型机房大都用这种标准机架。
2。这个会在这个系列的后续里介绍,正在积累资料,不过关于Flickr FS的资料很难找。
3。照片的元数据是在Shard里,照片本身是存在NetApp,Flickr FS根据我现在的理解是一个分布式文件系统中间件。
总体感觉,这个架构的针对性非常强。如果flickr的业务发生重大变化,这套架构似乎就得动大手术了
架构的变化不好说,如果有重大改变,也许会另起炉灶,技术的发展使几年前不可能的事情变成了可能,如果重新设计,应该能有更多的选择。
1.
增加一个问题,从第一篇的图中看,Central DB同Shard一样,也有Master和Slave的配合。所以问题是,既然Central DB已经有了Slave,负责“读”,为什么还另外需要MemCached?
2.
这里所说的“Cache”,是不是指MemCached?如果是这样的话,任何对Central DB的更改,先要放到MemCached里去,然后再push到Central DB?
这样颠倒主次关系的做法,是不是很容易make troubles?
1. 关于服务器的硬件配置,是我先前理解错误。经兄台解释,恍然大悟。
2.
这个猜测很靠谱。同意。
多谢!
同意荷包兄的意见,shard可以按行切,也可以按列切。
按行切的麻烦在于join operation会很麻烦。
按列切,join的事情好办些,但是读某个用户的所有数据时,速度会放慢。
同意鲁丁兄的看法,MemCached只负责Central DB的事情,而与Shard无关。
但是疑问是,Central DB本身已经有了Slave,为什么还需要额外加MemCached?
1。这个架构图是从Cal Henderson的PPT里直接拷过来的,版权不是我的。
2。如果我的理解没错的话,在Shard里,只有一对Master-Master,没有Slave。我想这是因为Shard已经切分得足够小,虽然大多数操作可能还是读,但已经没必要加Slaves,如果业务增加的话,会再次切分。
关于Memcached集群,文中没有提到是Memcached没有冗余和HA,每个数据根据hash key的值,只存在一个memcached的服务器的内存里,没有复制,因而一旦这个服务器垮掉了,memcached client端会重新计算hash key的值,应用逻辑每次要判断如果数据不在memcached里,会从数据库里再取,同时一旦更新也要同步更新memcached和数据库,这也是为什么Flickr要写一个write-through cache层的原因。
具体memcached的细节请参见外链出处,不好意思,篇幅有限,很多东西没有说清楚,有时间我会再修改的。
一个更激进的想法是所谓的"内存数据库",即所有数据都放入内存,数据库只是作为persist store, 参见http://natishalom.typepad.com/nati_shaloms_blog/2008/03/scaling-out-mys.html
2。 这个Cal Henderson自己也承认是很麻烦,是不是一定要这样做,有没有更好的办法,也许只有身在其中才知道。
这个cache根据我的理解是memcached,不过不敢肯定。
既然MemCached有什么多好处,尤其是对于“读”来说,这些好处更明显。那么为什么Central DB还需要Slave?
增加了Slave,对于“读”来说,看不出有太多好处,但是对于“写”来说,增加了同步的负担。
或许,是因为历史原因?也就是说,Flickr还没有来得及完全改造好?