|
|
老黄 
于 8 月, 2 周 前说到：
这个与好看不的系统很相关，但是大家都有这方面的需求。一个朋友最近也搞了这样的系统，大家说说想法？
|
|
|
|
|
手背轻微晒伤的大野狼 
于 8 月, 2 周 前说到：
我们的计划是原图和700px以上的文件放到S3上，小一些的450px和150px的在本地用MogileFS＋lighttpd方式提供服务。二傻这两天正在忙着个东东，他那里有细节。
|
|
|
|
|
老黄
于 8 月, 2 周 前说到：
哈哈，这是一个互联网企业的做法，够2.0。 :) 这个模型如下：
数据存储角度：
S3
优：足够稳定与结实，原则上不会丢失数据
劣：速度慢，带宽贵
self
优：掌握性强
劣：担心稳定性，一次性投入过大
数据存储所需要的：
1.不能有数据的丢失
2.成本足够低
3.容量足够的大
选择：S3
流量接入角度：
S3
优：全球接入，速度上会有保证
劣：带宽贵，对中国来讲可能优势不足
self
S3
优：中国自己的idc，速度会快
劣：对国外来讲差
流量接入所需要的：
1.速度快
2.容量不用太大
选择：self
方案：数据存储于S3，用户使用率高的cache到本地。
想了大狼的东东，加了点自己的想法。还有别的建议吗？
|
|
|
|
|
二傻
于 8 月, 2 周 前说到：
>数据存储于S3，用户使用率高的cache到本地。
基本就是这个策略。对于好看簿，对原图的访问量非常小。所以放到S3即能节约存储，而且也不会使用太多的带宽。对于近期（1个月左右）的图片会cache在本地。
|
|
|
|
|
xyb 
于 8 月, 2 周 前说到：
喜欢最后选择的这个策略。但不知道S3在国内的网站中应用到底效果如何，看来好看簿要做探路者了。
|
|
|
|
|
二傻
于 8 月, 1 周 前说到：
这段时间准备开始测试这个方案，最新情况会及时汇报的。
|
|
|
|
|
仨儿
于 8 月, 1 周 前说到：
饿靠！
好看的这个大规模网站设计 快成了高性能网络架构的方案中心了！
建议在达到某一容度时，收费准入袅 ;)
|
|
|
|
|
二傻
于 8 月, 1 周 前说到：
今天初步测试了一下S3，分3批分别上传了100，100，500张图片到S3。图片大小几十K到4M。下面是些体会：
1. 图片上传到S3后，可以马上通过浏览器访问到，延迟基本觉察不到。
2. 访问S3的速度比较慢，但是由于对于访问原图的需求非常少，所以这个速度应该也可以接受。大家可以通过下面两个连接感觉一下速度的不同。
http://www.haokanbu.com/media/...
http://haokanbu.s3.amazonaws.c...
3. 在上传过程中会出现错误，我遇到的是http 400。导致图片上传失败。700张照片中共出现4次失败。不过如果重新上传这些图片，能够成功上传。google了一下，可能是网络问题。
4. 上传速度比想象的要慢。700张照片，共367M，总共用了135分钟，平均一分钟不到3张。这个结果让我比较担心。因为如果按照这个速度，24小时最多往S3传送4320张图片。如果好看簿一天增加的图片数超过这个值，就会是S3无法同步。
|
|
|
|
|
手背轻微晒伤的大野狼
于 8 月, 1 周 前说到：
有意思，2和4的問題比較突出。有沒有什么可以解決的方案？相信我們不會是第一個遇到這些問題的人。
|
|
|
|
|
xyb
于 8 月, 1 周 前说到：
试试从美国机器上传速度如何。如果速度快，可以考虑利用美国机器做二传。
|
|
|
|
|
清风
于 8 月, 1 周 前说到：
多线程同时上传呢?
|
|
|
|
|
二傻
于 8 月, 1 周 前说到：
@xyb: 从美国机器上传速度应该会快一些，但是这需要先从本地传到一台美国的服务器，再到S3，会比较麻烦。而且还需要保证从本地到美国服务器的速度。
@清风：多线程应该会对性能有所增加，不过同时肯定会消耗更多的资源和带宽，这个我会具体测一下看看。
|
|
|
|
|
老黄
于 8 月, 1 周 前说到：
今天和一朋友一起聊，总结了三点，可以一起综合考虑：
1.S3做为存储，对它的可用性的要求到底是什么？
2.S3做为服务，对它的可用性的要求到底是什么？
如果丫断网了，是不是可以承受。这里感觉网络是最大的问题。
|
|
|
|
|
老黄
于 8 月, 1 周 前说到：
今天和一朋友一起聊，总结了三点，可以一起综合考虑：
1.S3做为存储，对它的可用性的要求到底是什么？
2.S3做为服务，对它的可用性的要求到底是什么？
如�
|
|
|
|
|
车载（宰）蚂蚁
于 8 月, 1 周 前说到：
在2里面图片不是同一张，大小相差3倍。
我有几个疑问：
1、简单算一下4里面的上行速度50K，不知道这是s3的限制还是我们托管机房的限制，如果是我们这个结点的限制，并发上传是无意义的，如果是s3单连接上传的限制，那并发上传能把这个数字提高几倍呢？
确实象二傻同学说的，如果我们新增的图片超过了用s3节约的空间，采用s3的好处就丢了，也许我们可以估算下这个好处能保持多久。
@老黄：我自己倒是认为目前这个方案其实是在借力s3的存储，所以最重要的是可靠性，以及从s3二次备份数据的可用性。
|
|
|
|
|
二傻
于 8 月, 1 周 前说到：
s3的SLA说uptime可以达到99.9%。如果断网了，他号称会赔钱给你。不过这些钱肯定无法弥补损失的。所以对于关键性服务，还是把东西掌握的自己手里比较好。
|
|
|
|
|
二傻
于 8 月, 1 周 前说到：
@蚂蚁：不是S3的限制，论坛上有人速度能达到1M。应该也不是我们节点的限制。我认为应该是国内访问S3的速度比较慢。我traceroute了一下：
traceroute to haokanbu.s3.amazonaws.com (72.21.211.214), 30 hops max, 40 byte packets
1 60.28.205.129 (60.28.205.129) 0.340 ms 0.426 ms 0.554 ms
2 (60.28.192.17) 2.186 ms 2.280 ms 2.369 ms
3 211.151.227.65 (211.151.227.65) 3.657 ms 3.751 ms 3.639 ms
4 211.151.224.150 (211.151.224.150) 3.979 ms 3.976 ms 4.052 ms
5 219.142.8.25 (219.142.8.25) 4.663 ms 4.652 ms 4.776 ms
6 bj141-130-121.bjtelecom.net (219.141.130.121) 4.786 ms 3.139 ms 7.911 ms
7 202.97.57.213 (202.97.57.213) 25.930 ms 25.947 ms *
8 202.97.53.146 (202.97.53.146) 26.056 ms 26.044 ms 26.066 ms
9 (202.97.51.66) 659.403 ms 659.398 ms 659.447 ms
10 sjp-brdr-01.inet.qwest.net (205.171.1.5) 243.146 ms 243.134 ms 243.117 ms
11 snj-core-02.inet.qwest.net (205.171.233.29) 243.097 ms 243.093 ms 243.195 ms
12 dcx-core-01.inet.qwest.net (67.14.32.2) 373.920 ms dcx-core-02.inet.qwest.net (67.14.1.250) 375.114 ms 375.115 ms
13 dcp-edge-01.inet.qwest.net (205.171.251.74) 375.631 ms 375.644 ms dcp-edge-01.inet.qwest.net (205.171.251.70) 375.805 ms
14 * * *
15 72.21.209.34 (72.21.209.34) 305.820 ms 305.897 ms 305.926 ms
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
到了9以后，节点就变得比较慢了。
|
|
|
|
|
老黄
于 8 月, 1 周 前说到：
我刚发现写的字被截断了，如果它是一个备份，哪是一个非常幸运的选择。要知道，GFW和海上捞鱼的网都是最可怕的威胁呀。
|
|
|
|
|
二傻
于 7 月, 4 周 前说到：
s3在国内的连接情况真的让人担忧，在这一段时间的测试中，发现会不定期的出现Broken pipe的问题，查了一下论坛，好像还是网络连接的问题。400也是经常出现。
测试了一下多线程，速度也没有提高，不知是我的程序有问题还是网络的问题。总之对s3在国内的使用情况还是持保留态度。
|
|
|
|
|
手背轻微晒伤的大野狼
于 7 月, 4 周 前说到：
另一種方式就是先上傳到Amazon，然後通過下行通訊把內容下載到國內機房。
這樣的好處：1）文件小了很多，pipe穩定一些；
2）整個文件處理的負擔全部外包了。
不過就需要在amazon上開上一堆EC2了。
|
|
|
|
|
手背轻微晒伤的大野狼
于 7 月, 4 周 前说到：
我體內商人的一面讓我閉嘴，但是Geek的一面想大聲喊出來。
對於Smugmug，採用S3每年節省他們50萬美元的運營成本。（當然，美國對於固定資産折舊的法律和國內不同，但是差別不會太大）。
下面是我找到的關於Smugmug架構和採用S3的幻燈片。Smugmug是美國非常著名的，自主盈利的照片存儲網站，更有趣的是這是個家庭運營的買賣，所有員工都是家人。
× Scaling Smugmug from startup to profitability：
http://www.royans.net/arch/200...
× Smugmug的創始人在ETech上的PPT：http://static.scribd.com/docs/...
－ 根據這個創始人的計算，如果流量達到1GB以上，自己host照片在帶寬上可能會更便宜一些，但是硬碟的開銷，折舊，處理，機房費用仍然非常高昂。
－ 對於Smugmug團隊，周一開始開發，周五就已經上線了。
－ Smugmug開始只把S3作爲二級備份存儲，後來完全採用S3，發現性能不行；最後採用的方案是把熱點文件在Smugmug內部存儲。基本95%的文件從S3向外提供。
－ Smugmug不直接提供S3的鏈結，基本採用本地的一個Proxy服務。這樣的好處據說是
－ 可以先試試本地緩存，如果本地已經有的話，可以直接返回，節約S3的帶寬（Smugmug有192T的照片，所以估計帶寬還是蠻貴的）
－ 方便許可和Permission管理。
－ 爲了防止網路出現問題，Smugmug在本地寫，然後首先同步；如果失敗，就異步同步。
－ 在美國東西海岸，S3讀寫速度都可以達到10M每秒！（想罵人，真的）
－ 同步腳本用cURL寫的，據說可以支援Stream，不過俺不太理解什麽意思。（二傻？）據說cURL是他們測試過的最快的傳輸工具。
除了S3以外，Smugmug還採用EC2進行圖像處理，
|
|
|
|
|
二傻
于 7 月, 4 周 前说到：
我觉得速度现在是唯一瓶颈。stream我个人理解是对于文件不是一下子全部读到内存中，而是采用stream的方式读取并put到s3。这个对于大的文件影响较大，对于小文件，例如图片，几乎不会有多少性能的影响。Smugmug对s3的成功使用的基础就是10M每秒的速度。但是中国是一个具有中国特色的社会主义国家，在国内连接s3也只有中国特色的速度。而一旦失去这个稳定快速连接的基础，s3除了备份，基本无法使用到要求有较快响应速度的服务中。
|
|
|
|
|
二傻
于 7 月, 4 周 前说到：
对于直接把图片上传到S3的方案，如果出现测试中400和Broken pipe的频率来看，上传失败的几率要大很多，基本是不可接受的。
|
|
|
|
|
二傻
于 7 月, 4 周 前说到：
http://www.chedong.com/blog/ar...
这篇blog的最后一句说他用s3一天大约上传1G左右。看来国内连接s3基本就是这个速度了。
|
|
|
|
|
手背轻微晒伤的大野狼
于 7 月, 4 周 前说到：
是呀，是呀。 （一边摇头，一边微微叹气）
对了，如果用EC2，让文件直接先传到S3，然后再下载到国内呢？ 有没有测试过下载的速度？
|
|
|
|
|
二傻
于 7 月, 4 周 前说到：
其实现在问题不在下载的速度，而是就算我们使用EC2，基于s3的速度测试，我们又怎么敢奢望国内连接EC2的速度和可靠性呢？如果EC2的连接也和S3一样，那从本地到s3和从EC2到s3基本都不行。
|
|
|
|
|
老黄
于 7 月, 4 周 前说到：
上次写了一半，担心大家更geek :) 但是用S3是理想的选择，但是线路是不保证的，海底的哪几个天天上面漂着网的线绳和强大的GFW确实让人担心呀 :(
|
|
|
|
|
二傻
于 7 月, 4 周 前说到：
对。如果在网络的速度和可靠性可以保证的基础上，EC2和S3绝对是一个很好的选择。但是一旦失去的这个基础，对于重要的服务来说，基本就不可用了。
|
|
|
|
|
手背轻微晒伤的大野狼
于 7 月, 4 周 前说到：
So Sad
- Everly Brothers
We used to have good times together
but now I feel them slip away
It makes me cry to see love die,
so sad to watch good love go bad
Remember how you used to feel, dear,
you said nothing could change your mind
It breaks my heart to see us part,
so sad to watch good love go bad
Is it any wonder that I feel so blue
when I know for certain that I'm losing you?
Remember how you used to feel, dear,
you said nothing could change your mind
It breaks my heart to see us part,
so sad to watch good love go bad
So sad to watch good love go bad
|
|
|
|
|
手背轻微晒伤的大野狼
于 7 月, 3 周 前说到：
基于今天下午讨论的提纲, 有下列测试可以做:
1. 如果用多台机器同时上传, 是否每个机器都可以达到50K的数据?
2. 如果把网站出口带宽多扩充2M, 上传速度是否会有所改进?
最次情况, 也可以考虑采用S3对外链图片进行处理, 以减轻尖峰访问带来的长期带宽浪费.
|
|
|
|
|
二傻
于 7 月, 3 周 前说到：
昨天晚上突然觉得S3不应该这么次。于是就又上网搜索，找了另外一个python s3的库，重新修改程序，测试，传100个文件居然只用了7分钟，而且几乎不出400的错误。心里这个美啊。于是开着测试程序睡觉去了。
早上起床后，看程序的log，整个晚上也只传了2000多个文件。读log，发现在某些时间段，s3的速度会非常非常慢，而且也偶尔出现了400错误。不过Broken pipe的问题已经没有了。根据log，传100个文件，最快的时候可以达到3分钟多点，最慢的时候要一个多小时。所以对于s3的整体速度，还是比较难以估计。
|
|
|
|
|
手背轻微晒伤的大野狼
于 7 月, 3 周 前说到：
这无论如何都是非常好的消息, 恭喜!
今晚再试试, 看看有啥子规律没? 也许, 晚上恰好是美国同学们用网高峰?
|
|
|
|
|
车载（宰）蚂蚁
于 7 月, 3 周 前说到：
每100个文件个文件大小相同吗？快慢20多倍的比例也太夸张了。
|
|
|
|
|
二傻
于 7 月, 3 周 前说到：
不一样，但差别应该不大。速度慢的时候经常会出requesttimeout的错误，所以应该还是网络问题。
|
|
|
|
|
老黄
于 7 月, 3 周 前说到：
国内的下一代高可用性、虚似化基础服务显然和百度一样建立在本土化基础上会有完全不同的领先者。期待这个领先者的出现。
我还是不太相信海底的哪几跟线和GFW的情绪。
|
|
|
|
|
Diamond Tin!
于 7 月, 3 周 前说到：
今天看到这个小组和这个讨论非常兴奋，不过没有时间仔细看晚呢，明天继续看。
只是我想说，如果理性一点想这个问题，如果中国的网络有问题，在你的用户增长到一定程度的时候如果每日的备份的吞吐量超过了我们链接S3的能力，那么存储压力就会比较大了。而且感觉S3的访问速度实在是成问题。
联想到前一段时间南方的电信ban了google的一些ip段……如果国内S3开展积极的话，你看可爱的电信、网通会不会行动起来让你买单？让你买还好，如果他们偷偷掐线怎么办？
如果老黄出来在国内搞这个服务，即使是咨询的形式我觉得也很好呀。MogileFS个人认为没啥特点，其实自己写这个图片服务器的路由算法也是非常简单的。就是基于数据库来存储实际的文件存储服务器位置嘛。
现在1TB的硬盘如果越来越普及的话，我觉得还是可以考虑自己维护磁盘阵列。
|
|
|
|
|
二傻
于 7 月, 2 周 前说到：
昨天下午把带宽临时调高到5M，上传速度有了明显的提高。通过上传一个22M的文件进行测试，平均上传时间为2分钟，上传速度将近190K/s。测试两个机器同时上传这个文件，时间平均为150秒，速度达到300k/s。所以通过增加带宽和多机同时上传来提高效率的方法应该是可行的。
现在其实唯一担心的就是对S3的信任问题。一是会不会被和谐掉，二是海底光缆会不会被挖断。
|
|
|
|
|
手背轻微晒伤的大野狼
于 7 月, 2 周 前说到：
这个结果很有意思，完全可以把至少是外联的问题给解决掉，不错！！
如果这样说来，等到咱们的带宽买了1G的时候，咱们上传速度也可以到达10M/s吗？ 有没有可能让世纪互联的人给放开到1G？ 如果需要的话，俺可以给他们打电话，应该一个晚上就够了吧～～～
|
|
|
|
|
Diamond Tin!
于 7 月, 2 周 前说到：
我感觉这个讨论涉及到了Web service的可用性问题，我们应该冷静对待：
1、如果Amazon没有做全球的分布，我觉得我们依赖地球对面的存储服务就不是非常靠谱。
2、在国内搞这样的基础Web服务还是有商机的。
3、当上层应用发展速度非常快的时候，基础设施就容易成为瓶颈。
|
|
|
|
|
车载（宰）蚂蚁
于 7 月, 2 周 前说到：
除了用s3解决外链带来的带宽压力，我们也应该可以用s3作为原图的备份，如果担心s3不可用时数据的恢复，就再加一台到多台存储量大的廉价服务器作为图片压缩存储的备份服务器。
用s3+备份服务器的组合方案解决带宽压力和存储压力似乎更简单些。
|
|
|
|
|
手背轻微晒伤的大野狼
于 7 月, 2 周 前说到：
(nodding)
你的这句话俺不是特别明白：”廉价服务器作为图片压缩存储的备份服务器。“，能解释一下吗？
|
|
|
|
|
二傻
于 7 月, 2 周 前说到：
>如果这样说来，等到咱们的带宽买了1G的时候，咱们上传速度也可以到达10M/s吗？
因为上传会占用总带宽，所以上传速度应该和我们网站的访问流量成反比的。所以具体多大的带宽能达到什么样的上传速度还不好说。
>有没有可能让世纪互联的人给放开到1G？ 如果需要的话，俺可以给他们打电话，应该一个晚上就够了吧～～～
可以试试，至少可以知道在流量小的情况下，1G的S3上传速度有多少。不过要扩到1G，看来必须你亲自出马了。
|
|
|
|
|
车载（宰）蚂蚁
于 7 月, 2 周 前说到：
所谓备份服务器，就是跑一个CronJob把每１００张图片压缩到一个文件里，然后放在自己的硬盘上，这个服务器不对外提供服务，完全作为备份机存在。
|
|
|
|
|
手背轻微晒伤的大野狼
于 7 月, 2 周 前说到：
@蚂蚁: 理解了，这样其实没有压缩？只是归档？
@二傻: 关于反比的计算是很正确的，这也是在国内用S3比较尴尬的问题，用带宽的高峰期，恰恰也是备份速度最好的时候。
可以打个电话聊聊了。
|
|
|
|
|
Diamond Tin!
于 7 月, 2 周 前说到：
其实目前的mysql和media server都可以作为冗余备份用，而异地备份的蚂蚁想的方法很好。其实500G的硬盘不过799元，我们可以定期过去备份，减少网络带宽带来的限制。
现在的关键还是数据分目录，分区，方便备份的切分！
|
|
|
|
|
老黄
于 7 月, 2 周 前说到：
我的理念一真是服务即备份，备份即服务。不过这是在规模化运行的情况下的工作方法。原理是你为了让用户的服务做的好，这时会发现不得不把数据变为两份或多份，这时你就不必再考虑备份的问题了。
|
|
|
|
|
Diamond Tin!
于 7 月, 2 周 前说到：
老黄，你说的我不太懂，能详细一点么？我非常感兴趣，正在读长尾。
|
|
|
|
|
老黄
于 7 月, 2 周 前说到：
比如说，好看的图片现在有2T。现在都在一个机房里，因为世纪互联有双线的线路。可是。。。发现四川用户访问很慢（以我所知道的情况西南地区都快不到哪里去），可是四川的用户访问西安很快。这时决定把系统部署到西安机房去。。。。西安是一个sync的slave机房，这时。。。数据有两份了，都是服务数据，而且互为备份。没有理由再做什么备份了。。。 ;)
|
|
|
|
|
chifeng
于 7 月, 1 周 前说到：
终于读完了。。。重要的服务还是自己做比较好，放到地球那边的amazon不太靠谱。
|
|
|
|
|
Diamond Tin!
于 7 月, 1 周 前说到：
嗯，谢谢老黄的解释。你说的还是分布式了。
我突然想明白了一个问题，带宽不是问题。这个技术环节中缺了一节，是它让我们迷茫。我们缺少了message queue，有了异步消息队列（如著名的JMS）我们就可以让更多的节点去做上传这样的工作了。
|
|
|
|
|
chifeng
于 7 月, 1 周 前说到：
我怎么觉得用rsync就可以实现。
|
|
|
|
|
车载（宰）蚂蚁
于 6 月, 3 周 前说到：
http://haokanbu.s3.amazonaws.c...
Http/1.1 Service Unavailable
|
|
|
|
|
手背轻微晒伤的大野狼
于 6 月, 3 周 前说到：
works here. 你那里还不行？
|
|
|
|
|
车载（宰）蚂蚁
于 6 月, 3 周 前说到：
it's fine now.
|
|
|
|
|
老黄
于 6 月, 3 周 前说到：
S3停机了。。。
|
|
|
|
|
老黄
于 6 月, 3 周 前说到：
http://www.roughtype.com/archi...
|
|
|
|
|
手背轻微晒伤的大野狼
于 6 月, 3 周 前说到：
smugmug几乎未受任何影响。 它的CEO近期会介绍Smugmug的备份方案，值得期待中。
由于对原图请求数量非常少，好看簿几乎未受到任何影响。
在此感谢二傻同志在存储架构稳定性上的深入研究。
|
|
|
|
|
手背轻微晒伤的大野狼
于 6 月, 3 周 前说到：
s3出问题的原因竟然是登陆验证失败
http://www.highscalability.com...
|
|
|
|
|
lucksnail 
于 5 月, 4 周 前说到：
这个东西现阶段还是不靠谱~~~可控性太差
|
|
|
|
|
DavidShi
于 1 月, 1 周 前说到：
怎么解决，图片或者其他资源 被盗链的问题呢？？
|
|
|
|
|
手背轻微晒伤的大野狼
于 1 月, 1 周 前说到：
@faceweb: 你可以参考好看簿现在采取的外链策略。
|
|
|
|
|
DavidShi
于 1 月, 1 周 前说到：
@手背轻微晒伤的大野狼: 不是把图片备份两份吧， 外联的用图片放A3上，本站浏览用的图片放在自己的server上？？
不知道您说的是啥外链策略？ 望指导一二.....
|
|
|
|
|
手背轻微晒伤的大野狼
于 1 月, 1 周 前说到：
关于外链图片存储，我们基本采用两套存储，保证数据安全性。
此外，通过一些非技术性的手段，来减少低端用户大量上传可能带来的存储压力。
|
|
|
|
|
