# Slashdot Architecture-互联网的老人如何学会扩展
> 原文: [http://highscalability.com/blog/2007/11/12/slashdot-architecture-how-the-old-man-of-the-internet-learne.html](http://highscalability.com/blog/2007/11/12/slashdot-architecture-how-the-old-man-of-the-internet-learne.html)
**Slashdot effect**: overwhelming unprepared sites with an avalanche of reader's clicks after being mentioned on Slashdot. Sure, we now have the "Digg effect" and other hot new stars, but Slashdot was the original. And like many stars from generations past, Slashdot plays the elder statesman's role with with class, dignity, and restraint. Yet with millions and millions of users Slashdot is still box office gold and more than keeps up with the young'ins. And with age comes the wisdom of learning how to handle all those users. Just how does Slashdot scale and what can you learn by going old school?
Site: http://slashdot.org
## 信息来源
* [Slashdot 的设置,第 1 部分-硬件](http://meta.slashdot.org/article.pl?sid=07/10/18/1641203&tid=124)
* [Slashdot 的设置,第 2 部分,软件](http://meta.slashdot.org/article.pl?sid=07/10/22/145209)
* [Slashdot 第 3 部分的历史-成为公司](http://meta.slashdot.org/article.pl?sid=07/10/17/1412245)
* [Slashdot 的历史第 4 部分-昨天,今天,明天](http://meta.slashdot.org/article.pl?sid=07/10/31/1631213)
## 该平台
* MySQL
* Linux(CentOS / RHEL)
* 磅
* Apache
* Perl
* 内存缓存
* LVS
## 统计资料
* 从 1999 年开始构建系统。
* 每月有 550 万用户访问。
* 每天增加 7,000 条评论。
* 每天的浏览量超过 900 万。
* 超过 2100 万条评论。
* 平均每月带宽使用量约为 40-50 兆位/秒。
* 对于同一故事[,Kottke.org](http://www.kottke.org/06/01/digg-vs-slashdot) 发现 Slashdot 交付的用户是 Digg 的 4 倍。 因此,Slashdot 还没有死。
* 摘自 **Slashdot 的历史第 4 部分**:*在[9 月 11 日],主流新闻网站陷入了困境,尽管我们不得不关闭日志记录功能,但我们还是设法保持运转,在一个站点中共享新闻。 通常很难获得的时间。 那一天,使该站点发生的工程师团队齐心协力,做了不可能的事情,迫使我们有限的小型硬件集群处理的流量可能是正常一天的三倍或四倍。*
## 硬件架构
* 数据中心的设计与所有其他 SourceForge,Inc.站点相似,并且已证明可以很好地扩展。
* 两个主动-主动千兆位上行链路。
* 一对 Cisco 7301 作为网关/边界路由器。 执行一些基本过滤。 过滤是分层的,以分散负载。
* 铸造厂 BigIron 8000 充当核心交换机/路由器。
* Foundry FastIron 9604s 用作某些机架的交换机。
* 一对可机架系统(1U; P4 Xeon 2.66Gz,2G RAM,2x80GB IDE,运行 CentOS 和 LVS)用作负载平衡防火墙,将流量分配到 Web 服务器。 [BIG-IP F5](http://www.f5.com/products/big-ip/) 正在其新数据中心中部署。
* 所有服务器均至少为 RAID1。
* 16 个 Web 服务器:
-运行 Red Hat9。
-带有 2 个 Xeon 2.66Ghz 处理器,2GB RAM 和 2x80GB IDE 硬盘的机架式 1U 服务器。
-两个提供静态内容:javascript,图像和非登录用户的首页。
-前四个页面用于登录用户
-10 个处理注释页面。
-主机角色根据负载而更改。
-所有 NFS 挂载均处于只读模式。
* NFS 服务器是具有 2 个 Xeon 2.4Ghz 处理器,2GB RAM 和 4x36GB 15K RPM SCSI 驱动器的 Rackable 2U。
* 7 个数据库服务器:
-全部运行 CentOS4。
-2 个在主-主配置中:
-具有 16GB RAM,4x36GB 15K RPM SCSI 的 Dual Opteron 270,
-一个主服务器 只写数据库。
-一个主数据库是只读数据库。
-他们可以随时进行故障转移并切换角色。
-2 个读取器数据库:
-具有 8GB RAM,4x36GB 15K RPM SCSI 驱动器
的 Dual Opteron 270,每个数据库均从一个主数据库进行同步。
-可以增加更多规模,但目前足够快。
-3 个其他数据库
-具有 4GB RAM,8x36GB 10K RPM SCSI 驱动器的 Quad P3 Xeon 700Mhz
-Accesslog 写入器和 accesslog 读取器。 使用单独的数据库是因为审核和统计信息需要大量的 CPU 时间进行计算。
-搜索数据库。
## 软件架构
* 已登录用户和未登录用户的处理方式有所不同。
-未登录的用户将看到同一页面。 此页面是静态页面,每两分钟更新一次。
-登录的用户具有无法缓存的自定义选项,因此为这些用户生成页面会占用更多资源。
* 6 磅服务器(对于 SSL 为 1 磅)用作反向代理:
-如果无法处理请求,则将其转发到 Web 服务器。
-磅服务器与 Web 服务器在同一台计算机上运行。
-分发它们是为了实现负载平衡和冗余。
-SSL 由磅服务器处理,因此 Web 服务器不需要支持 SSL。
* 16 个 apache Web 服务器(1.3 版):
-从/ usr / local 挂载软件到只读 NFS 服务器上。
-图像保持简单。 编译的全部内容是:
-mod_perl
-挥之不去地在交付过程中释放了 RAM。
-mod_auth_useragent 阻止机器人。
-1 用于 SSL。
-2 用于静态(.shtml)请求。
-4 为动态首页。
-6 个用于动态评论传递页面(评论,文章,pollBooth.pl)。
-3 用于所有其他动态脚本(ajax,标签,书签,firehose)。
* 将 apache 服务器划分为不同角色的原因:
-隔离服务器,以防在特定页面上出现性能问题或 DDoS 攻击。 即使一部分出现故障,系统的其余部分也将起作用。
-由于效率原因,例如 httpd 级别的缓存和 MaxClients 调整。 可以针对每个角色对 Web 服务器进行不同的调整。 对于动态 Web 服务器,MaxClients 设置为 5-15,对于静态服务器,MaxClients 设置为 25。 瓶颈是 CPU,而不是 RAM,因此,如果不能快速处理请求,那么出了点问题,排队更多的请求将无法帮助 CPU 更快地处理它们。
* 使用只读安装有助于提高系统的稳定性。 写入/ usr / local 的任务(例如,每秒更新 index.html)在 NFS 服务器上运行。
* 使用在 DBD :: mysql 和 DBI.pm 之上构建的自己的 SQL API。
* 通过使用 memcached 缓存用户,故事和评论文本,极大地提高了性能。
* 大多数数据访问是通过为每种数据类型定制的 get 和 set 方法以及执行一个特定更新或选择的方法进行的。
* 多主复制体系结构即使在阻止查询(如 ALTER TABLE)期间也可以保持站点完全正常运行。
* [多遍日志处理](http://slashdot.org/journal.pl?op=display&nick=jamie&uid=78724&id=93006&)用于检测滥用情况并挑选哪些用户获得了 Mod 积分。
* 创建了针对垃圾邮件的审核系统。 起初只是几个朋友,然后是很多朋友。 这没有扩展。 因此,引入了“ mod points”系统,以便对系统做出贡献的任何用户都可以审核该系统。
* 禁止活动用户防止机器人过度使用。
## 得到教训
* 最富创造力的时期是资金紧缺,团队规模很小,每个人都在帮助其他人做任何需要做的事情。
* 不要浪费时间优化代码,因为您太便宜了,无法购买更多机器。 购买硬件并花时间在功能上。
* 卖给一家大公司,您将失去控制。 不断面临着去开发新产品,融合广告商提供的内容以及投放大型广告的阴暗面的压力。
* 对希望您变得像其他所有人一样的力量说不。 尽管许多竞争对手来来去去,但 Slashdot 仍然存在,因为他们:*继续保持编辑独立性,适度的广告数量,广告和内容之间有明显的区别,当然,我们继续选择合适的故事来吸引人们 给我们现有的听众...不要花我们的时间去吸引其他听众,这些听众只会淡化讨论,从而使日复一日的你们中的许多人到来。*
* 将服务器隔离到不同的策略域中,以便您可以优化它们的配置。
* 优化通常意味着缓存,缓存,缓存。
* 表不完整,但大多已归一化。 在大多数情况下,这可以提高性能。
* 在过去的七年中,开发数据库支持的网站的过程发生了变化:*数据库曾经是瓶颈:集中化,难以扩展,运行缓慢。 现在,如果您进行防御性编码,那么即使是便宜的 DB 服务器也可以运行一个相当大的站点,并且由于摩尔定律,内存缓存和开源数据库软件的改进,在您不进行扩展的情况下,扩展问题才真正成为问题。 实际上是 eBay 的大小。 这是编写 Web 应用程序的激动人心的时刻。*
“对于动态 Web 服务器,MaxClients 设置为 5-15,对于静态服务器,MaxClients 设置为 25。”
只有 15 点? 我们在每个 Apache 上有 256 个(1u 服务器 2xOpteron 双核 4GB RAM),并使用 PHP 提供 9-10 倍的页面
取决于 apache 进程在做什么。例如,它们可以等待 SQl 结果。因此,最好等待更多的进程。 他们也在等待客户端获取所有发送的数据-速度较慢的客户端,需要更多进程来保持 CPU 利用率。
但是 AFAIK slashdot 使用的是反向代理,到 apache 仅以全 CPU 速度运行 PHP 代码,并立即将数据返回给代理。 代理然后等待慢速客户端...
Slashdot 不使用 PHP,而是使用 mod_perl。
他们如何将 NFS 只读安装在 Web 服务器上并仍然写入其中? 他们是否首先从 Web 服务器到 NFS 服务器使用 ssh?
谢谢,
- 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 内容平台的经验教训