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更新,在安装后他们需要一个个的重启集群中的节点然后更新。也存在热补丁的情况,但是很罕见,通常的升级都非常麻烦。

WhatsApp的Erlang世界的更多相关文章

  1. Erlang C1500K长连接推送服务-性能

    Whatsapp已经使用Erlang在生产环境跑到96GB内存单机 3M长连接,参加:WhatsApp的Erlang世界.毕竟业务级别能达到Whatsapp那样极少,现在只有千万级,单机太多挂一台影响 ...

  2. Erlang中的图形化检测工具(4)

    这儿例举出若干个用于检视运行时系统的图形化工具,这些工具可以很好地帮助我们增进对系统的理解.借助这些工具,我们可以很好地以图形化方式观察进程.应用和监督层级. (1) Appmon.Appmon 是用 ...

  3. 同一世界服务器架构--Erlang游戏服务器

        Erlang最大的优点是方便,很多基础功能都已经集成到Erlang语言中.之前用C++写服务器的时候,管理TCP连接很繁琐,需要写一大堆代码来实现.底层的框架需要写很多代码实现,这样既浪费时间 ...

  4. 进入Erlang的世界

    http://erlang.group.iteye.com/group/wiki/1407-to-enter-the-world-of-erlang 进入Erlang的世界 作为程序员,我们曾经闻听很 ...

  5. 同一个世界(erlang解题答案)

    最近玩同一个世界,才几关就把3次提示用完了,十分气愤, 于是写了程序来解~~~ o(^▽^)o 以2-1为例子,题目如下 以0代表白色,1代表黑色,抽象的就是这样的 ----------------- ...

  6. [Erlang 0105] Erlang Resources 小站 2013年1月~6月资讯合集

    很多事情要做,一件一件来; Erlang Resources 小站 2013年1月~6月资讯合集,方便检索.      小站地址: http://site.douban.com/204209/     ...

  7. 通向高可扩展性之路(WhatsApp篇)---- 脸书花了190亿买来的WhatsApp的架构

    原文链接:http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-bill ...

  8. Erlang基础 -- 介绍 -- 历史及Erlang并发

    前言 最近在总结一些Erlang编程语言的基础知识,拟系统的介绍Erlang编程语言,从基础到进阶,然后再做Erlang编程语言有意思的库的分析. 其实,还是希望越来越多的人关注Erlang,使用Er ...

  9. Erlang 转至维基百科

    Erlang(英语发音:/ˈɜrlæŋ/)是一种通用的并行程序设计语言,它由乔·阿姆斯特朗(Joe Armstrong)在瑞典电信设备制造商爱立信所辖的计算机科学研究室开发,目的是创造一种可以应付大规 ...

随机推荐

  1. react+redux官方实例TODO从最简单的入门(3)-- 删

    上一篇文章我们实现了增删改查中<增>这个功能 那么这一篇我们将实现第二个功能,删! 首先增加一个状态: actions中增加对应的约定 到reducer里面设置执行的函数(这里todo.i ...

  2. Linux中不同主机建立免登陆

    ssh-keygen -t rsa scp /root/.ssh/id_rsa.pub  root@192.168.0.236:/root/.ssh/authorized_keys cat /root ...

  3. Vue.js学习笔记(4)

    分享一段将 json数组数据以  csv格式导出的代码: html: <button class="btn btn-danger" @click='exportData'&g ...

  4. [No000007]搜索引擎以图搜图的原理

    之前,Google把"相似图片搜索"正式放上了首页. 你可以用一张图片,搜索互联网上所有与它相似的图片.点击搜索框中照相机的图标. 一个对话框会出现. 你输入网片的网址,或者直接上 ...

  5. JSP页面格式化货币金额,千分位

    <fmt:formatNumber value="${值}" pattern="currency"></fmt:formatNumber> ...

  6. JSTL 核心标签库

    SP标准标签库(JSTL)是一个JSP标签集合,它封装了JSP应用的通用核心功能. JSTL支持通用的.结构化的任务,比如迭代,条件判断,XML文档操作,国际化标签,SQL标签. 除了这些,它还提供了 ...

  7. .Net Core 在Linux服务器下部署程序--(3). 部署.net Core程序

    确认第二步中的软件已安装完成 lrzsz文件上传下载软件 zip与unzip压缩包软件 net core 相关软件 确认上述软件安装完成之后,开始部署程序 创建部署文件夹 我的习惯是在usr文件夹下新 ...

  8. 【Python3爬虫】网易云音乐歌单下载

    一.目标: 下载网易云音乐热门歌单 二.用到的模块: requests,multiprocessing,re. 三.步骤: (1)页面分析:首先打开网易云音乐,选择热门歌单,可以看到以下歌单列表,然后 ...

  9. vue 学习笔记(一)

    对于 vue 官网给的教程由浅及深,非常容易上手.我之前有过 react 项目开发经验,对 webpack 打包,脚手架这一类的东西并不陌生.所以也是我上手比较快的原因吧.简单将我在学习 vue 中遇 ...

  10. docker 启动报错 WARNING: IPv4 forwarding is disabled. Networking will not work.

    解决办法: # vi /etc/sysctl.conf 或者 # vi /usr/lib/sysctl.d/00-system.conf 添加如下代码:     net.ipv4.ip_forward ...