大型web2.0互动网站设计方案 分析mixi.jp and Yeejee.com：用开源搭建的可扩展大型SNS网站总概关键点：1，Mysql 切分，采用Innodb运行2，动态Cache 服务器 –美国Facebok.com,中国Yeejee.com,日本mixi.jp均采用开源分布式缓存服务器Memcache3，图片缓存和加速Mixi目前是日本排名第三的网站，全球排名42，主要提供SNS服务：日记，群组，站内消息，评论，相册等等，是日本最大的SNS网站。Mixi从2003年12月份开始开发，由现在它的CTO – Batara Kesuma一个人焊，焊了四个月，在2004年2月份开始上线运行。两个月后就注册了1w用户，日访问量60wPV。在随后的一年里，用户增长到了21w，第二年，增长到了200w。到今年四月份已经增长到370w注册用户，并且还在以每天1.5w人的注册量增长。这些用户中70%是活跃用户（活跃用户：三天内至少登录一次的用户），平均每个用户每周在线时间为将近3个半小时。下面我们来看它的技术架构。Mixi采用开源软件作为架构的基础：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前为止已经有100多台MySQL数据库服务器，并且在以每月10多台的速度增长。Mixi的数据库连接方式采用的是每次查询都进行连接，而不是持久连接。数据库大多数是以InnoDB方式运行。Mixi解决扩展问题主要依赖于对数据库的切分。首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，根据用户的ID将不同用户的内容再划分的不同的数据库中，这是比较通常的做法，也很管用。划分的关键还是在于应用中的实现，需要将操作封装在在数据层，而尽量不影响业务层。当然完全不改变逻辑层也不可能，这时候最能检验以前的设计是否到位，如果以前设计的不错，那创建连接的时候传个表名，用户ID进去差不多就解决问题了，而以前如果sql代码到处飞，或者数据层封装的不太好的话那就累了。这样做了以后并不能从根本上解决问题，尤其是对于像mixi这种SNS网站，页面上往往需要引用大量的用户信息，好友信息，图片，文章信息，跨表，跨库操作相当多。这个时候就需要发挥memcached的作用了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，这样应用层基本上就可以解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库。Mixi的经验是平均每个页面的加载时间在0.02秒左右（当然根据页面大小情况不尽相似），可以说明这种做法是行之有效的。Mixi一共在32台机器上有缓存服务器，每个Cache Server 2G内存，这些Cache Server与App Server装在一起。因为Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可以和平共处，更有效的利用资源。图片的处理就显得相对简单的多了。对于mixi而言，图像主要有两部分：一部分是经常要使用到的，像用户头像，群组的头像等等，大概有100多GB，它们被Squid和CDN所缓存，命中率相对比较高；另一部分是用户上传的大量照片，它们的个体访问量相对而言比较小，命中率也比较低，使用Cache不划算，所以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上，在用户访问的时候直接进行访问，当然图片的位置需要在数据库中进行记录，不然找不到放在哪台服务器上就郁闷了。国内领先的SNS网站-采用类似的系统架构，在下面的文章会进行分析对比。这是稳定与典型的大型互动网站系统架构，web2.0的创业者，在设计网站时，可以参考参考，少走弯路。FROM:it168

Facebook图片管理架构 Facebook 的照片分享很受欢迎，迄今，Facebook 用户已经上传了150亿张照片，加上缩略图，总容量超过1.5PB，而每周新增的照片为2亿2000万张，约25TB，高峰期，Facebook 每秒处理55万张照片，这些数字让如何管理这些数据成为一个巨大的挑战。本文由 Facebook 工程师撰写，讲述了他们是如何管理这些照片的。旧的 NFS 照片架构老的照片系统架构分以下几个层：# 上传层接收用户上传的照片并保存在 NFS 存储层。# 照片服务层接收 HTTP 请求并从 NFS 存储层输出照片。# NFS存储层建立在商业存储系统之上。因为每张照片都以文件形式单独存储，这样庞大的照片量导致非常庞大的元数据规模，超过了 NFS 存储层的缓存上限，导致每次招聘请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题，他们做了两项优化：# Cachr: 一个缓存服务器，缓存 Facebook 的小尺寸用户资料照片。# NFS文件句柄缓存：部署在照片输出层，以降低 NFS 存储层的元数据开销。新的 Haystack 照片架构新的照片架构将输出层和存储层合并为一个物理层，建立在一个基于 HTTP 的照片服务器上，照片存储在一个叫做 haystack 的对象库，以消除照片读取操作中不必要的元数据开销。新架构中，I/O 操作只针对真正的照片数据（而不是文件系统元数据）。haystack 可以细分为以下几个功能层：# HTTP 服务器# 照片存储# Haystack 对象存储# 文件系统# 存储空间存储Haystack 部署在商业存储刀片服务器上，典型配置为一个2U的服务器，包含：# 两个4核CPU# 16GB – 32GB 内存# 硬件 RAID，含256-512M NVRAM 高速缓存# 超过12个1TB SATA 硬盘每个刀片服务器提供大约10TB的存储能力，使用了硬件 RAID-6, RAID 6在保持低成本的基础上实现了很好的性能和冗余。不佳的写性能可以通过高速缓存解决，硬盘缓存被禁用以防止断电损失。文件系统Haystack 对象库是建立在10TB容量的单一文件系统之上。文件系统中的每个文件都在一张区块表中对应具体的物理位置，目前使用的文件系统为 XFS。Haystack 对象库Haystack 是一个简单的日志结构，存储着其内部数据对象的指针。一个 Haystack 包括两个文件，包括指针和索引文件：Haystack 对象存储结构指针和索引文件结构Haystack 写操作Haystack 写操作同步将指针追加到 haystack 存储文件，当指针积累到一定程度，就会生成索引写到索引文件。为了降低硬件故障带来的损失，索引文件还会定期写道存储空间中。Haystack 读操作传到 haystack 读操作的参数包括指针的偏移量，key，代用Key,Cookie 以及数据尺寸。Haystack 于是根据数据尺寸从文件中读取整个指针。Haystack 删除操作删除比较简单，只是在 Haystack 存储的指针上设置一个已删除标志。已经删除的指针和索引的空间并不回收。照片存储服务器照片存储服务器负责接受 HTTP 请求，并转换成相应的 Haystack 操作。为了降低I/O操作，该服务器维护着全部 Haystack 中文件索引的缓存。服务器启动时，系统就会将这些索引读到缓存中。由于每个节点都有数百万张照片，必须保证索引的容量不会超过服务器的物理内存。对于用户上传的图片，系统分配一个64位的独立ID，照片接着被缩放成4种不同尺寸，每种尺寸的图拥有相同的随机 Cookie 和 ID，图片尺寸描述（大，中，小，缩略图）被存在代用key 中。接着上传服务器通知照片存储服务器将这些资料联通图片存储到 haystack 中。每张图片的索引缓存包含以下数据Haystack 使用 Google 的开源 sparse hash data 结构以保证内存中的索引缓存尽可能小。照片存储的写/修改操作写操作将照片数据写到 Haystack 存储并更新内存中的索引。如果索引中已经包含相同的 Key，说明是修改操作。照片存储的读操作传递到 Haystack 的参数包括 Haystack ID，照片的 Key, 尺寸以及 Cookie，服务器从缓存中查找并到 Haystack 中读取真正的数据。照片存储的删除操作通知 Haystack 执行删除操作之后，内存中的索引缓存会被更新，将便宜量设置为0，表示照片已被删除。重新捆扎重新捆扎会复制并建立新的 Haystack，期间，略过那些已经删除的照片的数据，并重新建立内存中的索引缓存。HTTP 服务器Http 框架使用的是简单的 evhttp 服务器。使用多线程，每个线程都可以单独处理一个 HTTP 请求。结束语Haystack 是一个基于 HTTP 的对象存储，包含指向实体数据的指针，该架构消除了文件系统元数据的开销，并实现将全部索引直接存储到缓存，以最小的 I/O 操作实现对照片的存储和读取。本文国际来源：http://www.facebook.com/FacebookEngineering#/note.php?note_id=76191543919&ref=mf中文翻译来源：COMSHARP CMS 官方网站

IBM推出软件开发人员SNS站点My developerWorks 据国外媒体报道报道，IBM推出面向软件开发人员社交网站。对软件开发人员而言，IBM的developerWorks是全球最大的在线技术来源，developerWorks用户约有800万人，占全球软件开发人员的一半。今天，IBM为这些软件开发人员推出了专门的社交网站My developerWorks。My developerWorks与Facebook、LinkedIn或者其他所有我们知道的社交网站都不一样，该社交网站主要聚焦于技术的讨论。在My developerWorks上，全球范围的技术人员可以寻找特定的知识或技能，利用该社交网站的群组、讨论主题和个人资料来判断谁是某一特定领域的专 家。My developerWorks最令人兴奋的前景是不断合作的可能性。IBM所要做的就是如何展示这些技术人员的个人资料，让业务开发、营销、设计、管理和风投人员找到需要的技术人员。那么，初创公司就会不停地出现。一位IBM代表周三晚间通过电子邮件表示：“IBM的目标是，利用My developerWorks，将全球范围的软件开发人员联系起来，让他们在Java、Linux和XML等开放标准的基础上能更容易地进行技术创新。 IBM希望软件开发人员能在分析、清洁技术和云计算等热门技术领域占有一席之地。”那么，为软件开发人员推出专门的社交网站能给IBM带来什么好处？目前还没有关于这方面的评论，不过参与My developerWorks的个人和组织都会获利。