著名社交网站LinkedIn的Java架构技术

在JavaOne 2008的会议上，著名社交网站LinkedIn的开发者做了2个关于LinkedIn

网站的架构技术的演讲，目前这两个演讲的PPT已经可以下载了。下载地址如下：
http://s3.amazonaws.com/ppt-download/linkedinjavaone2008techsessioncomm-1211223608637383-9.pdf?Signature=bq3zR1KBX72YUJBtcR1J3zPFt9Y%3D&Expires=1212911935&AWSAccessKeyId=1Z5T9H8PQ39V6F79V8G2

http://s3.amazonaws.com/ppt-download/linkedinbofjavaone2008-1210975769299886-8.pdf?Signature=7mtRpPrZrBbz%2BgOjJcsJNOhyOOI%3D&Expires=1212911913&AWSAccessKeyId=1Z5T9H8PQ39V6F79V8G2


可以看一下LinkedIn网站的基本情况：
1。2千2百万用户
2。每个月4百万独立用户访问
3。每天4千万page view
4。每天2百万搜索流量
5。每天25万邀请发送
6。每天1百万的回答提交
7。每天2百万的email消息发送

这是一个世界顶尖级别流量的网站了，看看LinkedIn的系统架构：
* 操作系统：Solaris (running on Sun x86 platform and Sparc)
* 应用服务器：Tomcat and Jetty as application servers
* 数据库：Oracle and MySQL as DBs
* 没有ORM，直接用JDBC No ORM (such as Hibernate); they use straight JDBC
* 用ActiveMQ在发送JMS. (It’s partitioned by type of messages. Backed by MySQL.)
* 用lucene做搜索Lucene as a foundation for search
* Spring做逻辑架构Spring as glue

下面是随着流量增加，LinkedIn的架构演化：
2003－2005
1。一个整体的web程序，
2。一个核心数据库，
3。在Cloud中缓存所有network图，Cloud是用来做缓存的独立server。
4。用lucene做搜索，也跑在Cloud中。

2006年
1。复制另外一个数据库，减少直接load核心数据库，另外一个server来管理非只读数据库数据更新。
2。把搜索从Cloud中移出来，单独一个server跑搜索
3。增加Databus数据总线来更新数据，这是通过分布式更新的核心组件，任何组件都需要atabus

2008年
1。WebApp不再任何事情都它自己做，把业务逻辑分成很多部分，通过server群来做。webApp仍然提供用户界面给用户，但是，通过server群来管理用户资料，小组等等。
2。每个服务有自己的域数据库
3。新的架构允许其他应用链接LinkedIn，比如增加的招聘和广告业务。

The Cloud
1。Cloud是整个架构最重要的部分，整个LinkedIn的网络图都缓存在Cloud里面
2。Cloud大小：22M nodes, 120M edges
3。需要12GB RAM
4。在生产环境要跑40个实例
5。从硬盘重建Cloud一个实例需要8个小时
6。Cloud通过databus实时更新
7。关闭时持久化到硬盘
8。缓存通过C++实现，用JNI调用，LinkedIn选择C++而不是Java有两个原因：
    1）尽可能的减少RAM的使用
    2）垃圾收集暂停会杀死整个系统，LinkedIn用了最新的GC程序，也就是就是说java的的垃圾搜集性能不太好
9。将所有东西放在缓存里面是一种限制，但是LinkedIn指出，分割业务图将更麻烦
10。Sun提供了2TB的RAM


Communication Architecture交流架构包括：
Communication Service是用来提供永久信息的，比如收件箱里面的消息和email
1。整个系统通过JMS异步通讯
2。客户端用JMS发送消息
3。消息通过路径服务器来到达相应的邮箱或者直接放到email进程中
4。消息发送：同时使用Pull主动寻求信息(如用户需要信息)和Push发送信息(如发email)
5。使用Spring和LinkedIn专业Spring插件完成，使用HTTP-RPC

Scaling Techniques
1。通过功能来划分：发送，接受，文档等。
2。通过类别来划分：用户信箱，访问者信箱等
3。等级划分：用户ID等级，Email等级等
4。所有的操作都是异步的。

Fenng 作为支付宝的DBA 谈了一些DB的细节

现在是 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--

 

J道的banq：

在不同分布式服务器的内存RAM中进行同步有两个方向：
1. 在server之间拷贝RAM中数据。
2. 使用DB，也就是Fenng 提到的Oracle的dataBus概念。

目前Java架构中，都是倾向于使用第一种，内存之间直接刷新异动，应该比先回数据库，再从数据库触发多个服务器要快速得多。当然，具体怎么做不得而知，是核心秘密。大家猜猜而已。

 

楼上有人提到:我们相信不使用昂贵的EJB就可以实现世界一流级的项目
这对EJB有误解，首先EJB不昂贵，使用普通PC就能完成分布式计算；昂贵的是集中式DB模式，需要更大更强的主机；EJB使用很方便，只要加上@stateless就变成EJB了。

EJB是一个通用的商务解决方案，是各个因素的综合折中考虑，尤其是事务安全和性能中和，而社区网站则侧重于高性能，事务安全可以忽视，因此EJB不一定适合社区网站，而且一个自己的网站要杰出，当然必须走手工定制分布式计算这条路，而不是选择通用的解决方案。