# Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
> 原文: [http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html)
![](https://img.kancloud.cn/58/da/58da2ec570db09352a89662fec52606e_215x215.png)
如果您是 Uber,并且需要存储驾驶员和骑乘者应用程序每 30 秒发送一次的位置数据,该怎么办? 大量实时数据需要实时使用。
Uber 的解决方案是全面的。 他们构建了自己的系统,该系统在 Mesos 之上运行 Cassandra。 Uber 的软件工程师 [Abhishek Verma](https://www.linkedin.com/in/verma7) 在一个很好的演讲中都做了解释: [Cassandra 在多个数据中心的 Mesos 上 Uber](https://www.youtube.com/watch?v=4Ap-1VT2ChU&feature=youtu.be) ( [幻灯片](http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016) )。
您也应该这样做吗? 在听 Abhishek 的演讲时,会想到一个有趣的想法。
这些天来,开发人员有很多困难的选择。 我们应该全力以赴吗? 哪一个? 太贵了吗? 我们担心锁定吗? 还是我们应该尝试同时兼顾并打造混合架构? 还是我们应该自己做所有事情,以免由于未达到 [50%](http://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/) 毛利率而被董事会蒙羞?
Uber 决定建立自己的公司。 或者更确切地说,他们决定将两个功能强大的开源组件融合在一起,从而将自己的系统焊接在一起。 所需要的是一种使 Cassandra 和 Mesos 协同工作的方法,而这正是 Uber 的基础。
对于 Uber 的决定并不那么困难。 他们资金充裕,可以访问创建,维护和更新这类复杂系统所需的顶尖人才和资源。
由于 Uber 的目标是使运输在每个地方的每个人都具有 99.99%的可用性,因此在扩展到无限远及更高水平时,希望能够控制您的成本确实很有意义。
但是,当您听演讲时,您会意识到制作此类系统所付出的巨大努力。 这真的是您的普通商店可以做的事情吗? 不,不是。 如果您是那些希望每个人都在裸露的金属之上构建自己的所有代码的云专家之一,请记住这一点。
以金钱换时间通常很划算。 通常,以技能交易金钱是绝对必要的。
鉴于 Uber 的可靠性目标,即 10,000 个请求中只有一个可能失败,因此他们需要在多个数据中心中用完。 由于 Cassandra 被证明可以处理巨大的负载并且可以跨数据中心工作,因此作为数据库选择是有道理的。
如果您想使所有人,任何地方的运输都可靠,则需要有效地利用您的资源。 这就是使用像 Mesos 这样的数据中心操作系统的想法。 通过在同一台计算机上统计复用服务,您需要的计算机数量减少了 30%,从而节省了资金。 之所以选择 Mesos,是因为当时 Mesos 是经证明可与数以万计的计算机集群大小一起工作的唯一产品,这是 Uber 的要求。 优步的工作量很大。
有哪些更有趣的发现?
* 您可以在容器中运行有状态服务。 Uber 发现在裸机上运行 Cassandra 与在 Mesos 管理的容器中运行 Cassandra 之间几乎没有任何区别,开销为 5-10%。
* 性能良好:平均读取延迟:13 毫秒,写入延迟:25 毫秒,P99 看起来不错。
* 对于最大的群集,他们能够支持超过一百万次写入/秒和约 10 万次读取/秒。
* 敏捷性比性能更重要。 通过这种架构,Uber 获得的就是敏捷性。 跨集群创建和运行工作负载非常容易。
这是我的演讲要点:
## 开头
* 跨不同服务的静态分区计算机。
* 50 台机器可能专用于 API,50 台机器专用于存储,等等,并且它们没有重叠。
## 即时
* 希望在 [Mesos](http://mesos.apache.org/) 上运行所有内容,包括诸如 Cassandra 和 Kafka 之类的有状态服务。
* Mesos 是数据中心操作系统,可让您像单一资源池一样针对数据中心进行编程。
* 当时,事实证明 Mesos 可以在成千上万的计算机上运行,这是 Uber 的要求之一,因此这就是为什么他们选择 Mesos。 今天,Kubernetes 可能也可以工作。
* Uber 在 MySQL 之上构建了自己的分片数据库,称为 [Schemaless](https://eng.uber.com/schemaless-part-one/) 。 这个想法是 Cassandra 和 Schemaless 将成为 Uber 中的两个数据存储选项。 现有的 Riak 装置将移至 Cassandra。
* 一台机器可以运行各种服务。
* 同一台机器上的统计复用服务可能会导致 的机器数量减少 30% 。 这是 Google 在 Borg 上运行的 [实验](http://research.google.com/pubs/pub43438.html) 的发现。
* 例如,如果一项服务使用大量 CPU,并且与使用大量存储或内存的服务非常匹配,那么这两项服务可以有效地在同一服务器上运行。 机器利用率上升。
* Uber 现在有大约 20 个 Cassandra 集群,并计划在将来有 100 个。
* 敏捷性比性能更重要。 您需要能够管理这些集群并以平滑的方式对其执行不同的操作。
* **为什么在容器中而不是在整个机器上运行 Cassandra?**
* 您想存储数百 GB 的数据,但您还希望将其复制到多台计算机上以及跨数据中心。
* 您还希望跨不同群集进行资源隔离和性能隔离。
* 很难在一个共享群集中获得所有这些。 例如,如果您制作了一个 1000 节点的 Cassandra 群集,它将无法扩展,或者跨不同群集也会产生性能干扰。
## 量产中
* 在两个数据中心(西海岸和东海岸)中复制约 20 个群集
* 最初有 4 个集群,包括中国,但是由于与滴滴合并,这些集群被关闭了。
* 跨两个数据中心的 300 台机器
* 最大的 2 个集群:每秒超过 100 万次写入和每秒 10 万次读取
* 群集之一正在存储驾驶员和骑乘者应用程序每 30 秒发送一次的位置。
* 平均读取延迟:13 毫秒,写入延迟:25 毫秒
* 通常使用 [LOCAL_QUORUM](https://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html) 一致性级别(表示强一致性)
## 月背景资料
* Mesos 将 CPU,内存和存储从计算机中分离出来。
* 您不是在查看单个计算机,而是在查看资源并对其进行编程。
* 线性可伸缩性。 可以在数以万计的计算机上运行。
* 高度可用。 Zookeeper 用于在可配置数量的副本中进行领导者选举。
* 可以启动 Docker 容器或 Mesos 容器。
* 可插拔资源隔离。 用于 Linux 的 Cgroups 内存和 CPU 隔离器。 有一个 Posix 隔离器。 不同的操作系统有不同的隔离机制。
* 两级调度程序。 来自 Mesos 代理的资源被提供给不同的框架。 框架在这些提议的基础上安排自己的任务。
## Apache Cassandra Backgrounder
* Cassandra 非常适合 Uber 的用例。
* 水平可扩展。 随着新节点的添加,读写规模呈线性增长。
* 高度可用。 具有可调一致性级别的容错能力。
* 低延迟。 在同一数据中心内获得亚毫秒级的延迟。
* 操作简单。 这是同质的簇。 没有主人。 集群中没有特殊的节点。
* 足够丰富的数据模型。 它具有列,组合键,计数器,二级索引等
* 与开源软件的良好集成。 Hadoop,Spark,Hive 都具有与 Cassandra 进行通信的连接器。
## 中层+ Uber + Cassandra = dcos-cassandra-service
* Uber 与 Mesosphere 合作生产了 [mesosphere / dcos-cassandra-service](https://github.com/mesosphere/dcos-cassandra-service) -一种自动化服务,可轻松在 Mesosphere DC /上进行部署和管理 操作系统。
![29683333130_0478a29f4f.jpg](https://img.kancloud.cn/e5/cc/e5ccceded6d1dad19d6629eceb4868b3_500x361.png)
* 顶部是 Web 界面或 Control Plane API。 您指定所需的节点数; 您想要多少个 CPU; 指定 Cassandra 配置; 然后将其提交给 Control Plane API。
* 使用 Uber 的部署系统,它在 [Aurora](http://aurora.apache.org/) 之上启动,用于运行无状态服务,用于引导 dcos-cassandra 服务框架。
* 在示例 dcos-cassandra-service 框架中有两个与 Mesos 主服务器通信的集群。 Uber 在其系统中使用了五个 Mesos 母版。 Zookeeper 用于领导者选举。
* Zookeeper 还用于存储框架元数据:正在运行的任务,Cassandra 配置,集群的运行状况等。
* Mesos 代理在群集中的每台计算机上运行。 代理将资源提供给 Mesos 主服务器,主服务器以离散报价分发它们。 报价可以被框架接受或拒绝。 多个 Cassandra 节点可以在同一台计算机上运行。
* 使用 Mesos 容器,而不是 Docker。
* 覆盖配置中的 5 个端口(storage_port,ssl_storage_port,native_transport_port,rpcs_port,jmx_port),以便可以在同一台计算机上运行多个容器。
* 使用永久卷,因此数据存储在沙箱目录外部。 万一 Cassandra 失败,数据仍将保留在持久卷中,并且如果崩溃并重新启动,则将数据提供给同一任务。
* 动态预留用于确保资源可用于重新启动失败的任务。
* Cassandra 服务操作
* Cassandra 有一个 [种子节点](https://www.quora.com/What-is-a-seed-node-in-Apache-Cassandra) 的想法,它为加入集群的新节点引导八卦过程。 创建了自定义 [种子提供程序](https://mesosphere.github.io/cassandra-mesos/docs/configuration-and-state.html) 来启动 Cassandra 节点,该节点允许 Cassandra 节点自动在 Mesos 群集中推出。
* 可以使用 REST 请求增加 Cassandra 群集中的节点数。 它将启动其他节点,为其提供种子节点,并引导其他 Cassandra 守护程序。
* 可以更改所有 Cassandra 配置参数。
* 使用 API可以替换死节点。
* 需要修复才能跨副本同步数据。 维修在每个节点的主键范围内进行。 这种方法不会影响性能。
* 清除将删除不需要的数据。 如果已添加节点,则数据将被移动到新节点,因此需要清除以删除移动的数据。
* 可以通过框架配置多数据中心复制。
* 多数据中心支持
* 在每个数据中心中独立安装 Mesos。
* 在每个数据中心中设置框架的独立实例。
* 框架互相交谈并定期交换种子。
* 这就是 Cassandra 所需要的。 通过引导其他数据中心的种子,节点可以八卦拓扑并找出节点是什么。
* 数据中心之间的往返 ping 延迟为 77.8 ms。
* P50 的异步复制延迟:44.69 毫秒; P95:46.38ms; P99:47.44 毫秒;
* 计划程序执行
* 调度程序的执行被抽象为计划,阶段和块。 调度计划具有不同的阶段,一个阶段具有多个块。
* 调度程序启动时要经过的第一阶段是协调。 它将发送给 Mesos 并确定已经在运行什么。
* 有一个部署阶段,检查集群中是否已存在配置中的节点数,并在必要时进行部署。
* 块似乎是 Cassandra 节点规范。
* 还有其他阶段:备份,还原,清理和修复,具体取决于所命中的 REST 端点。
* 集群可以每分钟一个新节点的速率启动。
* 希望每个节点的启动时间达到 30 /秒。
* 在 Cassandra 中不能同时启动多个节点。
* 通常给每个 Mesos 节点 2TB 的磁盘空间和 128GB 的 RAM。 每个容器分配 100GB,每个 Cassandra 进程分配 32GB 堆。 (注意:目前尚不清楚,因此可能有错误的细节)
* 使用 G1 垃圾收集器代替 CMS,它具有更好的 99.9%延迟(16x)和性能,无需任何调整。
## 裸机 vs Mesos 托管群集
* 使用容器的性能开销是多少? 裸机意味着 Cassandra 不在容器中运行。
* 读取延迟。 几乎没有什么区别:5-10%的开销。
* 在裸机上平均为 0.38 ms,而在 Mesos 上为.44 ms。
* 在 P99 上,裸机为 0.91 毫秒,在 Mesos 上,P99 为 0.98 毫秒。
* 读取吞吐量。 差别很小。
* 写入延迟。
* 在裸机上平均为 0.43 ms,而在 Mesos 上为.48 ms。
* 在 P99 上,裸机为 1.05 毫秒,在 Mesos 上,P99 为 1.26 毫秒。
* 写入吞吐量。 差别很小。
## 相关文章
* [关于 HackerNews](https://news.ycombinator.com/item?id=12600298)
* [使用 Borg 在 Google 进行大规模集群管理](http://research.google.com/pubs/pub43438.html)
* [Google 的三个时代-批处理,仓库,即时](http://highscalability.com/blog/2011/8/29/the-three-ages-of-google-batch-warehouse-instant.html)
* [Google On Latency Tolerant Systems:由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html)
* [Google:驯服长时间延迟的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html)
* [Google 从单一数据中心到故障转移,再到本地多宿主体系结构的过渡](http://highscalability.com/blog/2016/2/23/googles-transition-from-single-datacenter-to-failover-to-a-n.html)
* [Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html)
* [Uber 变得与众不同:使用驾驶员电话作为备份数据中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html)
* [为在现代时代构建可扩展的有状态服务提供依据](http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html)
* [我也想运行有状态容器](https://techcrunch.com/2015/11/21/i-want-to-run-stateful-containers-too/)
* [Uber 工程技术堆栈,第一部分:基础](https://eng.uber.com/tech-stack-part-one/)
* [Uber,Twitter,PayPal 和 Hubspot 使用 Apache Mesos 的 4 种独特方式](https://www.linux.com/news/4-unique-ways-uber-twitter-paypal-and-hubspot-use-apache-mesos)
链接到代码:https://github.com/mesosphere/dcos-cassandra-service
顺便说一句,在文章中有一个链接。
有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。
我认为 ELK 不能跟上步伐。
@bob。 Uber 确实使用 ELK 进行记录。 它具有最大的 ELK 日志搜索安装之一。
我想知道他们是否正在使用 Mesos 卷进行持久数据存储。
是的,我们正在使用持久卷(https://mesos.apache.org/documentation/latest/persistent-volume/)进行数据存储。
你好
您能否阐明查询的性质?
聚合或联接或基于纬度的查询?
是否想知道 solr 是否可以根据您的用例进行选择?
> >有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。
如今,许多人用来实现此目的的一种模式是使用 kafka 日志记录库,该库挂接到其微服务中,并使用 spark 等将来自 Kafka 的日志消耗到 elasticsearch 中。 我们在一个很小的〜8 节点 ES 集群上每秒处理数十万个事件。
-SRE @ Orchard 平台
您能否分享 DC 之间的延迟时间?
Uber 使用 DC / OS 很有意思,但选择使用 Aurora 而非马拉松。 我上一次看极光时(大约 18 到 24 个月前),它的发展程度不及马拉松。 我想知道何时做出决定? Aurora 文档得到了很大的改进。
很棒的帖子! 使用 Mesos 代替 Hadoop YARN 是否有任何特殊原因? Mesos 是否更适合您的需求?
YARN 只能运行 Hadoop 工作负载 Mesos 允许您运行任何类型的工作负载。
谢谢您,先生,非常有信息。
Mesos 是否可以在没有 Docker 容器的情况下运行以安装 Cassandra?
我们可以使用 Mesos 默认容器安装 cassandra 吗?
很棒的翔实文章。 做得好!
怎么可能有 100 万次写入但每秒 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 内容平台的经验教训