谈谈Facebook的聊天系统架构

标签: Computer System 高性能Web架构 Facebook | 发表时间:2013-08-12 17:13 | 作者:ideawu
分享到:
出处:http://www.ideawu.net/blog

今天看到一份 Facebook 公司 2009 年的 PDF, 介绍它的聊天系统架构, 其中的一张图结构非常清晰, 所以我对这张图谈谈我的看法.

Web Tier: 用 PHP 开发, 聊天相关的业务逻辑代码. 如 AJAX 请求, HTML 页面拼接等. 这个模块整个其它的 3 个模块, 向浏览器提供了大部分的聊天接口.

Chatlogger, 用 C++ 开发, 消息的存储服务. 至少向 Web Tier 层提供了消息保存, 聊天历史消息, 最近联系人等基础服务接口.

Presence, 用 C++ 开发, 提供用户在线状态维护服务. 这些服务器会将在线的用户(UID)保存在内存中, 然后接受 Web Tier 的请求, 例如判断某个用户是否在线.

Channel(Comet) Cluster, 用 Erlang 开发, 提供基于浏览器的”Server Push(服务器推)”功能. 是对开源的 Mochiweb 的二次开发. 浏览器会跟 Channel Clusters 进行连接, 当 Web Tier 收到某个用户的消息时, 会通过 Channel Cluster 推送到接收者, 实现网页实时聊天功能.

关于 Web Tier, 其实没有太多的技术可讨论, 因为这主要是业务逻辑, 即使不用 PHP 语言, 用 Python 或者 Java 等都没有问题.

Chatlogger 虽然名字是”日志记录”, 但它不可能是简单的日志记录, 它必须要提供基本的消息服务接口. 而且, 为了存储数亿 Facebook 用户的聊天历史, 必然要涉及到海量数据存储. 这部分 Facebook 曾经用 Cassandra, 后来改为 HBase. Chatlogger 使用 C++ 进行开发是基于性能的考虑, 而且消息存储服务的接口比较固定, 不太可能经常变化.

Presence 维护用户的在线状态, 类似这种服务在网游中比较常见. Presence 服务器使用 C++ 来开发, 也是基于性能的考虑. 如果使用 HTTP + PHP + Memcache/Redis 这样的架构, 一是 PHP 代码执行性能损失很大, 二是 Memcache/Redis 是通用的存储方案, 不适合 Presence 的高性能需求. Presence 在数据全部保存在内存中, 速度快, 设计灵活. 注意, Presence 是一个被动服务器, 它并不主动向外推送消息, 这使得这样的服务器接口非常固定, 独立性很强. Presence 的数据主要来自于 Comet 群集的推送.

Channel(Comet) Cluster 和浏览器保持网络连接. Comet 有通道的概念, 每个用户对应一个通道, 用户会分布在不同的服务器上, 用户每打开一个新的浏览器标签, 就会同服务器建立一个新的网络连接, 但都是连到同一个通道. Comet 服务器是基于开源的 Erlang 服务器 Mochiweb 进行二次开发. 在身份验证和安全方面, 通道的建立是由 Web Tier 进行控制的, 这样如果用户没有在业务逻辑层经过相应的验证, 就直接连接 Comet 服务器, 它是会被拒绝的. 另外, Comet 服务器会在自己的内存中先维护一份在线用户列表, 然后定期更新到 Presence 服务器, 这也是二次开发的原因. 如果 Comet 服务器不自己先缓存一份在线用户列表, 那么用户频繁上线下线都立即通知 Presence 的话, 压力会非常大.

架构已经很清晰, 但要应用起来, 代码的开发是必不可少的. 当然, 不同的技术团队会根据技术情况进行取舍. 例如消息存储使用 MySQL, Presence 使用基于 Web 容器架构的技术来开发, 而 Comet 模块可以使用 nginx-push-stream. 不过, 仅仅依靠整合开源系统而不做二次开发, 不可能解决大问题.

PDF 文件可以在这里下载: http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf

Related posts:

  1. Facebook 网站架构
  2. nginx-push-stream-module 笔记
  3. 使用 Channel 进行可靠传输
  4. Redis被bgsave和bgrewriteaof阻塞的解决方法
  5. SSDB 使用 jemalloc

相关 [facebook 系统架构] 推荐:

Facebook 的系统架构

- Ivan - 博客园新闻频道
  来源:http://www.quora.com/What-is-Facebooks-architecture (由Micha?l Figuière回答).   根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:. Web 前端是由 PHP 写的. Facebook 的 HipHop [1] 会把PHP转成 C++并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能.

谈谈Facebook的聊天系统架构

- - idea's blog
今天看到一份 Facebook 公司 2009 年的 PDF, 介绍它的聊天系统架构, 其中的一张图结构非常清晰, 所以我对这张图谈谈我的看法.. Web Tier: 用 PHP 开发, 聊天相关的业务逻辑代码. 如 AJAX 请求, HTML 页面拼接等. 这个模块整个其它的 3 个模块, 向浏览器提供了大部分的聊天接口..

HBase 系统架构

- - 博客园_首页
HBase是Apache Hadoop的数据库,能够对大型数据提供随机、实时的读写访问. HBase的目标是存储并处理大型的数据. HBase是一个开源的,分布式的,多版本的,面向列的存储模型. 5 可在廉价PC Server搭建大规模结构化存储集群. HBase是Google BigTable的开源实现,其相互对应如下:.

Digg.com 的系统架构

- - 标点符
在过去的几年间,我们一直致力于重构Digg的架构,现在我们称之为“Digg V4”.本文我们将全面介绍Digg的使用的系统和技术. 首先,我们来看下Digg给大众用户提供的服务吧:. 人们通过浏览器或者其他应用来访问这些Digg服务. 一些有Digg账户的用户,可以得到“我的新闻”. 每位用户可以得到的我们称之为“热门新闻”.

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

Android 系统架构分析

- - CSDN博客移动开发推荐文章
Android:开源的 Linux + Google 的封闭软件 + 私有的基带 + 运营商锁定 = 开放的 Android 手机. iPhone:开源的 BSD + 苹果的闭源软件 + 私有的基带 + 运营商锁定 = 封闭的苹果 iPhone. 一个平庸的应用商店,开发者依靠广告赚钱,商店并非独此一家,用户找不到好软件.

twitter系统架构分析

- - 企业架构 - ITeye博客
twitter系统架构分析. (一)twitter的核心业务. twitter的核心业务,在于following和be followed:. (1)following-关注. 进入个人主页,会看到你follow的人发表的留言(不超过140个字),这是following的过程;. (2)followed-被关注.

支付宝系统架构

- - 编程语言 - ITeye博客
支付宝的开源分布式消息中间件–Metamorphosis(MetaQ). Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件,类似于LinkedIn的Kafka,具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性,适用 于大吞吐量、顺序消息、广播和日志数据传输等场景,在淘宝和支付宝有着广泛的应用,现已开源.

大型网站系统架构粗探

- - 网站架构_搜搜博客搜索
  软件架构有很多种定义,下面是卡内基梅隆大学软件研究所关于软件架构的定义:.   软件架构是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计. 软件架构描述的对象是直接构成系统的抽象组件. 各个组件之间的连接则明确和相对细致地描述组件之间的通讯. 在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象.