(转)强烈推荐:著名社交网站LinkedIn的Java架构技术

08-06-14 pub
强烈推荐:著名社交网站LinkedIn的Java架构技术

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

网站的架构技术的演讲,目前这两个演讲的PPT已经可以下载了。下载地址如下:

LinkedIn - A Professional Social Network Built with Java™ Technologies and Agile Practices

LinkedIn Communication Architecture

需要注册才可以下载,能下载PDF版本。

可以看一下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数据总线来更新数据,这是通过分布式更新的核心组件,任何组件都需要Databus

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

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。所有的操作都是异步的。

推荐阅读:LinkedIn架构图:99%都是用Java写的

2
pub
2008-06-14 10:48

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

迅雷下载文中的PDF

LinkedIn - A Professional Social Network Built with Java™ Technologies and Agile Practices

LinkedIn Communication Architecture

如果上面连接无法下载,参考:

LinkedIN架构

[该贴被admin于2014-12-02 11:14修改过]

[该贴被admin于2014-12-02 11:14修改过]

freeboy
2008-06-17 07:30
这么好的转贴不应该让他沉掉,因为这个架构,使我们相信不使用昂贵的ejb就可以实现世界一流级的项目。还有真正的世界级项目,并不是纯java编写而成,C++的出现让速度有了质的飞跃。希望大家踊跃发表自己的感想。

[该贴被freeboy于2008-06-17 07:57修改过]

pub
2008-06-20 15:09
LinkedIn 架构笔记

作者: Fenng

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

pub
2008-06-20 15:37
Fenng 作为支付宝的DBA 谈了一些DB的细节 倒也是职业病使然!!大家参考一下

[该贴被pub于2008-06-20 15:40修改过]

pub
2008-06-20 15:39
这里面提到了databus 和jms倒是希望banq出来谈谈

freeren
2008-06-24 23:32
好久没来了,这里又热闹了!真不错,学习去!希望这个贴子能热起来!

banq
2008-06-25 16:44
很不错,LinkedIn的思路正是我一直倡导分布式计算思路。

特别是Cloud,是一个内存计算的典型特征,有三个特征:

1. 从硬盘重建Cloud一个实例需要8个小时,很显然Clound不能随便当机,而且是不依赖持久化媒介如DB的。

2。Cloud通过databus实时更新 这是技术难点。

3。关闭时持久化到硬盘,7/24全年99%几乎无需关闭,一旦关闭,用户就不能使用了。

从以上看出,Cloud是一个脱离DB技术的架构.

技术难点是如何同步问题:

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

在不同分布式服务器的内存RAM中进行同步有两个方向:

1. 在server之间拷贝RAM中数据。

2. 使用DB,也就是Fenng 提到的Oracle的dataBus概念。

目前Java架构中,都是倾向于使用第一种,内存之间直接刷新异动,应该比先回数据库,再从数据库触发多个服务器要快速得多。

当然,具体怎么做不得而知,是核心秘密。大家猜猜而已。

楼上有人提到:我们相信不使用昂贵的EJB就可以实现世界一流级的项目

这对EJB有误解,首先EJB不昂贵,使用普通PC就能完成分布式计算;昂贵的是集中式DB模式,需要更大更强的主机;EJB使用很方便,只要加上@stateless就变成EJB了。

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

OO + 分布式计算 = 软件架构的方向

http://www.jdon.com/artichect/architecture.html

EJB+IBatis这种做法合理吗?

http://www.jdon.com/jivejdon/thread/34262.html

[该贴被banq于2008-06-25 16:58修改过]

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

我还说哪天能看到banq的技术展示:用EJB改写jivejdon,充分证明jdon框架开发的系统可以向EJB平滑过度,看来是不可能了。

yuanqixun
2008-07-12 09:45
怎么没有登陆连接?

weizhankui2008
2008-07-18 14:58
地址在哪儿?

weizhankui2008
2008-07-18 21:12
到哪登录啊

javaejb
2008-08-04 16:17
一提到EJB,某些人总会说大程序使用。好不容易看见这么大一个社交网站竟也不用EJB呀!看来EJB真的没用了。

banq
2008-08-05 10:06
>一提到EJB,某些人总会说大程序使用。好不容易看见这么大一个社交网站竟也不用EJB呀!看来EJB真的没用了。

这是不了解EJB,更不懂JavaEE,不知道什么是事务的外行评论,无论使用什么技术,都根据实际情况决定,这是架构的目的,哪有为反对而反对的呢?

javaejb
2008-09-03 21:28
Bang误解我了,我其实很喜欢EJB,但没见过EJB的项目。有感而发。你看PHP和ROR,怎么不好,人家有成功的实例啊,我很喜欢这个网站,看你发表EJB的高见,希望EJB能火起来,我支持你。

[该贴被javaejb于2008-09-03 21:31修改过]

猜你喜欢
3Go 1 2 3 下一页