- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【半原创】Flickr 网站架构研究（1） -- 西电鲁丁
鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望】
[返回] [关闭]
每个shard上的数据库结构看起来都差不多，shard A上面如果有某些表，表里存着一些客户的某些类型的数据（评论啦，照片的metadata啦等等），那么shard B上也是这么一套，只不过是针对另一些客户。文章中也说“Shard只适用于不需要join操作的表”，也就是说各客户之间的交互应该是很少的。如果是办一个用户之间交互很多的，比如Facebook这样的网站，这个架构就完全不适合了。这时候可能要把数据库纵向剖开，关于论坛的数据库在一个服务器上，在线聊天的又在另一个上……
客户之间的交互主要靠数据冗余,即两边各放一份，牺牲空间换效率；把不同的表放在不同的数据库上只适合于不太大的表；没看到太多的关于Facebook的介绍，（暂时也没有时间，先完成这个系列再说，坑里不再挖坑
）不过Facebook的规模比Flickr要大得多，根据2008年的数据，Flickr的服务器数量大约是几百台，而Facebook是上万台，光Memcached服务器就有６，７百台，也可能是象你说的，不过应该更进一步，关于论坛的数据库在一个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，无法及时保持一致？
１。 这个RAID-10根据我的理解应该是服务器的内置SCSI硬盘;2U是指刀片服务器的厚度，1U等于4.45厘米,2U就是8.9厘米，大型机房大都用这种标准机架。
２。这个会在这个系列的后续里介绍，正在积累资料，不过关于Flickr FS的资料很难找。
３。照片的元数据是在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?
１。这个架构图是从Cal Henderson的PPT里直接拷过来的，版权不是我的。
２。如果我的理解没错的话，在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
２。 这个Cal Henderson自己也承认是很麻烦，是不是一定要这样做，有没有更好的办法，也许只有身在其中才知道。
这个cache根据我的理解是memcached，不过不敢肯定。
既然MemCached有什么多好处，尤其是对于“读”来说，这些好处更明显。那么为什么Central DB还需要Slave?
增加了Slave，对于“读”来说，看不出有太多好处，但是对于“写”来说，增加了同步的负担。
或许，是因为历史原因？也就是说，Flickr还没有来得及完全改造好？