Tag Archives: Arch

LinkedIn 架构笔记

现在是 SNS 的春天，最近又有消息传言新闻集团准备收购 LinkedIn。有趣的是，LinkedIn 也是 Paypal 黑帮成员创建的。在最近一个季度，有两个 Web 2.0 应用我用的比较频繁。一个是Twitter，另一个就是 LinkedIn。

LinkedIn 的 CTO Jean-Luc Vaillant 在 QCon 大会上做了 ”Linked-In: Lessons learned and growth and scalability“ 的报告。不能错过，写一则 Blog 记录之。

LinkedIn 雇员有 180 个，在 Web 2.0 公司中算是比较多的，不过人家自从 2006 年就盈利了，这在 Web 2.0 站点中可算少的。用户超过 1600 万，现在每月新增 100 万，50％会员来自海外(中国用户不少，也包括我).

开篇明义，直接说这个议题不讲”监控、负载均衡”等话题，而是实实在在对这样特定类型站点遇到的技术问题做了分享。LinkedIn 的服务器多是 x86 上的 Solaris ，关键 DB 用的是 Oracle 10g。人与人之间的关系图生成的时候，关系数据库有些不合时宜，而把数据放到内存里进行计算就是必经之路。具体一点说，LinkedIn 的基本模式是这样的：前台应用服务器面向用户，中间是DB，而DB的后边还有计算服务器来计算用户间的关系图的。

问题出来了，如何保证数据在各个 RAM 块(也就是不同的计算服务器)中是同步的呢? 需要一个比较理想的数据总线(DataBus)机制。

第一个方式是用 Timestamp . 对记录设置一个字段，标记最新更新时间。这个解决方法还是不错的—除了有个难以容忍的缺陷。什么问题？就是 Timestamp 是 SQL调用发起的时间，而不是 Commit 的确切时间。步调就不一致喽。

第二个办法，用 Oracle 的 ORA_ROWSCN (还好是 Oracle 10g). 这个伪列包含 Commit 时候的 SCN(System Change Number)，是自增的，DB 自己实现的，对性能没有影响。Ora_ROWSCN 默认是数据库块级别的粒度，当然也可做到行级别的粒度。唯一的缺点是不能索引(伪列). 解决办法倒也不复杂：增加一个 SCN 列，默认值”无限大”。然后用选择比某个 SCN 大的值就可以界定需要的数据扔到计算服务器的内存里。

ORA_ROWSCN 是 Oracle 10g 新增的一个特性，不得不承认，我过去忽略了这一点。我比较好奇的是，国内的 Wealink、联络家等站点是如何解决这个关系图的计算的呢?

–EOF–

一点题外话：我的 LinkedIn Profile (Mail : [email protected]). Keep in Touch!。
另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家和若邻)。一般人我不告诉他~~

Yahoo！社区架构

旧金山举行的 QCon 会议带给我们很多新鲜的信息。虽然没机会参加，但是看看各个网站”晒架构”也是个比较过瘾的事情。请参观并收藏这个页面：Architectures you’ve always wondered about。

eBay 的架构和去年相比基本是换汤不换药，倒是 Yahoo! 的 Ian Flint(这位老兄是 Bix 的运营总监. Bix 已被雅虎收购) 这个 PPT Yahoo! Communities Architecture: Unlikely Bedfellows 挺有意思，披露了一些鲜为人知的信息。

Yahoo! 社区包括我们比较熟悉的 del.icio.us、Flickr、Yahoo!群组、Yahoo! Mail、Bix等。相当于 Yahoo！把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游戏的运营有些相近。

架构特点

有两点值得注意：1）层次化 2）模块化。这也是大规模作业下的比较经济的途径。

软件架构

首先是操作系统已经从 FreeBSD 逐渐迁移到 RHEL。这怕是雅虎不得已作出来的决定吧。FreeBSD 的开发力量的确不如 Linux，这也是不争的事实。数据库上 MySQL 与 Oracle 都有。Yahoo! 在 DW/BI 用的是 Oracle，构建了一个超大数据库。诸如 yapache、yts(反向代理服务器)、yfor(提供快速失败接管)、 ymon（监控），还有还有ysquid、ypan(cpan的 Yahoo! 克隆) 这些组件都是通过 yinst 来统计部署。关于 Yapache，请参考我以前写的 Yapache-Yahoo! Apache 的秘密

这是 Bix 与 DB 有关的部署架构:

数据放在 Netapp NAS 上(所以有的时候应用之慢也可以理解了)，通过快照复制到其他数据中心。

Yahoo! Mail 架构：

这里面居然部署了 Oracle RAC，用来存储 Mail 服务相关的 Meta 数据。非常有趣。

运营维护

监控工具主要用的是 Nagios，用以监控集群。使用标准插件，另外也有自行定制的插件。Nagios 这东西太棒了。主动、被动检查的消息转发是通过 Ymon 来做到。网管上针对 SNMP 的解决方案是用 Yahoo！自己 Y 字头的 Ywatch。这些 Y 字头的东西基本上外面都是找不到的。Yahoo！的技术其实并不那么开放。Google 在运营这方面也好不到什么地方去。趋势图用 Drraw 展现。Drraw 是基于 RRDtool 的 Web 展现工具。

应用服务器的监控是被动的。整个监控系统模块化部署。Nagios 的警告信息转发到 Ywatch 中心控制台。

Note: 上面所有截图版权都属于 Ian (Image COPYRIGHT@IAN) 。如果去看那个 PDF 文件，你或许比我收获更多。我只是让你知道我的想法而已。

–EOF–

Tailrank 网站架构

每天数以千万计的 Blog 内容中，实时的热点是什么? Tailrank 这个 Web 2.0 Startup 致力于回答这个问题。

专门爆料网站架构的 Todd Hoff 对 Kevin Burton 进行了采访。于是我们能了解一下 Tailrank 架构的一些信息。每小时索引 2400 万的 Blog 与 Feed，内容处理能力为 160-200Mbps，IO 写入大约在10-15MBps。每个月要处理 52T 之多的原始数据。Tailrank 所用的爬虫现在已经成为一个独立产品：spinn3r。

服务器硬件

目前大约 15 台服务器，CPU 是 64 位的 Opteron。每台主机上挂两个 SATA 盘，做 RAID 0。据我所知，国内很多 Web 2.0 公司也用的是类似的方式，SATA 盘容量达，低廉价格，堪称不二之选。操作系统用的是 Debian Linux 。Web 服务器用 Apache 2.0，Squid 做反向代理服务器。

数据库

Tailrank 用 MySQL 数据库，联邦数据库形式。存储引擎用 InnoDB，数据量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些多核模式下互斥锁的问题(This Bug?)。到数据库的JDBC 驱动连接池用 lbpool 做负载均衡。MySQL Slave 或者 Master的复制用 MySQLSlaveSync 来轻松完成。不过即使这样，还要花费 20％的时间来折腾 DB。

其他开放的软件

任何一套系统都离不开合适的 Profiling 工具，Tailrank 也不利外，针对 Java 程序的 Benchmark 用 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是开放的。

Tailrank 的一个比较大的竞争对手是 Techmeme，虽然二者暂时看面向内容的侧重点有所不同。其实，最大的对手还是自己，当需要挖掘的信息量越来越大，如果精准并及时的呈现给用户内容的成本会越来越高。从现在来看，Tailrank 离预期目标还差的很远。期待罗马早日建成。

–EOF–

财帮子（caibangzi.com）网站架构

财帮子(caibangzi.com) 定位在”基金理财社区”。是国内访问量最大的基于 Ruby on rails 的 startup 项目。“理财”这个词据说是光大银行发明的，且不去管，不可否认的是，目前国内”理财”是个很有潜力的切入点。财帮子网站潜在用户群还是很大的。

1.创建人员

创建者有三人。Robin Lu(石锅拌饭)、Meng Yan ( 孟岩 ) ，还有一位”不写Blog的家伙”。前两位都是技术人员。很早就看过孟岩的 Blog，那时候他还在 Sun。Robin Lu 的 Blog 也一直在我的订阅列表中的，所以财帮子刚成立我就知道的。倒没有细问第三位是技术人员还是负责商务。(Updated: Robin Lu留言说”财帮子那位不写blog的创建者也是工程师，叫赵路，曾经是 Mozilla 项目accessibility模块的module peer.”

2.服务器信息

Web 服务器用的是 Lighttpd ，出于节省成本的目的，服务器是自行组装的。数据库采用的是 MySQL 5，目前还没有使用 Replication. 正准备扩充服务器，服务器数量…暂且保密一下。

3.统计分析及监控

统计分析采用 Google Analytics 和 Awstats 。目前 Alexa 排名是 2 万一点。监控工具用 monit，”以及自己写的一些分析 Proc 的脚本”，再有就是 Unix 性能工具等。(Fenng: 服务器处于规模化之前基本上要这个样子)。

4.优化之路

Robbin 在此前的一篇财帮子性能优化简报披露：“财帮子两个星期以前，遇到严重的性能问题，最终我们采用了相当非主流的部署方案和打了自己补丁的web server，成功度过了难关”，我很好奇这具体是个什么问题。得到的答案是：“Apache的负载均衡是有问题的，算法太简单了，对Ror的应用来说，会造成某一个app instance的阻塞，从而阻塞了所有的request”。

谈及 Cache 的感慨:

Fenng: ... 我个人感觉你们需要Cache服务器， 这一类的站点内容需要 Cache 的太多
Meng Yan: ...Web 2.0网站的 cache 非常重要。我们从Mem的cache，到disk的cache，
再到数据库的cache，架构还不错，否则当前机器撑不住 :)
Fenng: 很多站点扩展作不好，也是Cache没用好
Meng Yan: 是啊，Cache非常重要，非常非常
Fenng: 豆瓣的阿北说他们 Memcached 用的非常爽，命中率非常之高
Meng Yan: 确实，我们的内存cache就是用的memcached，真的很棒

5.挑战

这是就这次采访的最后一个问题。

Fenng:还要采访你一个问题：caibangzi.com 现在运营、开发面临的最大的一个问题是什么? 
Meng Yan:目前可能我们遇到最多的是合作、商务上的事情。真正开发、运营上来说对我们的挑战还不大。

6.后记

这次采访(如果可以说这是采访的话)非常顺利。财帮子从三月底上线，到现在已经积累了一定数量的用户，当然不是十全十美的(我个人就感觉应该提供更多的RSS输出才是，不要太在乎站点流量，流量本身也是开销)，网站也还有很长的路要走。真诚希望财帮子能成为更多人的理财工具(至少我已经开始用了)。

这是我第一次写国内 Web 2.0 网站架构技术。感谢 Meng Yan 提供的第一手信息。关于网站架构，我在这个 Blog 上写过不少国外的站点分析。一直想采访一些国内的 Web 2.0 站点并且能披露点技术信息，相对来说，国内站点还是比较保守，各自闷头折腾。为什么不换个角度，分享、借鉴、壮大，这个方式不也不错麽?

BTW: 如果你有 Web 2.0 站点技术信息要报料，联系我！(要写软文就免了)。

–EOF–