# 正確處理事情:通過即時重放查看集中式系統與分散式系統
> 原文: [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”,它們才算是什么。*
| 
AT&T's Global [Network Operations Center](http://www.nj.com/business/index.ssf/2011/08/att_gnoc_earthquake.html) | 
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/) |
**更新**:[在 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 內容平臺的經驗教訓