# Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构
> 原文: [http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html)
![](https://img.kancloud.cn/8d/c9/8dc9f0e96bf4c7fcad0a62d6a3cd419f_240x155.png)
[Rick Reed](http://www.linkedin.com/pub/rick-reed/2/186/427) 在 3 月即将举行的演讲中,标题为 [,即“十亿”和“ B”:在 WhatsApp 上扩展到新的水平](http://lanyrd.com/2014/erlangfactory/scwqrt/) 令人眼前一亮 [WhatsApp](http://en.wikipedia.org/wiki/WhatsApp) 统计信息:
> 拥有数百个节点,数千个内核,数百 TB 的 RAM 的东西,并希望为不久将在全球范围内成为现实的数十亿智能手机提供服务? WhatsApp 上基于 Erlang / FreeBSD 的服务器基础结构。 在满足对消息传递服务不断增长的需求方面,我们面临着许多挑战,但是随着我们不断扩大服务范围(> 8000 核)和速度(>每秒 70M Erlang 消息), 系统。
但是由于我们还没有那个话题,让我们来看一下 Rick Reed 两年前在 WhatsApp 上的演讲: [扩展到数百万个同时连接](http://vimeo.com/44312354) 。
在 Yahoo 期间,Rick Reed 用 C ++构建了高性能的消息总线,对于高可伸缩性体系结构并不是陌生的。 创始人也是前雅虎人,他们在缩放系统方面经验不多。 因此,WhatsApp 凭借其扩展能力诚实地表现出来。 而且由于他们的目标是在世界上每部智能手机上都拥有大毛毛的大胆目标,因此几年之内可能会增加 50 亿部手机,因此他们需要充分利用这种体验。
在我们弄清事实之前,让我们先讨论一下这个绝对迷人的难题:WhatsApp 对 Facebook 可能价值 190 亿美元?
作为一名程序员,如果您问我 WhatsApp 是否值那么多,我会回答否定! 它只是通过网络发送内容。 变得真实。 但是我也是那个认为我们不需要博客平台的人,因为远程登录到您自己的服务器,用 vi 编辑 index.html 文件然后用 HTML 编写帖子有多难? 我花了相当长的时间才意识到这不是愚蠢的代码,而是让所有这些用户都喜欢并使用您的产品才是最困难的部分。 您无法购买爱情
是什么让 WhatsApp 如此有价值? 技术? 忽略所有说可以使用 PHP 在一周内编写 WhatsApp 的人。 那根本不是真的。 就像我们将看到的很酷的技术一样。 但可以肯定的是,如果他们愿意的话,Facebook 有足够的能力来构建 WhatsApp。
让我们看一下功能。 我们知道 WhatsApp 是 [无头](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) (无广告,无头,无游戏)的产品,其忠实的 [用户 世界](http://www.wired.com/wiredenterprise/2014/02/whatsapp-rules-rest-world/) 。 它在残酷的 SMS 收费世界中提供免费短信。 作为一个庇护的美国人,最令我惊讶的是,有多少真实的人使用 WhatsApp 与家人和朋友保持联系。 因此,当您使用 WhatsApp 时,您认识的人很可能已经在使用它,因为每个人都拥有一部电话,从而缓解了空社交网络的问题。 它积极地跨平台运行,因此您认识的每个人都可以使用它,并且它将正常工作。 它“行之有效”是经常使用的短语。 它功能齐全(共享位置,视频,音频,图片,一键通,语音消息和照片,阅读回执,群组聊天,通过 WiFi 发送消息,并且无论收件人是否在线,都可以完成所有操作) 或不)。 它很好地处理了本地语言的显示。 使用您的手机号码作为身份并将您的联系人列表作为社交图表非常简单。 无需电子邮件验证,用户名和密码,也不需要信用卡号。 这样就可以了。
令人印象深刻,但那不值 190 亿美元。 其他产品可以在功能上竞争。
[Google 想要](https://www.theinformation.com/Google-Was-Willing-to-Beat-Facebook-s-19-Billion-Offer-for-WhatsApp) 是可能的原因。 这是 [威胁](http://www.forbes.com/sites/parmyolson/2013/12/19/watch-out-facebook-whatsapp-climbs-past-400-million-active-users/) 的威胁。 费用为每位用户 0.99 美分。 Facebook 是 [绝望的](http://www.foxbusiness.com/technology/2014/02/21/facebook-buying-whatsapp-is-desperate-move/) 。 适用于 [您的电话簿](http://www.theregister.co.uk/2014/02/20/facebook_whatsapp_19bn_buy_also_45_for_your_phonebook/) 。 用于元数据(即使 WhatsApp 不保存任何元数据)。
适用于 [4.5 亿活跃用户](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) ,用户基础每天增长一百万,潜在的十亿用户。 Facebook 需要其下一个十亿用户使用 WhatApp。 当然,如果有的话,那一定是一部分。 每位用户约 40 美元的成本似乎并不合理,尤其是在大量库存支付的情况下。 Facebook 以 [每位用户 30 美元的价格收购了 Instagram](http://finance.fortune.cnn.com/2012/04/10/why-instagram-is-worth-1b-to-facebook/) 。 Twitter 用户为 [,价值$ 110](http://www.forbes.com/sites/georgeanders/2013/11/07/a-twitter-user-is-worth-110-facebooks-98-linkedins-93/) 。
本尼迪克特·埃文斯 [很好地证明了](https://www.youtube.com/watch?v=VnhbvS0MBXE) 移动业务是一个价值 1 万亿美元的业务,WhatsApp 正在扰乱该行业的 SMS 部分,全球范围内 全球短信系统每天仅发送 200 亿条短信,每天发送 180 亿条短信,从而实现超过 1000 亿美元的收入。 从 PC 到几乎普及的智能手机的过渡发生了根本变化,机遇的规模是一个比 Facebook 正常运营的市场更大的可寻址市场。
但是 Facebook 承诺不会投放广告,也不会出现干扰,那么胜利在哪里?
[商业使用移动](http://www.happymarketer.com/singapore-is-progressively-doing-business-over-whatsapp-are-you) 的有趣发展。 WhatsApp 用于为项目团队创建小组对话,风险投资家通过 WhatsApp 进行交易流程对话。
Instagram 用于科威特 [出售绵羊](http://storify.com/cbccommunity/kuwait-entrepreneurs-use-instagram-to-sell-sheep) 。
WhatsApp 的竞争对手微信在 1 月份推出了出租车出租车服务。 在第一个月, [接待了 2100 万辆出租车](http://www.techinasia.com/wechat-21-million-taxi-rides-booked/) 。
电子商务的未来似乎将通过移动消息传递应用程序进行传播,它一定是电子商务吗?
不仅仅是使用 WhatsApp 的企业曾经在台式机或网络上使用过这些应用程序。 西班牙的警务人员使用 WhatsApp 来抓捕罪犯。 意大利的人们使用它来组织篮球比赛。
出于显而易见的原因,商务和其他应用程序正在向移动设备转移。 每个人都拥有移动设备,这些消息传递应用程序功能强大,免费且使用便宜。 您不再需要桌面或 Web 应用程序即可完成工作。 许多功能可以叠加在消息传递应用程序上。
因此,消息传递对 Google 和 Facebook 构成了威胁。 桌面已死。 网络快要死了。 消息传递+移动是 [整个生态系统,它们避开了其渠道](https://news.ycombinator.com/item?id=7282876) 。 消息传递已经成为[在移动而不是搜索上的参与中心](http://cubed.fm/2014/02/cubed-episode-18-the-paradigm-shift-of-mobile-engagement-models/),它改变了事物的发现方式以及改变应用程序将赢得未来的本质。 我们不仅是前网页排名,而且是网络前。
Facebook 是否需要进入这个市场或变得无关紧要?
随着移动技术的发展,我们看到了 Facebook 的无人化。 Facebook 的桌面 Web 界面是门户样式的界面,可访问后端提供的所有功能。 它很大,很复杂而且吱吱作响。 谁真正喜欢 Facebook UI?
当 Facebook 转向移动设备时,他们尝试了门户方法,但这种方法无效。 因此,他们采用的策略是更小,更集中,[专用的应用](http://www.theverge.com/2014/1/16/5269664/facebook-plans-suite-of-standalone-mobile-apps-for-2014)。 移动第一! 在小屏幕上,您只能做很多事情。 在移动设备上,找到特殊的应用程序要比在复杂的门户风格的应用程序中找到深深的菜单要容易得多。
但是 Facebook 向前迈进了一步。 他们不仅在创建专用的应用程序,而且还在提供具有相似功能的多个竞争应用程序,而这些应用程序甚至可能没有共享后端基础架构。 我们通过 Messenger 和 WhatsApp,Instagram 和 Facebook 的照片应用程序看到了这一点。 Paper 是 Facebook 的备用界面,功能非常有限,但它做得很好。
康韦定律可能在这里适用。 “设计系统的组织受约束以产生作为这些组织的通信结构副本的设计”的想法。 借助整体后端基础架构,我们获得了类似于 Borg 的门户设计。 向移动的转变使组织摆脱了这种思维方式。 如果可以构建仅提供一部分 Facebook 基础结构视图的应用程序,则可以构建完全不使用 Facebook 基础结构的应用程序。 而且如果他们不需要 Facebook 的基础架构,那么它们完全可以免费完全不由 Facebook 构建。 那么,Facebook 到底是什么?
Facebook 首席执行官马克·扎克伯格(Mark Zuckerberg)有他自己的看法,他在移动世界大会 上的 [主旨演讲中说,Facebook 收购 WhatsApp 与该公司密切相关。 Internet.org 愿景:](http://techcrunch.com/2014/02/24/whatsapp-is-actually-worth-more-than-19b-says-facebooks-zuckerberg/)
> 的想法是开发一组免费使用的基本互联网服务-“互联网 911”。这些服务可能是社交网络服务,例如 Facebook,消息服务,搜索或其他 像天气一样。向用户免费提供这些捆绑服务将像各种网关药物一样工作-那些如今可能能够负担数据服务和电话费用的用户根本看不出为什么要为这些数据付费 这将为他们提供为何重要的一些背景信息,这将使他们为此类更多的服务付费(或者希望如此)
这是长距离比赛,这是一种游戏,拥有大量有价值的股票,您可以玩。
我们得出结论了吗? 我不这么认为。 如此惊人的美元金额加上如此微弱的明显立即回报,以至于长期游戏的解释实际上确实是有道理的。 我们还处在移动的初期。 没有人知道未来会是什么样,所以不必费力强迫未来看起来像您的过去。 Facebook 似乎就是这样做的。
但是足够了。 仅 32 位工程师如何支持 4.5 亿活跃用户? 让我们找出...
## 来源
这里的警告是,我们对所有架构的 WhatsApp 知之甚少。 只是零零碎碎地从各种来源收集而来。 Rick Reed 的主要演讲是关于使用 Erlang 时使服务器达到 200 万连接的优化过程,这很有趣,但这不是完整的体系结构。
* [从 2012 年起缩放至数百万个同时连接](http://vimeo.com/44312354) ( [幻灯片](http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf) ),作者:瑞克·里德
* [Erlang Factory 对 Rick Reed 的采访](http://mirkobonadei.com/interview-with-rick-reed/)。
* [对来自 Erlang 的 WhatsApp](http://pdincau.wordpress.com/2013/03/27/an-interview-with-eugene-fooksman-erlang/) 的 Eugene Fooksman 的采访。
* [DLD14-WhatsApp 怎么了? (Jan Koum,David Rowan)](http://www.youtube.com/watch?v=WgAtBTpm6Xk&feature=youtu.be)
* [yowsup](https://github.com/tgalal/yowsup/wiki/Yowsup-Library-Documentation) 是 WhatsApp API 的开源版本。 由于 DMCA 移除,该存储库现在不可用[,但是它们确实记录了 WhatsApp 的一些内部工作原理。 万物的多样性。](http://openwhatsapp.org/blog/2014/02/13/mass-dmca-takedowns-whatsapp/)
* 在 *相关文章下列出的一些来源。*
## 统计信息
这些统计信息通常适用于当前系统,而不是我们正在讨论的系统。 当前系统的讨论将包括有关数据存储,消息传递,元集群以及更多 BEAM / OTP 补丁的黑客技巧。
* 4.5 亿活跃用户,并且达到这个数字的速度超过历史上任何其他公司。
* 32 位工程师,一名开发人员支持 1400 万活跃用户
* 每天在七个平台上(入站+出站)发送 500 亿条消息
* 每天有超过一百万的用户注册
* 为广告投入了$ 0
* 来自红杉资本的 6000 万美元[投资; 红杉将赚 34 亿美元](http://techcrunch.com/2011/04/08/sequoia-whatsapp-funding/)
* 35%是 Facebook 现金中的[被用于交易](http://finance.fortune.cnn.com/2014/02/19/facebook-whatsapp-the-other-numbers/)
* 数百个节点
* > 8000 色
* 数百兆字节的 RAM
* >每秒 70M Erlang 消息
* 在 2011 年,WhatsApp 在具有内存和 CPU 的单台计算机上实现了 [100 万个已建立的 tcp 会话](http://blog.whatsapp.com/index.php/2011/09/one-million/) 。 在 2012 年,它被推翻了 [200 万 tcp 连接](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/) 。 2013 年,WhatsApp [发了推文](https://twitter.com/WhatsApp/status/286591302185938946) :12 月 31 日,我们创下了新的记录天:入站 7B 消息,出站 11B 消息=一天处理的总消息量为 180 亿 ! 2013 年快乐!!!
## 平台
### 后端
* Erlang
* FreeBSD
* 偏航,lighttpd
* PHP
* 自定义补丁 [BEAM](http://www.erlang-factory.com/upload/presentations/708/HitchhikersTouroftheBEAM.pdf) (BEAM 类似于 Java 的 JVM,但适用于 Erlang)
* 自定义 XMPP
* 托管[可能位于软件层](http://www.ip-adress.com/whois/whatsapp.com) 中
### 前端
* 七个客户端平台:iPhone,Android,Blackberry,诺基亚 Symbian S60,诺基亚 S40,Windows Phone 、?
* SQLite
### 硬件
* 面向用户的标准服务器:
* Dual Westmere Hex-core(24 个逻辑 CPU);
* 100GB RAM,SSD;
* 双网卡(公用面向用户的网络,专用后端/分发);
## 产品
* **重点是消息传递**。 不管人们身在何处,都可以联系世界各地的人们,而不必花很多钱。 创始人扬·库姆(Jan Koum)记得 1992 年与全世界的家人建立联系有多么困难。
* **隐私** 。 由扬·库姆(Jan Koum)在乌克兰度过的成长经历所塑造,那里没有什么私人物品。 消息不存储在服务器上; 聊天记录未存储; 目标是尽可能少地了解用户; 您的姓名和性别未知; 聊天记录仅在您的手机上。
## 常规
* WhatsApp 服务器几乎完全在 Erlang 中实现。
* 执行后端消息路由的服务器系统是在 Erlang 中完成的。
* 伟大的成就是,使用很小的服务器空间就可以管理活动用户的数量。 团队的共识是,这很大程度上是因为 Erlang。
* 值得一提的是 [Facebook 聊天室](http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf)于 2009 年用 Erlang 编写,但由于很难找到合格的程序员,他们放弃了它。
* WhatsApp 服务器已从 ejabberd 启动
* Ejabberd 是用 Erlang 编写的著名开源 Jabber 服务器。
* 最初选择是因为它开放,受到开发人员的好评,易于启动以及 Erlang 对于大型通信系统的长期适用性的保证。
* 接下来的几年用于重写和修改 ejabberd 的相当多的部分,包括从 XMPP 切换到内部开发的协议,重组代码库和重新设计一些核心组件,并对 Erlang VM 进行很多重要的修改,以 优化服务器性能。
* 为了每天处理 500 亿条消息,重点是建立一个可靠的有效系统。 获利是一个值得关注的问题,它远未实现。
* 系统运行状况的主要衡量标准是消息队列长度。 节点上所有进程的消息队列长度将得到持续监控,如果它们积压的积压超过预设阈值,则会发出警报。 如果一个或多个进程落后,则会发出警报,这将提供指向下一个攻击瓶颈的指针。
* 通过上载图像,音频或视频以发送到 HTTP 服务器,然后发送指向内容的链接及其 Base64 编码缩略图(如果适用)来发送多媒体消息。
* 通常每天都会推送一些代码。 通常,一天要多次,但通常可以避免高峰时段。 Erlang 有助于积极地将修补程序和功能投入生产。 热加载意味着可以推送更新而无需重启或流量转移。 通常,再次通过热加载可以很快消除错误。 系统趋向于松散耦合,这使得很容易以增量方式推出更改。
* Whatsapp 应用程序使用什么协议? WhatsApp 服务器池的 SSL 套接字。 所有消息都会在服务器上排队,直到客户端重新连接以检索消息为止。 消息的成功检索将发送回 whatsapp 服务器,该服务器将该状态转发回原始发件人(它将在消息旁边显示为“复选标记”图标)。 客户端接受消息后,就会从服务器内存中清除消息
* 在 Whatsapp 中,注册过程如何在内部进行? WhatsApp 曾经根据电话 IMEI 号码创建用户名/密码。 最近更改了。 WhatsApp 现在使用应用程序的一般请求发送唯一的 5 位数 PIN 码。 然后,WhatsApp 将 SMS 发送到指定的电话号码(这意味着 WhatsApp 客户端不再需要在同一部电话上运行)。 然后,根据密码,该应用会向 WhatsApp 请求一个唯一的密钥。 该密钥用作将来所有呼叫的“密码”。 (此“永久”密钥存储在设备上)。 这也意味着注册新设备将使旧设备上的密钥无效。
* Android 上使用了 Google 的推送服务。
* Android 上的更多用户。 Android 更加令人愉快。 开发人员可以对功能进行原型设计,并在一夜之间将其推销给数亿用户,如果有问题可以迅速解决。 iOS,不是很多。
## 每服务器 2 百万个以上的连接
* 经历了很多用户增长,这是一个好问题,但这也意味着必须花钱购买更多的硬件,并增加管理所有这些计算机的操作复杂性。
* 需要针对流量增加进行规划。 例如足球比赛和西班牙或墨西哥的地震。 这些发生在高峰流量负载附近,因此需要有足够的备用容量来处理高峰和颠簸。 最近的一场足球比赛在每日高峰时出站邮件率激增了 35%。
* 初始服务器装入是每台服务器 200 个同时连接。
* 推断出来将意味着很多服务器都有望实现增长。
* 面对突发负载,服务器很脆弱。 网络故障和其他问题将会发生。 需要解耦组件,以免大容量情况下变脆。
* 目标是每服务器一百万个连接。 当它们以 200K 连接运行时,给出了一个宏伟的目标。 运行具有裕量的服务器以允许发生世界性事件,硬件故障以及其他类型的故障,将需要足够的弹性来处理高使用率水平和故障。
## 用于提高可伸缩性的工具和技术
* 编写了系统活动报告程序工具(wsar):
* 记录整个系统的系统统计信息,包括 OS 统计信息,硬件统计信息,BEAM 统计信息。 它是经过构建的,因此很容易从其他系统(例如虚拟内存)中插入指标。 跟踪 CPU 利用率,总体利用率,用户时间,系统时间,中断时间,上下文切换,系统调用,陷阱,已发送/已接收的数据包,所有进程中队列中消息的总数,繁忙的端口事件,流量速率,输入/输出字节 ,排程统计资料,垃圾收集统计资料,收集的字词等。
* 最初每分钟运行一次。 由于系统的驱动更加困难,因此需要一秒钟的轮询分辨率,因为如果一分钟内看不到该事件,则该事件将在空间中发生。 真正细粒度的统计数据,以查看一切运行情况。
* CPU 中的硬件性能计数器(pmcstat):
* 以时间百分比查看 CPU 的位置。 可以知道执行仿真器循环花费了多少时间。 在他们的情况下,这是 16%,告诉他们只有 16%的人在执行仿真代码,因此即使您能够删除所有 Erlang 代码的所有执行时间,也只能节省总运行时间的 16%。 这意味着您应该专注于其他领域以提高系统效率。
* dtrace,内核锁计数,fprof
* Dtrace 主要用于调试,而不是性能。
* 在 FreeBSD 上修补了 BEAM 以包括 CPU 时间戳。
* 编写脚本以创建所有进程的汇总视图,以查看例程在所有时间上所花费的时间。
* 最大的获胜是在打开锁定计数的情况下编译模拟器。
* 一些问题:
* 较早的时候,在垃圾回收例程上花费了更多时间,这被减少了。
* 看到已调离的网络堆栈有一些问题。
* 大多数问题与模拟器中的锁争用有关,这在锁计数的输出中表现出强烈的作用。
* 测量:
* 合成工作负载(意味着从您自己的测试脚本生成流量)对于以极大规模调整面向用户的系统的价值很小。
* 非常适合简单的界面(例如用户表),可以尽快生成插入和读取。
* 如果要在一台服务器上支持一百万个连接,则将需要 30 台主机打开足够的 IP 端口以生成足够的连接来仅测试一台服务器。 对于 200 万台服务器,它将占用 60 个主机。 只是很难产生这种规模。
* 在生产期间看到的流量类型很难生成。 可以猜测正常的工作量,但是实际上可以看到网络事件,世界事件,因为多平台可以看到客户端之间行为的变化以及国家/地区的变化。
* Tee 的工作量:
* 进行正常的生产流量并将其通过管道传输到单独的系统。
* 对于可能限制副作用的系统非常有用。 不想散布流量并做会影响用户永久状态或导致向用户发送多条消息的事情。
* Erlang 支持热加载,因此可以在完整的生产负载下运行,有一个想法,进行编译,在程序运行时加载更改并立即查看更改的好坏。
* 添加了旋钮以动态更改生产负载,并查看其如何影响性能。 将跟踪 sar 输出,以查看诸如 CPU 使用率,VM 使用率,侦听队列溢出以及转动旋钮以查看系统如何做出反应。
* 实际生产负荷:
* 终极测试。 同时进行输入工作和输出工作。
* 将服务器放入 DNS 两次,这样它将获得正常流量的两倍或三倍。 由于客户端不遵守 DNS TTL 且存在延迟,因此造成了 TTL 问题,因此无法迅速做出反应以获取更多无法处理的流量。
* IPFW。 将流量从一台服务器转发到另一台服务器,这样可以为主机提供所需客户端连接的确切数量。 一个错误导致内核崩溃,因此无法很好地工作。
* 结果:
* 开始于每个服务器 200K 个并发连接。
* 第一个瓶颈出现在 425K。 系统出现了很多争论。 工作停止了。 对调度程序进行检测,以衡量正在执行的工作,休眠或旋转的工作量。 在负载下,它开始达到休眠状态,因此整个系统使用了 35-45%的 CPU,但调度程序的利用率为 95%。
* 第一轮修复程序已超过一百万个连接。
* VM 使用率为 76%。 CPU 占 73%。 BEAM 模拟器以 45%的利用率运行,这与用户百分比非常接近,这很好,因为该模拟器以用户身份运行。
* 通常,CPU 利用率不是衡量系统繁忙程度的好方法,因为调度程序使用 CPU。
* 一个月后,解决瓶颈问题的原因是每个服务器有 200 万个连接。
* BEAM 利用率为 80%,接近 FreeBSD 可能开始分页的位置。 CPU 大致相同,连接增加了一倍。 调度程序遇到了争用,但运行得很好。
* 似乎是个停止的好地方,因此开始分析 Erlang 代码。
* 最初每个连接有两个 Erlang 进程。 切成一个。
* 使用计时器做了一些事情。
* 每个服务器的连接数达到 280 万峰值
* 571k pkts / sec,> 200k dist msgs / sec
* 进行了一些内存优化,因此 VM 负载降至 70%。
* 尝试了 3 百万个连接,但失败了。
* 当系统出现问题时,请查看长消息队列。 单个消息队列或消息队列的总和。
* 已添加到 BEAM 工具中有关每个进程的消息队列统计信息。 发送/接收多少消息,速度有多快。
* 每 10 秒采样一次,可以看到一个进程在其消息队列中有 600K 条消息,出队列率为 40K,延迟为 15 秒。 预计排水时间为 41 秒。
* 调查结果:
* Erlang + BEAM 及其修复-具有出色的 SMP 可扩展性。 几乎线性的可伸缩性。 卓越。 在 24 路机器上,可以以 85%的 CPU 使用率运行系统,并且可以保持生产负荷。 它可以像这样整天运行。
* 证明 Erlang 的程序模型。
* 服务器启动的时间越长,它将积累长期处于运行状态的连接(大多数情况下处于空闲状态),因此它可以处理更多的连接,因为这些连接对每个连接而言并不那么忙。
* 竞争是最大的问题。
* 他们的 Erlang 代码中进行了一些修复,以减少 BEAM 的争用问题。
* 一些已修补到 BEAM。
* 对工作负载进行分区,因此无需过多地处理处理器。
* 时间锁定。 每次从端口传递消息时,它看起来都会更新一天中的时间,这是所有调度程序中的一个锁,这意味着所有 CPU 都在打一个锁。
* 优化使用计时器轮。 删除了 bif 计时器
* 检查 IO 时间表在算术上增长。 创建的 VM 崩溃将在各个点重新分配哈希表。 改进以使用表格的几何分配。
* 添加了写入文件,该文件占用一个您已经打开的端口,以减少端口争用。
* Mseg 分配是所有分配器之间的单点争用。 按调度程序进行。
* 接受连接时有很多端口事务。 设置选项以减少昂贵的端口交互。
* 当消息队列积压很大时,垃圾回收将破坏系统的稳定性。 因此,暂停 GC 直到队列缩小。
* 避免付出一些常见的代价。
* 将 TSE 时间计数器从 FreeBSD 9 反向移植到了 8。读取计时器更便宜。 快速获取时间,比购买芯片便宜。
* 从 FreeBSD 9 向后移植 igp 网络驱动程序,因为在 NIC 锁定时存在多个队列问题。
* 增加文件和套接字的数量。
* Pmcstat 显示花费了大量时间来查找网络堆栈中的 PCB。 因此,增加哈希表的大小可以使查找更快。
* BEAM 补丁
* 先前提到的检测补丁。 仪器调度程序可获取利用率信息,消息队列的统计信息,睡眠次数,发送速率,消息计数等。可以使用 procinfo 以 Erlang 代码进行操作,但是连接数百万时非常慢。
* 统计信息收集非常有效,因此可以在生产中运行。
* 统计信息以 3 个不同的衰减间隔保持:1、10、100 秒间隔。 允许随着时间推移查看问题。
* 使锁计数适用于较大的异步线程数。
* 为调试锁定计数器添加了调试选项。
* 调整
* 将调度程序的唤醒阈值设置为低,因为调度程序会进入睡眠状态并且永远不会唤醒。
* 优先使用 mseg 分配器,而不是 malloc。
* 每个调度程序的每个实例都有一个分配器。
* 配置载波大小从大到大。 使 FreeBSD 使用超级页面。 降低了 TLB 跳动率,并提高了同一 CPU 的吞吐量。
* 以实时优先级运行 BEAM,以使诸如 cron 作业之类的其他事情不会中断计划。 防止可能导致重要用户流量积压的故障。
* 修补程序可记录旋转计数,以便调度程序不会旋转。
* 失忆症
* 首选 os:timestamp 而不是 erlang:now。
* 不使用事务,但是使用远程复制遇到了积压。 每个表的并行复制可提高吞吐量。
* 实际上还有很多更改。
## 课程
* **优化是一项仅适用于巨魔和工程师的深色球衣工作。** 。 当 Rick 进行他为获得 200 万个服务器连接所做的所有更改时,我很麻木。 请注意,编写工具,运行测试,向后移植代码,将测试对象添加到几乎每个堆栈级别,调试系统,查看痕迹,处理非常低级的细节并试图理解所有内容都需要大量工作 。 这就是消除瓶颈,以将性能和可伸缩性提高到极限的方法。
* **获取所需的数据**。 **编写工具。 补丁工具。 添加旋钮。** Ken 坚持不懈地扩展系统以获取他们所需的数据,不断为他们管理和优化系统所需的数据编写工具和脚本。 尽一切努力。
* **测量。 消除瓶颈。 测试。 重复。** 这就是您的操作方式。
* **二郎岩石!** Erlang 继续证明其作为通用,可靠,高性能平台的能力。 尽管就个人而言,所需的所有调优和补丁处理都对该主张造成了怀疑。
* **破解病毒代码并获利** **。** 病毒性是一种寓言性的品质,但是正如 WhatsApp 所显示的,如果您确实发现了,伙计,它值得很多钱。
* **价值和员工人数现已正式离婚** **。** 当今世界上有很多倍增力。 先进的全球电信基础设施使类似 WhatsApp 的应用成为可能。 如果 WhatsApp 必须建立网络或电话等,那将永远不会发生。 强大的廉价硬件和开放源代码软件的可用性当然是另一个倍数。 就像在正确的时间,正确的位置,正确的产品出现在正确的购买者面前一样。
* **这种对用户想法** **的残酷关注。** WhatsApp 专注于成为一个简单的消息传递应用程序,而不是游戏网络,广告网络或消失的照片网络。 那为他们工作。 它指导了他们的无广告立场,在添加功能时保持应用程序简单的能力,以及总体而言,它在任何手机上都可以正常工作。
* **简单原因的限制是可以的** **。** 您的身份与电话号码相关,因此,如果更改电话号码,则您的身份将消失。 这非常像计算机。 但这确实使整个系统的设计更加简单。
* **年龄不是没有** **。** 如果是年龄歧视导致 WhatsApp 联合创始人布莱恩·阿克顿(Brian Acton)在 2009 年无法在 Twitter 和 Facebook 上找到工作,那真可耻,可耻,可耻。
* **简单开始,然后自定义** **。** 最初启动聊天时,服务器端基于 ejabberd。 此后已被完全重写,但这是向 Erlang 方向迈出的第一步。 在最初的用例中,Erlang 的可伸缩性,可靠性和可操作性方面的经验导致了越来越广泛的使用。
* **保持服务器计数低** **。** 不断努力将服务器数量保持在尽可能低的水平,同时为产生短期使用高峰的事件留有足够的空间。 分析和优化,直到这些工作受到收益递减的影响,然后再部署更多硬件。
* **故意过度配置硬件。** 这可确保用户在庆祝活动期间获得不间断的服务,并且员工能够享受假期,而不必花费所有时间解决过载问题。
* **当您收取费用** **时,增长停滞。** 当免费使用 WhatsApp 时,增长非常快,早期每天有 10,000 次下载。 然后,当切换到付费时,每天的费用下降到 1,000。 到了年底,在添加了图片消息后,他们决定收取一次性的下载费用,后来又改为年度付款。
* **灵感来自最陌生的地方** **。** 忘记了 Skype 帐户上的用户名和密码的经验驱使人们使应用程序“正常运行”。
## 相关文章
* [关于黑客新闻](https://news.ycombinator.com/item?id=7306066)
* [主题演讲:Benedict Evans-InContext 2014](https://www.youtube.com/watch?v=VnhbvS0MBXE) (相关的 [幻灯片](http://ben-evans.com/presentations/2013/11/5/mobile-is-eating-the-world-autumn-2013-edition) )
* [Whatsapp 和 190 亿美元](http://ben-evans.com/benedictevans/2014/2/19/whatsapp-and-19bn) ,作者:Benedict Evans
* [WhatsApp 的博客:一家市值 160 亿美元的初创企业的精彩日记](http://www.slideshare.net/socialmarketingfella/the-diary-of-a-16-billion-startup-31457350) -Andre Bourque 的精彩活动时间表。
* Rick 在 GitHub 上对 [Erlang 的更改](https://github.com/reedr)
* [WhatsApp 博客](http://blog.whatsapp.com/) :
* [一百万!](http://blog.whatsapp.com/index.php/2011/09/one-million/) ( [Hacker News](https://news.ycombinator.com/item?id=3028547) )
* [一百万就是 2011 年](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/)
* [4 亿个故事](http://blog.whatsapp.com/index.php/2013/12/400-million-stories/)
* [WhatsApp:内幕](http://www.wired.co.uk/news/archive/2014-02/19/whatsapp-exclusive)
* [WhatsApp](http://www.whatsapp.com/opensource/) 使用的开源项目
* [Whatsapp,Facebook,Erlang 和实时消息传递:一切都始于 ejabberd](http://blog.process-one.net/whatsapp-facebook-erlang-and-realtime-messaging-it-all-started-with-ejabberd/)
* Quora: [WhatsApp 如何工作?](http://www.quora.com/How-does-WhatsApp-work-1) , [WhatsApp 如何在移动网络中工作?](http://www.quora.com/How-does-WhatsApp-work-out-of-mobile-network) , [WhatsApp 如何成长得如此之大?](http://www.quora.com/WhatsApp-Messenger/How-did-WhatsApp-grow-so-big)
* [WhatsApp 已损坏,实际上已损坏](http://fileperms.org/whatsapp-is-broken-really-broken/) -早期的安全问题
* [WhatsApp 首席执行官 Jan Koum Hates Advertising 和 Tech Rumor Mill(全潜视频)](http://allthingsd.com/20130510/whatsapp-ceo-jan-koum-hates-advertising-and-the-tech-rumor-mill-full-dive-video/)
* [新加坡正在逐步通过 WhatsApp 开展业务。 你是?](http://www.happymarketer.com/singapore-is-progressively-doing-business-over-whatsapp-are-you)
* [四个数字解释了 Facebook 为什么收购 WhatsApp](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired)
* [马克·扎克伯格的公告](https://www.facebook.com/zuck/posts/10101272463589561?stream_ref=10)
* [带有 Mochiweb 的百万用户彗星应用程序,第 3 部分](http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3)
* [Erlang 内部,WhatsApp 成功背后的罕见编程语言](http://www.fastcolabs.com/3026758/inside-erlang-the-rare-programming-language-behind-whatsapps-success)
* [Facebook 的扎克伯格说,WhatsApp 的价值实际上超过 19B 美元,并且是 Internet.org 达成了交易](http://techcrunch.com/2014/02/24/whatsapp-is-actually-worth-more-than-19b-says-facebooks-zuckerberg/)
* [Facebook 以 190 亿美元收购 Whatsapp:价值与定价观点](http://aswathdamodaran.blogspot.in/2014/02/facebook-buys-whatsapp-for-19-billion.html)
* [Facebook 的 190 亿美元渴望,马克·扎克伯格(Mark Zuckerberg)解释](http://www.forbes.com/sites/georgeanders/2014/02/19/facebook-justifies-19-billion-by-awe-at-whatsapp-growth/)
* [恕我直言:从 WhatsApp 汲取的教训](http://blog.mindcrime-ilab.de/2012/12/16/imho-lessons-learned-from-whatsapp/)
* [您可能不会使用 WhatsApp,但世界其他地区肯定会使用](http://www.wired.com/wiredenterprise/2014/02/whatsapp-rules-rest-world/)
* [WhatsApp 的故事挑战了山谷的一些传统智慧](http://techcrunch.com/2014/02/23/the-whatsapp-story-challenges-the-valleys-conventional-wisdom/)
* [根据 Jan Koum(视频)的说法,WhatsApp 做了正确的事](http://recode.net/2014/02/20/what-whatsapp-did-right-according-to-jan-koum-video/)
* [Facebook 为什么要购买 WhatsApp?](http://kottke.org/14/02/why-did-facebook-buy-whatsapp)
* [有人可以向我解释 WhatsApp 的估值吗?](http://www.linkedin.com/today/post/article/20140220134541-79695780-can-someone-explain-whatsapp-s-valuation-to-me)
* [Google 对 WhatsApp 的不寻常出价](https://www.theinformation.com/Google-s-Unusual-Offer-to-WhatsApp) 。
我理解正确吗? WS 正在一台唯一的服务器上运行? 真? 那简直是疯了,O_o 正常,它总是掉下来...
伊凡,你是怎么得出这个结论的?
是从哪儿说的?
> 数百个节点
> > 8000 个内核
> 数百兆字节的 RAM
谢谢! 这是我今年(2014 年)阅读的最好的,最有趣,最令人鼓舞和最具挑战性的文章之一。 我喜欢看到其他人所做的既平凡(或使复杂的平凡)又令人惊奇。 我的团队将继续使用 Java,但是看到另一个团队不仅在财务上如此成功,而且能够满足数亿用户的需求是令人鼓舞的。 太棒了! 谢谢!
800 万资金是错误的。 他们筹集了大约六千万。
yowsup 在这里可用:https://github.com/nprasan/yowsup
我赞同 Kevin 的评论-一篇非常出色的文章。 实际上在 1 篇文章中有 3 篇很棒的文章:移动应用程序市场分析,深入的技术探讨,一般课程。 非常感谢! 会在这里上班...
您说:“尽管就个人而言,所需的所有调优和修补工作都对该主张造成了一些怀疑。” 这种怀疑似乎基于 Erlang / OTP 静止不动的假设,而事实上一段时间前 WhatsApp 的 Erlang / OTP 补丁已被并入 Erlang / OTP 中。 Erlang / OTP 是开源的,社区补丁很常见,爱立信的 OTP 团队在社区的帮助下继续在功能,性能和可伸缩性方面推动平台向前发展。 我相信 WhatsApp 最初是在 Erlang / OTP 的 R14B 版本上开发补丁的,但是下个月(2014 年 3 月),OTP 团队将发布 17.0 版,再次达到了每年生产 Erlang / OTP 的新主要版本的正常时间表。
很棒的帖子!
时间过长
到目前为止,我几个月来读的最好的文章。
做得好,可扩展性高。
首先,很棒的文章。 whatsapp 的工程设计以及他们对细节的关注给我留下了深刻的印象。 拥有内部外观很酷。
但是,对于涉及“ 200 万个 TCP 连接”的测试,我感到困惑。 我不清楚这到底是什么意思。 我的理解是,无效的 TCP 连接理论上只需要 RAM,而对 CPU 或带宽的影响很小。
如果是这样,我很难怀疑该基准所达到的目标。 在大多数情况下,RAM 不是限制因素吗? 我不清楚 Erlang 在这里有什么特别的帮助,或者说 200 万个连接测试的实际含义是,CPU 和带宽是否应该处于闲置状态。 在演示文稿中,听起来好像 CPU 的使用率为 85%,但我不清楚 CPU 的实际功能。 谁能启发我?
优秀的文章。
谈到隐私,“邮件未存储在服务器上”
不对
至少,视频和 img 消息将发送到服务器,然后进行压缩,然后转发给您的联系人。
如果 whatsapp 在此之后将其删除,我相信这取决于 NSA。
很棒的文章! 感谢您分享。
优秀的文章...! 感谢分享。
绝对惊人的文章! 我喜欢它,每一行,每一句话!!!
伟大的伟大伟大的职位。 我在 2009 年从事类似项目的工作,我知道所有这些技术讲座,并且帖子中的细节非常详尽。 我非常感谢作为技术部分的商业观点和经验教训...很好的结论。
值得花时间阅读。 谢谢。
不要相信会告诉您的人会花费 30 台主机打开足够的 IP 端口来生成足够的连接来测试具有一百万个并发连接的服务器。 这是完全错误的,并且仅仅是对知识缺失的证明。 ;)
已收藏。 这是非常棒的信息,感谢您的分享,
由于不熟悉此类工程的尖端人员,这是一本有趣的文章。
谁能回答一个愚蠢的问题?
我很欣赏从单个服务器中获得如此高的效率必然需要大量的工作,这是一项巨大的成就,但是为什么这样的消息传递应用程序原则上会带来巨大的可扩展性挑战? 为什么最小数量的服务器很重要? 在我的手机上看到自己的小 WhatsApp 气泡时,我经常只与约 20 个人联系,很少能以每小时 4 个以上的速度进行完整的对话。
因此,如果我不得不从视觉上代表整个网络,我会猜想有很多自然的分区,而不是像 bittorrent 这样的大规模且不可预测的互连。 并不是说这将是一个小的编程任务,但是原则上,通用框架不能通过遵循然后预测用户的自然分区来将连接分配给服务器。 例如。 我和我的伦敦哥们都乱伦,与圣保罗的交通突然中断为零。
因此,一旦最佳地分配了连接,服务器之间的剩余最小流量就不会成为问题-尤其是当您看到我突然尝试与 Sao Paolo 进行实时聊天时,您将我们切换到同一台服务器进行一次 。
我不是在问为什么 WhatsApp 没有尝试构建这种复杂的东西,而是我是否对社交网络连接的预测分区的 Hadoop 需求未得到满足是正确的? (是的,我意识到这比 hadoop 要复杂得多)
当客户端收到消息后,消息将被删除,这听起来很完美,但是如果出现群发消息怎么办? 它会一直持续到小组的所有成员都收到吗?
不错的文章。 让您欣赏系统的复杂性,并像 Whatsapp 一样被我们视为日常用户。
嘿,这是很酷的文章。
我有一个问题,我还没有完全明白。 那么,客户端建立的每个套接字连接都将在一个单独的过程中结束吗? 如果是这样,那么服务器如何创建一百万个:/进程中的消息队列如何一次可能达到 20 万条消息?
谢谢
Facebook 没有购买 Whatsapp 的建筑,而是购买了 10 亿以上的昏迷用户
- LiveJournal 体系结构
- mixi.jp 体系结构
- 友谊建筑
- FeedBurner 体系结构
- GoogleTalk 架构
- ThemBid 架构
- 使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构
- TypePad 建筑
- 维基媒体架构
- Joost 网络架构
- 亚马逊建筑
- Fotolog 扩展成功的秘诀
- 普恩斯的教训-早期
- 论文:Wikipedia 的站点内部,配置,代码示例和管理问题
- 扩大早期创业规模
- Feedblendr 架构-使用 EC2 进行扩展
- Slashdot Architecture-互联网的老人如何学会扩展
- Flickr 架构
- Tailrank 架构-了解如何在整个徽标范围内跟踪模因
- Ruby on Rails 如何在 550k 网页浏览中幸存
- Mailinator 架构
- Rackspace 现在如何使用 MapReduce 和 Hadoop 查询 TB 的数据
- Yandex 架构
- YouTube 架构
- Skype 计划 PostgreSQL 扩展到 10 亿用户
- 易趣建筑
- FaceStat 的祸根与智慧赢得了胜利
- Flickr 的联合会:每天进行数十亿次查询
- EVE 在线架构
- Notify.me 体系结构-同步性
- Google 架构
- 第二人生架构-网格
- MySpace 体系结构
- 扩展 Digg 和其他 Web 应用程序
- Digg 建筑
- 在 Amazon EC2 中部署大规模基础架构的六个经验教训
- Wolfram | Alpha 建筑
- 为什么 Facebook,Digg 和 Twitter 很难扩展?
- 全球范围扩展的 10 个 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展
- 《 FarmVille》如何扩展以每月收获 7500 万玩家
- Twitter 计划分析 1000 亿条推文
- MySpace 如何与 100 万个并发用户一起测试其实时站点
- FarmVille 如何扩展-后续
- Justin.tv 的实时视频广播架构
- 策略:缓存 404 在服务器时间上节省了洋葱 66%
- Poppen.de 建筑
- MocoSpace Architecture-一个月有 30 亿个移动页面浏览量
- Sify.com 体系结构-每秒 3900 个请求的门户
- 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训
- Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长
- 扩展 BBC iPlayer 的 6 种策略
- Facebook 的新实时消息系统:HBase 每月可存储 135 亿条消息
- Pinboard.in Architecture-付费玩以保持系统小巧
- BankSimple 迷你架构-使用下一代工具链
- Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表
- Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件
- Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求
- Node.js 成为堆栈的一部分了吗? SimpleGeo 说是的。
- 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量
- Medialets 体系结构-击败艰巨的移动设备数据
- Facebook 的新实时分析系统:HBase 每天处理 200 亿个事件
- Microsoft Stack 是否杀死了 MySpace?
- Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰
- Facebook:用于扩展数十亿条消息的示例规范架构
- Evernote Architecture-每天有 900 万用户和 1.5 亿个请求
- TripAdvisor 的短
- TripAdvisor 架构-4,000 万访客,200M 动态页面浏览,30TB 数据
- ATMCash 利用虚拟化实现安全性-不变性和还原
- Google+是使用您也可以使用的工具构建的:闭包,Java Servlet,JavaScript,BigTable,Colossus,快速周转
- 新的文物建筑-每天收集 20 亿多个指标
- Peecho Architecture-鞋带上的可扩展性
- 标记式架构-扩展到 1 亿用户,1000 台服务器和 50 亿个页面视图
- 论文:Akamai 网络-70 个国家/地区的 61,000 台服务器,1,000 个网络
- 策略:在 S3 或 GitHub 上运行可扩展,可用且廉价的静态站点
- Pud 是反堆栈-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术
- StackExchange 体系结构更新-平稳运行,Amazon 4x 更昂贵
- DataSift 体系结构:每秒进行 120,000 条推文的实时数据挖掘
- Instagram 架构:1400 万用户,1 TB 的照片,数百个实例,数十种技术
- PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片
- Etsy Saga:从筒仓到开心到一个月的浏览量达到数十亿
- 数据范围项目-6PB 存储,500GBytes / sec 顺序 IO,20M IOPS,130TFlops
- 99designs 的设计-数以千万计的综合浏览量
- Tumblr Architecture-150 亿页面浏览量一个月,比 Twitter 更难扩展
- Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天对 2000 万张照片进行爬网,分析和排名
- LinkedIn:使用 Databus 创建低延迟更改数据捕获系统
- 在 30 分钟内进行 7 年的 YouTube 可扩展性课程
- YouPorn-每天定位 2 亿次观看
- Instagram 架构更新:Instagram 有何新功能?
- 搜索技术剖析:blekko 的 NoSQL 数据库
- Pinterest 体系结构更新-1800 万访问者,增长 10 倍,拥有 12 名员工,410 TB 数据
- 搜索技术剖析:使用组合器爬行
- iDoneThis-从头开始扩展基于电子邮件的应用程序
- StubHub 体系结构:全球最大的票务市场背后的惊人复杂性
- FictionPress:在网络上发布 600 万本小说
- Cinchcast 体系结构-每天产生 1,500 小时的音频
- 棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容
- 棱镜更新:基于文档和用户的机器学习
- Zoosk-实时通信背后的工程
- WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量
- 史诗般的 TripAdvisor 更新:为什么不在云上运行? 盛大的实验
- UltraDNS 如何处理数十万个区域和数千万条记录
- 更简单,更便宜,更快:Playtomic 从.NET 迁移到 Node 和 Heroku
- Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序
- BigData 使用 Erlang,C 和 Lisp 对抗移动数据海啸
- 分析数十亿笔信用卡交易并在云中提供低延迟的见解
- MongoDB 和 GridFS 用于内部和内部数据中心数据复制
- 每天处理 1 亿个像素-少量竞争会导致大规模问题
- DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长
- SongPop 在 GAE 上可扩展至 100 万活跃用户,表明 PaaS 未通过
- Iron.io 从 Ruby 迁移到 Go:减少了 28 台服务器并避免了巨大的 Clusterf ** ks
- 可汗学院支票簿每月在 GAE 上扩展至 600 万用户
- 在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段
- 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量
- Facebook 的网络秘密
- 神话:埃里克·布鲁尔(Eric Brewer)谈银行为什么不是碱-可用性就是收入
- 一千万个并发连接的秘密-内核是问题,而不是解决方案
- GOV.UK-不是你父亲的书库
- 缩放邮箱-在 6 周内从 0 到 100 万用户,每天 1 亿条消息
- 在 Yelp 上利用云计算-每月访问量为 1.02 亿,评论量为 3900 万
- 每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips
- Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户,300K QPS,22 MB / S Firehose 以及发送推文
- Salesforce Architecture-他们每天如何处理 13 亿笔交易
- 扩大流量的设计决策
- ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行
- 如何制作无限可扩展的关系数据库管理系统(RDBMS)
- Bazaarvoice 的架构每月发展到 500M 唯一用户
- HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息
- NYTimes 架构:无头,无主控,无单点故障
- 接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放,喜欢和更多内容
- Google 如何备份 Internet 和数十亿字节的其他数据
- 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧
- AOL.com 体系结构如何发展到 99.999%的可用性,每天 800 万的访问者和每秒 200,000 个请求
- Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 构建社交音乐服务
- 大,小,热还是冷-条带,Tapad,Etsy 和 Square 的健壮数据管道示例
- WhatsApp 如何每秒吸引近 5 亿用户,11,000 内核和 7,000 万条消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理
- 关于 Disqus 的更新:它仍然是实时的,但是 Go 摧毁了 Python
- 关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明
- 在 PagerDuty 迁移到 EC2 中的 XtraDB 群集
- 扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序
- 一点点:建立一个可处理每月 60 亿次点击的分布式系统的经验教训
- StackOverflow 更新:一个月有 5.6 亿次网页浏览,25 台服务器,而这一切都与性能有关
- Tumblr:哈希处理每秒 23,000 个博客请求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构
- MixRadio 体系结构-兼顾各种服务
- Twitter 如何使用 Redis 进行扩展-105TB RAM,39MM QPS,10,000 多个实例
- 正确处理事情:通过即时重放查看集中式系统与分散式系统
- Instagram 提高了其应用程序的性能。 这是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架构
- 英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大规模构建发布平台
- Aeron:我们真的需要另一个消息传递系统吗?
- 机器:惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化
- AWS 的惊人规模及其对云的未来意味着什么
- Vinted 体系结构:每天部署数百次,以保持繁忙的门户稳定
- 将 Kim Kardashian 扩展到 1 亿个页面
- HappyPancake:建立简单可扩展基金会的回顾
- 阿尔及利亚分布式搜索网络的体系结构
- AppLovin:通过每天处理 300 亿个请求向全球移动消费者进行营销
- Swiftype 如何以及为何从 EC2 迁移到真实硬件
- 我们如何扩展 VividCortex 的后端系统
- Appknox 架构-从 AWS 切换到 Google Cloud
- 阿尔及利亚通往全球 API 的愤怒之路
- 阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分
- 为社交产品设计后端
- 阿尔及利亚通往全球 API 第 3 部分的愤怒之路
- Google 如何创造只有他们才能创造的惊人的数据中心网络
- Autodesk 如何在 Mesos 上实施可扩展事件
- 构建全球分布式,关键任务应用程序:Trenches 部分的经验教训 1
- 构建全球分布式,关键任务应用程序:Trenches 第 2 部分的经验教训
- 需要物联网吗? 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式
- Uber 如何扩展其实时市场平台
- 优步变得非常规:使用司机电话作为备份数据中心
- 在不到五分钟的时间里,Facebook 如何告诉您的朋友您在灾难中很安全
- Zappos 的网站与 Amazon 集成后冻结了两年
- 为在现代时代构建可扩展的有状态服务提供依据
- 细分:使用 Docker,ECS 和 Terraform 重建基础架构
- 十年 IT 失败的五个教训
- Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售
- 整个 Netflix 堆栈的 360 度视图
- Wistia 如何每小时处理数百万个请求并处理丰富的视频分析
- Google 和 eBay 关于构建微服务生态系统的深刻教训
- 无服务器启动-服务器崩溃!
- 在 Amazon AWS 上扩展至 1100 万以上用户的入门指南
- 为 David Guetta 建立无限可扩展的在线录制活动
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿个通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训
- 缩放原理
- TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿条通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训