WhatsApp的Erlang世界

rick 的两个ppt整理

下载：2012 2013  ，使用半年erlang后，从新看这两个ppt才发现更多值的学习的地方，从ppt中整理以下：

 

- Prefer os:timestamp to erlang:now

  应该禁止使用erlang:now()，稍微用得多，整个node的%si 飙满，且总体性能数量级降低。

- Implement cross-node gen_server calls without  using monitors (reduces dist traffic and proc link lock contention)

  能够实现本身的rpc 模块，不是每次调用都monitor - call - demonitor，消耗太大。能够第一次调用就永久性monitor。

 

- Partition ets and mnesia tables and localize access to smaller number of processes

  为减小锁争用，对 ets,mnesia 作拆分，而且尽可能少的进程去访问同一个ets/mesia，高并发访问时严重影响性能且占用CPU。

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

 

- Small mnesia clusters

   使用小的mnesia 集群，从ppt看出whatsapp 所有采用优化过的 async_dirty 操做mneisa表，不使用事务，并且通常集群只有两个节点（一主一备，只操做主）。

   mnesia 集群有很是好的集群效果，但大的集群对性能影响太大。曾经测试过20个节点集群，在其中一个节点执行几十字节行的：read-update transaction，8K/s 居然把node的千M网卡跑满了。

 

- Offloaded SSL termination to stud

    whatsapp 的多媒体文件下载使用的是https，yaws服务前使用 stud: https://github.com/bumptech/stud  做为ssl 的proxy。

    曾经测试，16G机器最多20w链接 2500/s 新建链接速度，ssl新建链接处理为CPU密集型，纯 erlang实现过于低效，性能在大量短链接状况并不乐观。不过使用大量loopback 地址解决64K tcp port 问题，若是链接数太高的话，也带来内存消耗，也许能够在stud将请求rpc 化转给后端处理也能解决。

 

-  chat message encrypt

　　https://github.com/davidgfnet/wireshark-whatsapp/blob/master/protocol-spec.txt

      ssl 流程过于复杂，链接速度慢；使用密码+random code 做为rc4密钥加密，连密钥交互过程都省了。

 

   whatsapp 存储方案：

  - mnesia memory（相似redis 当作 cache用，相比好处嘛，更灵活）：

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

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

由于whatsapp 不会长期存储全部的用户消息记录，而是接受完后就删除。每条消息都被用户快速的读取，60秒内完成50%。

所以设计全部消息先存储在 内存Mnesia，若是必定时间被接收完了，就直接删除。长时间未收取才落地。

 

  - mnesia disc（用户信息，离线消息）：

图片、音视频文件索引信息，实际文件存储在磁盘上面（ppt上每台机器存储189G * 16 Node，不是说每台机器500GB内存么）。

用户信息、消息等

 

[转] WhatsApp的Erlang世界 （很是棒的一篇文章）

 http://www.csdn.net/article/2014-04-04/2819158-how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an/1

在以前咱们有分享过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更新，在安装后他们须要一个个的重启集群中的节点而后更新。也存在热补丁的状况，可是很罕见，一般的升级都很是麻烦。