# 神話:埃里克·布魯爾(Eric Brewer)談銀行為什么不是堿-可用性就是收入
> 原文: [http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html](http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html)

在 [NoSQL:過去,現在,未來](http://www.infoq.com/presentations/NoSQL-History) [Eric Brewer](https://twitter.com/eric_brewer) 中,關于解釋 [BASE 的觀念通常很難理解的部分特別細膩](http://queue.acm.org/detail.cfm?id=1394128) (基本可用,軟狀態,最終一致), [酸](http://en.wikipedia.org/wiki/ACID) (原子性,一致性,隔離性,耐久性), [CAP [](http://en.wikipedia.org/wiki/CAP_theorem) (一致性可用性,分區容限),這是關于銀行業一致性的神圣性的長期存在的神話。
**神話** :金錢很重要,因此銀行 必須 使用交易來保持金錢安全和一致,對嗎?
**現實** :銀行交易不一致,尤其是對于 ATM 而言。 ATM 被設計為具有正常情況下的行為和分區模式的行為。 在分區模式下,可用性是通過一致性來選擇的。
**為什么?** **1)**可用性與收入相關,而一致性通常不相關。 **2)**歷史上從來沒有完美交流的想法,所以一切都被分割了。
您的 ATM 交易必須經過,因此可用性比一致性更重要。 如果自動柜員機(ATM)處于關閉狀態,那么您就無法賺錢。 如果您可以保持一致性,堅持不懈,并彌補其他錯誤(這種情況很少發生),那么您將獲得更多的收入。 這是大多數企業發現的空間,因此 BASE 比以前更受歡迎。
對于金融業來說,這不是一個新問題。 他們從來沒有保持過一致,因為歷史上他們從來沒有過完美的溝通。 相反,金融業依賴審計。 導致銀行數據一致性的原因不是其數據庫的一致性,而是所有事實都被 [寫下兩次,然后稍后使用](https://en.wikipedia.org/wiki/Double-entry_bookkeeping_system) 進行整理。 不可更改的記錄,以后再進行核對。 對錯誤進行財務補償的想法是深深植根于金融系統的想法。
在文藝復興時期,當[現代銀行系統](http://en.wikipedia.org/wiki/Luca_Pacioli)初具規模時,一切都被分割了。 如果信件(您的數據)是通過馬或輪船運輸的,那么您的數據可能會保持非常低的一致性,但是它們仍然擁有令人驚訝的豐富而成功的銀行系統。 交易是不必要的。
例如, ATM 選擇了 [交換操作](http://en.wikipedia.org/wiki/Serializability) 之類的遞增和遞減操作,因此操作順序無關緊要。 它們是可重新排序的,以后可以使其保持一致。 如果 ATM 與網絡斷開連接,并且當分區最終恢復正常時,ATM 發送將操作列表發送到銀行,并且期末余額仍然正確。 問題很明顯,您可能會提取比您更多的錢,因此最終結果可能是一致的,但為負數,無法通過要求退款來彌補,因此,銀行將向您獎勵透支罰款。
隱藏的哲學是您試圖 **約束并管理風險,** 仍然可以進行所有操作。 在 ATM 機中,這將限制您一次可以提取的最大金額。 風險不大。 自動取款機是有利可圖的,因此偶爾的損失僅僅是開展業務的風險。
事實證明,這不是圣杯。 勝過一致性的是:
* 審核
* 風險管理
* 可用性
在以寫可用性為關鍵的后互聯網世界中,現實世界看起來更像*弱一致性+延遲異常+補償*,而不是完美的溝通和交易的無錯誤世界。 就像過去一樣,但現在您在 ACID <-> CAP 頻譜上有更多選擇。
## 相關文章
* [關于 HackerNews 2](https://t.co/VMC2IA1K0I)
* [討論黑客新聞](https://news.ycombinator.com/item?id=5642010)
* [](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html)[Google Spanner 最令人驚訝的啟示:NoSQL 出爐了,而 NewSQL 出現了](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html)
真的很有趣。 當然,課程必須實施廣泛的審核功能,以彌補潛在的不一致問題,并在發現問題時嘗試和糾正流程
這帶來了銀行認為可以接受的復雜程度,因為收益非常可觀。 但是并不是每個組織或其應用程序都可以忍受這一點-因此仍然有很多地方需要保持一致性
嗨,托德,
我不確定您的所在地,但該示例在英國似乎并不成立。 我不知道實際的實現方式,但是在免費的 ATM 交易環境中,可用性似乎并不是主要問題。 自動柜員機停運并不罕見,而且,超出您的限額將導致機器拒絕為您提供所要求的現金。
盡管如此,有關換向運算的有趣觀點。
干杯,
蒂姆
我不知道這是否可行,因為錢是可替代的-銀行從我那里獲得的 1 美元報酬與自動柜員機應支付的 1 美元沒有明顯的不同。
如果我使用了錯誤的約會資料并承諾“以后再補”,則效果不一樣。 :)
蒂姆
我也在英國,并且同意 ATM 系統乍看之下在英國似乎并不那么清楚,但我相信它仍然是正確的。
我相信,使 ATM 脫機的原因是 ATM 與它用于驗證卡號并快速檢查卡是否被舉報為欺詐性的服務之間的斷開連接。 每個 ATM 提供商(實際上是銀行組)似乎確實要分別運行其系統,然后再將它們一起應用。
我當然已經看過自動取款機說不能顯示我的余額,但是可以提款。
如果這樣的分區是為什么在周末/銀行假日不進行任何交易,而您仍然可以使用您的卡,我不會感到驚訝。
另一個蒂姆
A 罐(應該)仍代表原子。 誰想要一半的交易偽裝成整個交易?
我在 atm 網絡上工作了多年,是的,它們都像這樣工作。 今天,大多數網絡都以在線模式工作。 但是協議支持脫機交易。 請記住,這些網絡也支持信用卡交易(可以在授權交易后應用提示)。 脫機模式可用于支持斷開連接的情況或啟用可伸縮性,驗證是聯機的,但金融交易是分批的。 完全斷開連接的可能性較小,因為必須在線檢查引腳(至少直到芯片和引腳為止)。
從 atm 到后臺,事務不是原子的,如果發生通信錯誤,則可以撤消事務。 一些自動取款機交易被標記為強制過帳,以表明已經發放了款項,即使它們違反了辦公室規定(如不透支)也已得到處理。
這些細節中的一些是西方過去的遺跡,但是在非洲,南美和印度,長距離通信可能非常繁瑣,因此中斷的操作仍然非常重要。
盡管 Atm 交易是免費的,但信用卡交易涉及銀行收費和商人收入。 當服務不可用時,也會損害聲譽。 在金融危機爆發的第一年左右,有很多關于不同機構的傳言。 這些機構非常擔心服務中斷會觸發其銀行擠兌。
干得好,保持下去
好的文章,內容翔實,有趣,重點突出。
Tim,
>可用性似乎并不是主要問題。 自動柜員機停運并不罕見
高不可用性率并不能證明可用性不是 OP 中規定的最高優先級。 它只是表明所討論的網絡在實現該優先級方面很差。
>超出您的限制將導致機器拒絕為您提供所要求的現金。
同樣,這并不是可用性優先于一致性的禁忌。 本文的風險管理部分對此進行了介紹。
本文缺少的是認識到,在銀行發布的實際財務更新包含的內容遠不止簡單的余額更新。 可能會有幾十個表被更新,甚至更多。 所有這些工作必須是原子的。 ATM 網絡具有備用功能,可以在多個級別上進行不可靠的通信或主機丟失,但是當消息到達銀行時,它最終是一個很好的老式 ACID 更新。 ATM 和在線信用卡交易系統及其支持的登錄,強制發布,預授權,部分和增量授權等功能,使網絡變得非常可用,這僅僅是因為各機構已選擇達成一項協議 彼此都很好。 銀行系統不太愿意讓提款部分過帳。
謝謝,不錯的帖子
有趣的文章,感謝您提供信息。
真正不幸的是,信息開發人員必須受到來自 Web 開發社區的此類論點的轟炸。
經典的 ATM 示例不應該從字面上理解,而是重要交易的象征。 最容易理解的一種。
現代銀行機構已經實施了風險管理以促進可用性的事實,并沒有改變任何與 ACID 兼容的交易的重要性!
在我的銀行存款,我每 24 小時只能提取 500 美元(風險)(保持一致的時間)。 讓我們想象一下一項新法律,銀行將不再采取此類措施? 哪里有人可以拿出大筆現金? 銀行將很快從 BASE 變為 ACID!
今天的最終一致性如何?
這是關于分發帳單,以及在有人關心的情況下移動零碎的東西。
考慮到關于 ACID 的評論中的論點,我真的很想讀這本書的續集。
- 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 內容平臺的經驗教訓