對於平均大小在 10M 至 50M 左右的文件下載服務來說，有沒有什麼成熟的緩存方案呢？

01-06

幾百個TB 這個量級已經不小了，2TB的硬碟100TB也要放50塊，設每台伺服器插12塊硬碟，100TB的文件光存儲伺服器就要5台。一般考慮容災備份策略，無論是 raid x，還是其他策略的備份，肯定不止 5 台，比如按副本冗餘1.5倍或者2倍來算，就是 (50x1.5)/12=6.25 或者 (50x2)/12=8.33..，即100TB的文件最少需要7-9台能插12x2TB硬碟的專業存儲伺服器來支撐，假設這樣一台伺服器便宜點賣3萬元, 100TB 的存儲成本不下 21-27 萬人民幣。

那麼幾百 TB 文件需要 n*(7~9) 台存儲伺服器規模，即 n * (21w~27w) 的存儲成本，當 n = 3 時，此時光存儲伺服器的硬體成本已經接近 100w 人民幣。

這還不算緩存伺服器，io 伺服器，以及帶寬成本。也不算人力成本，和實際研發的時間成本。

考慮到存儲容災備份，不可能把所有雞蛋都放在一個籃子里，所以還需要考慮跨機房跨IDC架構，這又是另外一個話題了。若真跨IDC後，還需要根據實際國情考慮網路/帶寬方面的問題。

一個普通品質的存儲集群，研發投入約10人年

一個高品質的存儲集群，研發投入50~100人年

當然，還需要長期投入2~10人作為日常運維支持。

還有伺服器硬體三年折舊，定期更換磁碟、伺服器是必須的

如果真要投入人力這麼干，不得不說，錢多，...

個人覺得，賣伺服器的同學可以過來關注一下。

不過，撇開硬體層面的各種成本和架構思路不談，單就從技術層面來講。存儲無非就是「存」和「取」，即 get 和 set, 看似很簡單，其實這裡邊大有文章。比如說：

- 如何以最低冗餘實現多副本，而不是讓數據備份成指數級的增長？

- 如何實現跨機器跨idc的低冗餘多副本？

- 如何保證數據一致性？

- 如何讓損壞的數據實現快速修復？

- 基於開源軟體搭建存儲集群是否真的靠譜？如何求證？出現問題怎麼快速解決？

- etc, ...

作為一個做過無數遍雲存儲團隊的其中一分子，說句實話，如果不是真心想運營一套雲存儲基礎服務，還不如用第三方專業雲存儲解決實際問題更靠譜，專業的團隊做專業的事情，單方面的技術折騰只怕水太深。

不知道題主是一定要自己自建CDN么？投入的成本可能會很大。如果能夠使用現成的存儲解決方案，無論從效率還是成本角度都會有好處。現成解決方案，推薦一下七牛雲存儲。:-) 全分散式存儲，

提供在線存儲，傳輸加速，和雲端處理的服務。文件大小無限制，實測下來速度應該是國內最快的雲存儲服務，支持斷點續上傳，數據可靠性可用性一致性都有保障，並且可以做到跨IDC修復。我建議可以測試比較下。5分鐘玩轉七牛雲存儲註冊地址： https://dev.qiniutek.com

又拍雲存儲，又拍雲主要業務就是專註於不超過100M的靜態文件的雲存儲和CDN加速服務，跟你所描述的需求是比較吻合的，建議可以先去免費測試一下，看看是否合適~

自己做了個小東西玩，每天流量最低超過 500 GB。

文件構成絕大部分 10 MB 以下，但有部分文件從 10 MB ~ 80 MB 不等，使用又拍雲作存儲服務，表示比較穩定，毫無壓力。

見下圖：

Amazon S3吧，支持P2P、CDN、條件下載等等強大功能。沒有其它。

眾多這種50m左右文件下載的站點，下載過程都會跳一個Ip 80 82 83等埠跟一串1Q2W3E4R5T6Y7U8I9O0P1Z2X3C4V5B 然後才是路徑，是怎樣實現的，Isp CDN自動生成緩存的嗎

上面那張圖從NS信息上看是藍訊的CDN吧現在= =擦……

這裡先大概說下自己的一些探索過程。

剛開始考慮用proxy_cache，但是proxy_cache只能用硬碟，內存只是保存索引數據。但這邊由於成本的限制，硬碟可能都會是sas，遠遠比不上SSD的。而且有於緩存數據的特殊性，可能需要急時被清理，proxy_cache除非改動代碼否則也沒法直接做到。

想著自己做一個簡單的內部多級cache，利用內存和ssd。這裡大概講下淘汰演算法，使用LFU，但由於緩存的文件不會變化，因此不設定失效時間，純粹的LFU會導致緩存污染很嚴重。大概參考google到的一些LFU的改進方案，自己思索著引入一個周期，當進行數據淘汰時，就遍歷所有緩存的數據，如果條目存在的時間已經超過這個周期了，就訪問計數減半，同時重置存在時間，以達到降低緩存污染影響的目的。

但由於本人並沒有緩存方面的經驗，以前都是使用memcache tc來保存小數據，第一次遇到大文件的緩存，不知道這個淘汰演算法是否會引起某些嚴重的問題？貌似memcache proxy_cache都是使用純粹的lru和lfu的，但是他們本身有條目失效時間。