# Cinchcast 體系結構-每天產生 1,500 小時的音頻 > 原文： [http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html](http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html)  *這是 [Aleksandr Yampolskiy 博士](http://www.twitter.com/ayampolskiy)， [Cinchcast](http://www.cinchcast.com/) 和 [BlogTalkRadio](http://www.blogtalkradio.com/) 的 CTO 的嘉賓帖子，他負責工程，質量檢查，TechOps，電話和 產品團隊。* [Cinchcast](http://www.cinchcast.com) 提供的解決方案使公司能夠創建，共享，衡量和貨幣化音頻內容，以吸引和吸引對其業務最重要的人們。 我們的技術將會議橋與實時音頻流集成在一起，以簡化在線事件并增強與會人員的參與度。 Cinchcast 技術還用于為全球最大的音頻社交網絡 [Blogtalkradio](http://www.blogtalkradio.com) 提供動力。 今天，我們的平臺每天制作和分發超過 1500 小時的原始內容。 在本文中，我們描述了為了擴展平臺以支持這種數據規模而做出的工程決策。 ## 統計信息 * 每月瀏覽量超過 5000 萬 * 已創建 50,000 小時的音頻內容 * 15,000,000 個媒體流 * 175,000,000 次廣告展示 * 每秒 40,000 個并發請求的峰值速率 * MSSQL，Redis 和 ElasticSearch 群集中每天存儲的數據量為 TB /天 * 由 10 位工程師組成的團隊（在 20 位技術人員中）。 * 大約有 100 個硬件節點正在生產中。 ## 數據中心 * 生產網站是從布魯克林的數據中心運行的。 我們喜歡控制自己的命運，而不是將數據委托給云。 * Amazon EC2 實例主要用于質量檢查和登臺環境。 ## 硬件 * 大約 50 臺 Web 服務器 * 15 個 MS SQL 數據庫服務器 * 2 個 Redis NOSQL 鍵值服務器 * 2 個 NodeJS 服務器 * 2 個用于彈性搜索集群的服務器 ### 開發工具 * .NET 4 C＃：ASP.NET 和 MVC3 * Visual Studio 2010 Team Suite 作為 IDE * StyleCop，用于加強代碼標準的 Res??harper * 敏捷開發方法，Scrum 用于大型功能，看板任務板用于較小的任務 * Jenkins + Nunit 用于測試和持續集成 * 按需調味–自動化測試用硒 ## 使用的軟件和技術 * **Windows Server 2008 R2 x64** ：操作系統 * **SQL Server 2005** 在 **Microsoft Windows Server 下運行 2008 年** Web 服務器 * **均衡器負載均衡器** ：用于負載均衡 * **REDIS** ：用作分布式緩存層并用于消息發布-子隊列 * **NODEJS** **用于實時分析和更新 Studio 儀表板** * **ElasticSearch** ：用于節目搜索 * **Sawmill +自定義解析器腳本：** 用于日志分析 ## 監控 * **NewRelic** 用于性能監控 * **Chartbeat** 對性能對 KPI（轉化，頁面瀏覽）的影響 * **Gomez，WhatsupGold 和 Nagios 提供各種警報功能** * **SQL Monitor：** 來自 Red Gate-用于 SQL Server 監視 ## 我們的方法 * “簡短，聰明，消失”：尊重他人的時間。 不要有問題，要有解決方案。 * 不要去追逐當今的熱門技術。 而是“緩解您的主要問題”。 我們采用新技術，但是在業務案例需要時采用新技術。 當您有數百萬個用戶時，生產中斷的需求就會大大降低。 * 達到“基本”，然后擔心“優秀”。 * 成為“如何團隊”而不是“沒有團隊”。 * 將安全性納入軟件開發生命周期。 您需要培訓開發人員如何編寫安全軟件，并使之從一開始就成為企業的優先事項。 ## 架構 * 所有 Javascript，CSS 和圖像都緩存在 CDN 級別。 DNS 指向將請求傳遞到原始服務器的 CDN。 我們使用 Cotendo 是因為它允許在 CDN 上做出 L7 路由決策。 * Web 服務器的單獨群集用于為常規用戶和廣告用戶提供服務，以 Cookie 區分。 * 我們正在朝著面向服務的體系結構發展，該體系的關鍵部分（例如搜索，身份驗證，緩存）是以各種語言實現的 RESTFUL 服務。 這些服務還提供了一個緩存層。 * REDIS NOSQL 鍵值存儲（redis.io）用作數據庫調用之前的緩存層。 * 橫向擴展用于在整個 Web 服務器花園中維護會話狀態。 但是，我們正在考慮切換到 REDIS。  ## 獲得的經驗教訓 * **無法在 SQL Server 數據庫中搜索文本**。 它阻塞了 CPU，所以我們切換到 ElasticSearch（Lucene 派生的）。 * **Microsoft 的內置會話模塊容易出現死鎖**，因此我們最終將其替換為 AngiesList 會話模塊，并將數據存儲到 REDIS。 * **日志記錄是檢測問題的關鍵。** * **重塑車輪可能是一件好事**。 例如，最初我們使用供應商產品將 JS / CSS 捆綁在一起，這開始導致性能問題。 然后，我們重新編寫了捆綁包，并顯著提高了我們網站的性能。 * **并非所有數據都是相關的**，所以數據庫并不總是一個好的媒介。 一個很好的類比是“假設您有水順著管道流下。 管道的頂部較寬，而底部則較窄。” 頂部是 Web 服務器（其中有很多），底部是數據庫（很少，并且被阻塞了）。 * **在開發過程中不使用指標就像試圖在高度計不起作用的情況下將飛機降落在風暴中**。 在整個開發過程中，計算指標，例如站點吞吐量，修復 Blocker /關鍵 bug 的時間，代碼覆蓋率，并使用它們來衡量性能。 感謝您的有趣帖子。 您如何處理 sql 數據庫的復制？ 謝謝！ 有趣的 您模型的“關系”部分是什么？ 將記錄保留在 Disc 陣列中并在 DB 中保留位置不是一個更好的設計。 另外，您也不要在 CDN 服務器上復制脫機內容。 只是好奇