求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
日600亿消息,月4.65亿用户——WhatsApp的Erlang世界
 
作者 Todd Hoff 火龙果软件  发布于 2014-04-09
 

两年,流量翻了10倍,月用户增至4.65亿,平均每日接收190亿消息,发送400亿消息,同时还有6亿张图片、2亿条语音、1亿条视频,然而他们依仗的只是1个10人工程团队。

在之前我们有分享过HighScalability创始人Tod Hoff总结的WhatsApp早期架构,其中包括了大量的Erlang优化来支撑单服务器200万并发连接,以及如何支撑所有类型的手机并提供一个完美的用户体验。然而时过境迁,两年后WhatsApp又是如何支撑10倍于之前的流量,以及应用的飞速扩展,这里我们一起看Tod带来的总结。以下为译文:

两年内的飞跃

天价应用当下的规模显然不能与两年前同日而语,这里总结了一些WhatsApp两年内发生的主要变化:

1.从任何维度上都可以看到WhatsApp的巨变,但是工程师的数量却一直未变。当下,WhatsApp有更多的主机、更多的数据中心、更多的内存、更多的用户以及更多的扩展性问题,然而最引以为豪的却是那支10人工程团队——每个工程师平均负责4000万个用户。当然,这也是云时代的胜利:工程师只负责软件的开发,网络、硬件及数据中心运维全部假手于人。

2.在之前,面对负载的激增,他们必须让单服务器支撑尽可能多的连接数,但是现在他们已经步出了那个时代。当然,基于总体成本的控制,他们仍然需要控制主机的数量并让SMP主机更效率的运行。

3.瞬时的好处。鉴于现在的架构已经囊括多媒体、图片、文本、音频,无需保存这些大体积格式的信息让系统大大的简化,架构的重心被放在吞吐量、缓存以及分片等。

4.Erlang的世界。即使他们打造的仍然是一个分布式系统,遇见的问题也大同小异,但是从始至终都在说Erlang确实值得称道。

5.Mnesia,这个Erlang数据库似乎已成为他们问题的主要来源。因此,不得不怀疑一味的紧抓Erlang会不会比较盲目,是否有其他更好的替代方案。

6.如此规模下问题之多你可以想象。海量连接数的保持、队列因优先级操作变得太长、计时器、不同负载下的代码表现问题、高负载下高优先级消息得不到处理、一个操作被另一个操作意外打断、故障导致的资源问题以及不同用户平台的兼容性等,巨型架构的打造绝非一朝一夕。

7.Rick的发现和处理问题能力让人赞叹,也可以说是吃惊。

Rick的分享总是非常精彩,他乐于分享许多细节,其中有许多只能在生产环境出现。下面是他最新分享总结:

统计

月4.65亿用户

平均每日接收190亿消息,发送400亿消息

6亿张图片,2亿条语音,1亿段视频

峰值期间1.47亿的并发连接数——电话连接到系统

峰值期间每秒23万次登陆操作——手机上线及下线

峰值期间每秒32.4万信息流入,71.2万的流出

约10个工程师致力于Erlang,他们肩负了开发与运维

节日的峰值>

平安夜流出达146 Gb/s,相当多的带宽用于服务手机

平安夜视频下载达3.6亿次

新年夜图片下载约20亿(46 k/s)

新年夜有张图片下载了3200万次

堆栈

Erlang R16B01(打了自己的补丁)

FreeBSD 9.2

Mnesia(数据库)

Yaws

使用了SoftLayer云服务和实体服务器

硬件

大约550个服务器+备份

150个左右的Chat服务器(每个服务器处理大约100万的手机、峰值期间1.5亿的连接)

250个左右的多媒体信息服务器

2x2690v2 Ivy Bridge 10-core(总计40的超线程技术)

数据库节点拥有512GB的内存

标准计算节点搭载64GB内存

SSD主要用于可靠性,存储资源不足时还用于存储视频

Dual-link GigE x2(公共的面向用户,私有的用于后端系统)

Erlang系统使用的核心超过1.1万个

系统概况

独爱Erlang

非常棒的语言,适合小工程团队。

非常棒的SMP可扩展性。可以运行高配的主机,并且有益于减少节点。运维复杂性只与节点数有关,而不是核心数。

可以飞快的更新代码。

扩展性就像扫雷,但是他们总可以在问题爆发之前发现并解决。世界级事件相当于做系统的压力测试,特别是足球赛,会带来非常高的峰值。服务器故障(通常是内存)、网络故障以及差的软件的推送都考验着系统。

传统的架构

手机客户端连接到MMS(多媒体)

Chat连接到瞬态离线存储,用户之间的消息传输通过后端系统控制。

Chat连接到数据库,比如Account、Profile、Push、Group等。

发送到手机的消息

文本消息

通知:群组消息,个人简介照片改变等

状态消息:输入状态、离开状态、在线或离线情况等

多媒体数据库

内存Mnesia数据库使用大约2TB的RAM,跨16个分片存储180亿条记录。

只存储正在发布的消息和多媒体,但是在多媒体发布时,会将信息储存在数据库中。

当下单服务器只运行100万的并发连接,而在两年前这个数字是200万,因为现在服务器要做的事情更多了:

随着用户量的增多,WhatsApp期望每个服务器上预留更多的空间以应对峰值。

许多过去不是运行在这个服务器上的功能现在被移到上面,因此服务器更忙了。

解耦

隔离瓶颈,让之不会存在整个系统中

紧耦合会导致相继故障

前端系统和后端系统首先要分离

隔离一切,让组件间不会存在影响。

正在解决问题时,保持尽可能多的吞吐量。

异步处理以最小化吞吐量延时

当延时不可预知及在不同点存在时,异步可以尽可能的保证吞吐量。

解耦可以让系统运行尽可能的快。

避免HOL阻塞

线头阻塞是首位处理会饿死队列中其他项目。

分离读和写队列。特别是在表格上执行事务,写入方面的延时不会影响读取队列,通常情况下读的速度会很快,因此任何阻塞都会影响读性能。

分离节点内部队列。如果节点或者网络连接的节点出现问题,它可能会阻塞应用程序中其他任务。因此,发往不同节点的消息会分配不同的进程(Erlang中的轻量级并发),因此只有当消息发送给问题节点时才会做备份,这将允许消息自由的传输,问题被隔离开来,给Mnesia打补丁以保证async_dirty级响应时间。App发送消息后就会被解耦,因此当一个节点发生故障时,不会导致负载问题。

在不确定延时场景下使用FIFO模型。

Meta Custering

本节出现在讲话的第29分钟,不幸但是,信息量不大。

需要一种方法来控制单集群体积,并允许他跨很长距离。

建立wandist,基于gen_tcp的分布式传输,由许多需要相互通信的节点组成。

1个基于pg2的透明路由层,建立一个单跳路由调度系统。

举个例子:两个数据中心的两个主集群,位于两个不同数据中心的两个多媒体集群,以及两个数据中心间一个共享的全局集群,他们之间都使用wandist进行连接。

例子

使用async_dirty来避免Mnesia事务耦合,大部分情况下不会使用事务。

只在从数据库中恢复时才使用call,其他情况下都使用cast来维持异步模型。在Erlang,消息队列会因等待handle_call响应而造成阻塞,handle_cast不会造成阻塞是因为它不关注结果。

Call使用超时而不是监视,减少远端进程竞争以及分发时传输的数据。

如果只是想追求最好的交付能力,为cast使用nosuspend。这样会阻止节点受到下游问题影响——不管是节点失败还是网络问题(在这些情况下,发送数据缓冲池会备份到发送节点上),进程发送的开始指令会被调度系统挂起,从而造成了相继故障——大家都在等待,却没有操作正在被处理。

使用大的发送缓冲器,从而降低收来自网络和下游系统的影响。

并行

任务分配

需要在1.1万个核心上分配任务

始于单线程的gen_server,然后建立了一个gen_factory负责多节点之间的任务传递。

在负载达到了一定程度,调度过程本身就变成了瓶颈,不仅仅是执行时间问题。

因此建立一个gen_industry,位于gen_factory之上,从而并行的摄入所有输入,并且有能力立刻给工作节点分配。

工作节点的寻址类似数据库通过key查找,因此这里存在不确定延时,比如IO,所以为了避免线头阻塞,这里使用了一个FIFO模型。

分割服务

在2到32间进行分割,大部分服务都被分割成32个。

pg2 addressing,分布式进程组,用于集群上的分片寻址。

节点进行主从设置,用于容灾。

限制访问单ets或者mnesia进程的数量到8,这会让锁争用处于控制当中。

Mnesia

因为没有使用事务去保证一致性,他们使用一个进程对一个节点上的记录进行连续访问。哈希到一个分片,会映射到1个mnesia fragment,最后会被调度到1个factory,随后是节点。因此,对每个单记录的访问都会被转换成一个独立的Erlang进程。

每个mnesia fragment都只能在1个节点上的应用程序等级进行读取,这样复制流只需要在一处进行。

一旦节点间存在复制流,分片的更新速度上就会存在瓶颈。他们给OTP打补丁以实现多个事务管理器,用以实现async_dirty,从而记录可以并行的进行修改,这将产生更多的吞吐量。

打补丁允许Mnesia库直接被分割到多个库上,这就意味着它可以写多个驱动,这么做可以直接提升磁盘的吞吐量。这里存在的问题是Mnesia达到峰值,通过多个磁盘来分摊IO,而为了进一步提升可扩展性及性能,甚至会加入SSD。

将Mnesia“island”缩减到2个,每个“island”都是一个Mnesia集群。因此在表格被分割成32份时,将会有16个“island”支撑一个表格。从而,他们可以进行更好的schema operation,因为只需要修改两个节点。在同时打开1或2个节点时,可以减少加载时间。

通过设置警报快速处理Mnesia中的网络分片,让它们继续保持运行,然后手动的调节将它们整合。

优化

在峰值情况下,离线存储系统曾是1个非常大的瓶颈,无法更快的将消息推送到系统。

每条消息都被用户快速的读取,60秒内完成50%。

添加一个回写缓存,这样消息就可以在写入文件系统之前被交付,缓存命中率达98%。

如果IO系统因为负载而阻塞,缓存会对消息交付起到额外的缓冲作用,直到IO系统恢复。

给BEAM(Erlang VM打补丁)以实现异步文件IO来避免线头阻塞问题,在所有异步工作线程上轮训文件系统端口请求,在大型mailbox和缓慢磁盘的情况下可以缓解写入。

让大型的mailbox远离缓存,有些用户加入了大量的组,每小时收入数千消息。他们会影响整个缓存,并让处理变慢。将它从缓存中驱除。需要注意的是,不成比例的大型用户处理是每个系统都存在的问题,其中包括Twitter。

使用大量的fragments降低mnesia表格的访问速度

账户表格被分割成512份打入“island”,这就意味着用户和这512个分片间存在一个稀疏映射,大部分的fragments都是空的和空闲的。

主机数量翻倍,但是吞吐量降低。记录访问变慢的原因是当目标为7时,哈希链的大小超过了2K。

这里存在的一个问题是哈希模式会导致建立大量的空bucket,有些甚至会非常长。双线的变化解决了这个问题,并将性能从4提升到1。

补丁

计时器轮上的竞争,当1个主机的连接数达到几百万,同时每个链接上的手机发生变化时就会建立或重置计时器,从而导致了每秒数十万的计时器。计时器轮上的锁则是竞争的主要来源,解决方法就是建立多个计时器轮。

mnesia_tm?是个非常大的选择循环,因此虽然负载未满,也可能会造成事务的积压,打补丁以收取事务流并且保存以作稍后处理。

添加多个mnesia_tm async_dirty发送者

存在许多的跨集群操作,因此mnesia最好从附近的节点加载。

给异步文件IO加入循环调度。

使用ets哈希开防止w/ phash2的同时发生。

优化ets main/name table来应对规模

不要队列mnesia dump,因为队列中存在太多的dumps时,schema ops将不可行。

2月22日的停机

即使做了如此多的努力,停机仍然不可避免,而且发生在了最不应该发生的时候,在被Facebook收购后宕机了210分钟。

负载的变化导致了问题的发生,此次宕机归结于后端系统的路由问题。

路由器造成了一片局域网的瘫痪,造成了集群中大量节点的断开和重连。同时,在节点重连之后,集群出现了前所未有的不稳定状态。

最终,他们不得不停机修复,这种情况在几年内都未出现过。

在检查中,他们发现了一个过度耦合的子系统。在断开和重连时,他们发现pg2在做n^3的消息,消息队列在数秒钟内从0飙升到了400万,为此他们推出了1个补丁。

特性发布

无法模拟如此规模的流量,特别是高峰期间,比如新年的钟声。因此,他们只能缓慢的发布特性,先在小流量下发布,然后迅速迭代直到良好运行,接着再向其他的集群推广。

上线是一个滚动的更新过程。冗余一切,如果他们想做一个BEAM更新,在安装后他们需要一个个的重启集群中的节点然后更新。也存在热补丁的情况,但是很罕见,通常的升级都非常麻烦。

 
相关文章

云计算的架构
对云计算服务模型
云计算核心技术剖析
了解云计算的漏洞
 
相关文档

云计算简介
云计算简介与云安全
下一代网络计算--云计算
软浅析云计算
 
相关课程

云计算原理与应用
云计算应用与开发
CMMI体系与实践
基于CMMI标准的软件质量保证
 
分享到
 
 


专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件的思考
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS
更多...   
相关培训课程

云计算原理与应用
Windows Azure 云计算应用

摩托罗拉 云平台的构建与应用
通用公司GE Docker原理与实践
某研发中心 Openstack实践
知名电子公司 云平台架构与应用
某电力行业 基于云平台构建云服务
云计算与Windows Azure培训
北京 云计算原理与应用