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 的确切时间。步调就不一致喽。

systimestamp.png

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

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

EOF

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

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.