# 正确处理事情:通过即时重放查看集中式系统与分散式系统
> 原文: [http://highscalability.com/blog/2014/9/15/getting-things-right-a-look-at-centralized-vs-decentralized.html](http://highscalability.com/blog/2014/9/15/getting-things-right-a-look-at-centralized-vs-decentralized.html)
*三个棒球裁判坐在酒吧周围,谈论他们如何在每个球场上打电话:第一裁判:有些是球,有些是打击,我将它们原样称呼。 第二位裁判:有些是球,有些是罢工,我称它们为“ em”。 第三次裁判:有些是球,有些是罢工,但直到我叫“ em”,它们才算是什么。*
| ![](https://img.kancloud.cn/e1/4d/e14d80bf885a2e8d8a8884a756a023f5_240x160.png)
AT&T's Global [Network Operations Center](http://www.nj.com/business/index.ssf/2011/08/att_gnoc_earthquake.html) | ![](https://img.kancloud.cn/3c/05/3c05552cbfa8f9d7ee303044dcd6f62b_240x124.png)
MLB 的[即时重播掩体](http://sports.yahoo.com/news/inside-look-at-mlb-s-new-instant-replay-bunker-032951044.html) | ![](https://img.kancloud.cn/70/cc/70cc94b6bd9239346487c54999feebf2_240x135.png)
NHL 的[情况室](http://blogs.canoe.ca/krykslants/nfl/special-report-inside-the-nhls-central-video-review-operation-can-it-work-in-the-nfl-with-tweaks-it-sure-can/) |
**更新**:[在 NFL 重放命令中心内](http://mmqb.si.com/2014/11/11/inside-the-nfls-replay-command-center/)
看一下我们认为主要属于计算机科学领域的概念在其他领域如何发挥作用很有趣。 一个有趣的例子是 [Instant Repla](http://en.wikipedia.org/wiki/Instant_replay) y 如何通过实现重播来反映甚至帮助[塑造](http://www.nfl.com/videos/nfl-network-top-ten/09000d5d811133e8/Top-Ten-Things-that-Changed-the-Game-Instant-replay)体育文化:[去中心化](http://en.wikipedia.org/wiki/Distributed_computing)或[集中化](http://en.wikipedia.org/wiki/Centralized_computing)。
有利可图的电视交易为专业体育运动注入了大量资金。 有了这么多钱,体育运动已经从纯粹的娱乐变成了**使事情变得正确**。 打个坏电话的代价太高了,无法让人为因素决定泰坦的命运。
正确处理事情也是计算机科学领域的热门话题。 在 CS 中,正确处理语言使用诸如事务,回滚,仲裁,乐观复制,线性化,同步,锁定,最终一致,补偿事务等术语。
在体育界为了使事情变得正确,裁判员使用诸如举旗,罚则,规则,裁决立场,重设时钟,向下和距离,取得线,吹哨,确认裁决以及推翻裁决等术语。
尽管词汇不同,但意图却是相同的。 正确性。
目的并非所有技术和体育都有共同点。 随着技术的发展,我们看到体育运动正在发生变化,以利用技术所提供的新功能。 这些变化应该是软件中任何人都熟悉的。 体育已经从完全分散的司法体制转变为现在我们看到的 [NBA](http://www.si.com/nba/point-forward/2014/05/18/nba-instant-replay-off-site-review-adam-silver) , [NFL](http://espn.go.com/nfl/story/_/id/10670707/nfl-owners-allow-centralized-system-aid-instant-replay) , [MLB](http://sports.yahoo.com/news/inside-look-at-mlb-s-new-instant-replay-bunker-032951044.html) 和 [NHL](http://blogs.canoe.ca/krykslants/nfl/special-report-inside-the-nhls-central-video-review-operation-can-it-work-in-the-nfl-with-tweaks-it-sure-can/) , 融合到某种形式的集中式系统上。
NHL 是创新者,于 2011 年启动了他们的集中式即时重放系统。它的工作原理类似于...官员坐在位于多伦多的作战室中,该作战室看起来非常类似于曾经建立的每个[网络运营中心](http://en.wikipedia.org/wiki/Network_operations_center)。 所有游戏的视频源都流进了房间。 如果存在争议或明显值得回顾的游戏,则会与多伦多联系,以对正确的电话进行快速回顾和判断。 每个运动都会以自己的方式实现自己的集中式重播系统,但这就是要旨。
我们已经看到了完全相同的转变,例如电子邮件之类的联合服务已被 Twitter 和 Facebook 等集中式服务所取代。 事实证明,体育和计算机科学具有更深的相似之处。 那可能是什么?
## 发明了即时重播功能,以正确处理事情
多年来,正确处理事情一直在发展。 首先,您需要一套规则。 没有规则,就不可能把事情做好。 使用一套适当的规则,游戏可以属于以下几类之一:自引游戏,无引荐游戏或引荐游戏。
**无裁判游戏**的示例在 [Outlander 电视节目](http://www.imdb.com/title/tt3006802/)的一集中进行了描绘,该剧集主要设置于 18 世纪。 它有一个很棒的场景,显示正在玩的游戏看起来像是苏格兰风格的曲棍球。 两支球队用大棒子打了一个球。 到目前为止还很熟悉。 然而不久之后,这些棍子就被用作武器,并且球员们到处互相棍打。 它造就了一场血腥的好游戏,但并没有过多地强调正确的事情。 变得...是的。
**休闲游戏**是一种玩足球,篮球或其他类型的接力游戏的聚会,它遵循一组规则,但通常都是自参考的。 没有裁判可以打电话。 游戏不是那么重要。 玩家会自称犯规,或者对方会称对方为犯规,但这都是非常非正式的,可能导致激烈的分歧。
## 游戏是去中心化且无锁的
在游戏发展的这一点上,游戏完全**去中心化**。 游戏彼此完全独立。 可以同时玩任何数量的游戏。 您需要的是足够的玩家和一个玩耍的地方。
还要注意,游戏是**无锁**,完全没有任何形式的货币控制。 场上的所有活动并行进行,场上的游戏状态是场上发生的一切。
对于无裁判员比赛,事后无法修复违反规则的情况。 对于自引游戏,修复违反规则的能力很有限。 部分原因是休闲游戏的规则不够详尽,部分原因是没有人玩游戏会接受其他玩家的这种判断。
## 最终推荐的游戏是一致的
这在游戏中发挥了客观的第三方裁判的作用。 或称他们为[裁判](http://en.wikipedia.org/wiki/Referee)。 裁判员可以制定更加详尽的规则集,因为只有专业人士才能了解所有规则并具有运用规则的技能。
在游戏中增加独立裁判员也可以使事情变得更加微妙,从某种意义上说,所有值最终都收敛于正确的值,这使得游戏成为[最终保持一致](http://en.wikipedia.org/wiki/Eventual_consistency)。 这是考虑引荐游戏的有趣方式。
游戏状态是上述值,可以通过在场上的游戏进行修改,但是可以说,这些更改不是已提交的事务。 裁判员可以使用相当于[补偿交易](http://en.wikipedia.org/wiki/Compensating_transaction)的补偿来弥补可能的违规行为,从而可能改变比赛状态。
例如,在 NFL 中,裁判决定球的放置位置,时间,得分,顺序以及通常在球场上发生的所有其他事情。 裁判需要告诉您比赛中实际发生的事情,他们需要确定认可系统中的可见性的东西。
思考裁判的另一种方法是,它们充当[寻求原谅编程](http://highscalability.com/blog/2012/3/6/ask-for-forgiveness-programming-or-how-well-program-1000-cor.html)中描述的**读取和修复**机制。 这篇文章展示了我们如何有效地对具有 1000 多个内核的处理器进行编程。 这个想法是让所有这些内核同时,并行运行,然后通过后台任务不断使答案更接近正确性,这些任务负责找出问题所在并进行调整。
这听起来不像游戏在肉类世界中的运作方式明显吗? 在游戏中,每个实体(球员,教练,裁判员,摄像机等)都是网络中连接的核心。 消息是通过手势或无线电信号进行的口头表达。 播放映射到协议。
在游戏中,由于实体的动作,状态在核心之间流动。 一些活动直接关联。 有些是间接链接的。 有些是独立的。
参加复杂的 NFL 比赛。 放一个球(或者是什么?),有一个拦截(在那里?),然后将球弄乱了(或者是吗?),又有一个忽悠了(或者在那里?),有人捡起球并跑了 在 TD。 最重要的是,该剧在该领域的完全不同的部分上有两个标志。
剧中到底发生了什么?
为了决定裁判们是否达到法定人数。 在解决冲突会议之后,这可能根本不会花费时间,也可能永远不会消失,裁判将得出结论。 裁判本质上是在阅读他们头脑中的“日志”中的事件,确定顺序,将事件与规则进行比较,确定哪些规则适用,哪些规则优先,然后确定正式发生了什么。
一旦确定,新游戏状态即已提交。 将通过补偿交易进行必要的维修。 可能会标出 15 码的罚款。 也许已经宣布了一个转身,球现在属于另一支球队。 裁判可以断定数百种潜在结果。 裁判说的是法律。
注意,像软件一样,正确性的代价是增加了延迟。 无裁判系统的延迟时间最短,因为比赛结束后,比赛不会停止,无法解决问题。 有了裁判,潜伏期有了巨大的飞跃。 决定处罚并实施任何更正需要大量时间。
裁判说的是真的吗? 这是一个关于“真相”的深刻问题,我们将完全忽略。 任何球迷当然不会告诉你的。 裁判一直吹牛。 但这没关系。 在游戏中(例如在数据库中),在解决冲突后,合并结果变为新状态。 没有更高的权威。
## 视频创建了可以挑战的共享内存日志
可是等等。 NFL 已经开发了一种**质询机制**,因此可以在事后查看通话。 教练发出红旗,并且将再次检查最后一次提交的事务,以查看是否犯了错误。 其他运动也有类似的机制。
挑战系统是**技术创新**的结果。 录制了游戏之后,就可以记录下来并在以后重播。 视频在时空上扩展并解耦了事件的“日志”。 在太空中,因为可以观看比赛的角度数量仅受摄像机数量的限制。 及时播放,因为可以在慢动作中实时或实时查看播放。
有了这个新工具,裁判员可以在几十年前完成几乎无法想象的事情,他们可以在一场比赛结束后再看一眼。 即时重播诞生了!
如果裁判在看比赛时发现打错了电话,他们将发出更多命令以纠正引起的任何问题,从而使比赛进入更加正确和一致的状态。 使用**读取修复**并补偿事务以解决问题的一个好例子。
重播后更改游戏状态就像 Amazon 出售系统认为可用但实际上缺货的商品一样。 如果您购买了缺货商品,世界会终结吗? 一点也不。 亚马逊会礼貌地通知您,该产品不再可用,您的订单已撤消。 对于亚马逊而言,获得销售要比每次犯错和改正错误更有利可图。 在比赛结束后,让比赛实时展开在场上也是值得的。
通常情况下,裁判员发出的用于解决先前问题的命令本身不可审查。 尽管许多体育运动都有一个上诉程序,联盟办公室可以先看电话然后说是,但裁判员犯了错,但是我们对此无能为力。 有时,极少数情况下,挑战会导致游戏从错误通话的角度重新开始。
在抗议之后,旧金山巨人队和芝加哥小熊队之间的最近一场比赛重新开始[。 这场比赛是在小熊队主场进行的,由于场地上的一些设备问题而被称为。 巨人当时正在输球,所以对他们来说这将是巨大的损失。 巨人上诉。 并荣获。 装备问题会给主队带来不当的胜利,这种力量被认为是不公平的。](http://espn.go.com/chicago/mlb/story/_/id/11384538/san-francisco-giants-win-appeal-finish-game-vs-chicago-cubs)
**正义不是上诉系统**的目标。 玩完游戏后很少能解决问题。 可能会发送道歉信。 也许规则委员会将在明年研究改变规则。 也许可以减少罚款或取消暂停。 亚马逊可能会在您下次购买时给您折扣。 但是通常,一旦响起最后的哨声,便确定了游戏状态,并且游戏交易以成功返回码返回。
到目前为止,在运动场上发生的事情与计算机科学中发生的事情之间存在着一些有趣的相似之处。 这是因为在所有引用的系统下都是**通用结构。** 有规则,状态,活动和裁判员,他们解释如何将规则应用于状态活动的结果。
数据库只是一大类引用系统的示例。 房屋检查,审判,经过同行审查的学术论文,保险索赔调整,参加比赛的电影-只有在法官说出自己的真实情况时才有意义。
请注意,即时重播延迟又增加了。 观看视频要花费很多时间,比没有裁判员系统甚至只有裁判员系统的时间要多得多。
## 更多技术意味着更多正确处理事情-集中式系统
技术在未来飞跃发展,并拖累了社会。
摄像头和视频回放是实现现场即时回放的技术。 形成我认为的联合架构。 每个游戏都是自治的和分散的组织,但是规则和信息在游戏之间共享。
自从开始重放以来,我们已经看到了**快速互联网**的发明,功能强大的计算机,甚至还有更多的野外摄像头,以及创建复杂软件的能力。 因此,可以立即发明一种新的即时重放方式。 是的。 这次它使用集中式体系结构。 实际上,NBA,NHL,MLB 和 NFL 都已经转移到集中式即时重播方法,或者正在转移到一种。
这个想法很简单。 现在,可以将**的每个游戏**传输到中央运营中心,该中心可以让专门的专家团队观看视频并查看通话。
再次注意,集中式即时重放延迟又增加了。 现在,我们必须去中央重放中心进行判断。 我们真的必须认为正确性很重要吗?
## 游戏外的读取和修复机制
即时重放并不是唯一可用的读取和修复机制。
例如,在棒球和橄榄球中,比赛统计之后经常对比赛统计数据进行校正。 并非所有内容都可以在游戏环境中正确列出。 例如,稍微反射一下,一个麻袋可能会变成一个完整的麻袋。
场地上发生了很多事情,所以即使裁判员也看不到所有令人讨厌的事情。 这就是为什么存在**精细机制**的原因。 即使未在游戏中要求罚款,也可以在比赛结束后对背景一致性进行罚款。
## 深度学习,无人机,传感器和更多摄像头-混合还是闭环?
技术的下一次发展可能涉及**先进的机器人**,**深度学习系统**,甚至还有**更多的摄像机**,因为传感器和无人机将覆盖整个领域。 您可以想象有 1000 个摄像机覆盖每个游戏,而 AI 则在每个流中检查是否存在违规行为。 游戏的 AI 可以对违规行为进行投票,并以最高的信心将这些呼叫冒出来,直至引起人们的注意。 人类可能会做出最后决定,也可能不会做出决定。
网球中目前使用机器人作为[电子线路裁判](http://en.wikipedia.org/wiki/Electronic_line_judge)。
有些机器人可以在棒球中叫[球,对](http://bleacherreport.com/articles/1942413-should-major-league-baseball-ever-bother-with-a-robotic-strike-zone)进行击打,但是由于棒球具有使用裁判员的悠久传统,因此没有被使用。
**人类自负**将决定如何使用下一代技术。 如果体育中的人为因素被重视超过正确性,那么可能会发展出一种混合系统,该系统在概念上与现代软件系统有很多共同点。 我们仍然会有人工裁判,机器人会选择他们的位置。 集中的 AI 中介组件将承担大部分繁重的工作,而人工将在适当时提供监督。 毕竟,人类仍然必须感到重要。
技术趋于发展。 因此,如果有一点技术增加了系统延迟,并且将精力从分散的架构转移到了集中式架构,那么更多的技术可能会逆转这些发展。
一个闭环系统,每个运动场都有自己的摄像头和自己的 AI,其中 AI 可以直接拨打电话,这将创建一个低延迟系统,与无裁判系统相当,并且完全删除了集中式组件。 **每个游戏都会再次变得快速且分散**。
无论系统多么复杂,在我们眼中,我们始终会知道真正发生了什么。
## 相关文章
* [经进一步审核:即时重播的简要历史记录](http://mentalfloss.com/article/26075/upon-further-review-brief-history-instant-replay)
* [为什么所有体育活动都不使用 NHL 的“控制室”重播审核系统?](http://www.thesportsfanjournal.com/columns/the-rev/all-sports-should-use-the-nhl-control-room-replay-review-system)
* [对 NFL 重播系统](http://espn.go.com/nfl/story/_/id/10670707/nfl-owners-allow-centralized-system-aid-instant-replay)所做的更改
* [特殊报告:在 NHL 的中央视频审核操作中。 它可以在 NFL 中使用吗? 通过调整,可以确定](http://blogs.canoe.ca/krykslants/nfl/special-report-inside-the-nhls-central-video-review-operation-can-it-work-in-the-nfl-with-tweaks-it-sure-can/)
* [美国职业棒球大联盟必须求助于 NHL 风格的即时重播系统,以解决问题](http://bleacherreport.com/articles/1634267-mlb-must-turn-to-nhl-style-instant-replay-system-to-fix-umpiring)
* [球员,裁判员现在比以往更需要重播](http://sports.yahoo.com/news/players--umpires-need-replay-now-more-than-ever.html)
* [如何结束棒球史诗般的主持人改组:使用即时重播裁判员](http://www.theatlantic.com/entertainment/archive/2013/05/how-to-end-baseballs-epic-officiating-screwups-use-instant-replay-umpires/275726/)-反映组织的结构和文化。
* [彼得·加蒙斯(Peter Gammons):忽略重播的天使埃尔南德斯(Angel Hernandez Blew)打电话了](http://deadspin.com/peter-gammons-angel-hernandez-blew-that-call-after-ign-499913975)
* [美国职业棒球大联盟(MLB)的胡扯重播技术:曾经获得通话权的奇迹之王](http://deadspin.com/mlbs-crappy-replay-tech-its-a-miracle-umps-ever-get-499041275)
* [小心您想要的东西](http://www.sportsonearth.com/article/70183162/major-league-baseball-instant-replay-may-be-overwhelming)-想您知道如何观看棒球比赛吗? 只需等到从每个可能的角度进行其他重放即可。 (美联社)
* [MLB 2014:棒球的即时重播如何工作?](http://online.wsj.com/news/articles/SB10001424052702304688104579465230759769104)
* [“在我叫它之前什么都没有!”](http://bill37mccurdy.wordpress.com/2010/08/23/it-aint-nothing-until-i-call-it/) -有关如何通过在球场上让裁判神神拯救棒球的故事。
* [要求宽恕编程-或我们将如何编程 1000 个内核](http://highscalability.com/blog/2012/3/6/ask-for-forgiveness-programming-or-how-well-program-1000-cor.html)
* [您实际上使用 NoSQL 的目的是什么?](http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html)
多么手淫
- 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 内容平台的经验教训