淘宝图片存储与颁诲苍系统
- 3. 图片存储与CDN系统全貌 3 Global Load Balancing L1-Cache L2-Cache Application Storage Cache Cluster Cache Cluster Cache Cluster Cache Cluster Cache Cluster Image Server Cluster Image Server Cluster TFS Cluster Cache Cluster Cache Cluster TFS Cluster ~20T ~50T ~200 Servers 600T Used / 1500T Deployed
- 5. 2007年之前的图片存储系统 5 FAS980C SnapShotSnapShot 杭州网通 IDC Upload Server 滨江联通备份中心 NearStore R200 DR: A+B+C+D SnapVault 远程数据冗灾 Image Server C: Online Image D: Online Image SnapMirror FAS980C SnapShotSnapShot A: Online Image B: Online Image SnapMirror 注：红框中设备是2006年的新增设备， 明年还得在原有的 NetApp 980C/R200 存储上增加 20TB 左右新的硬盘容量。 Admin Server
- 6. 商用产物无法满足需求 ? 系统需求 ? 淘宝的影响越来越大，数据的安全也更加重要 ? 数据存储量以每年二倍的速度增长（即原来的三倍） ? 商用存储产物 ? 对小文件的存储无法优化 ? 文件数量大，网络存储设备无法支撑 ? 连接的服务器越来越多，网络连接数已经到达了网络存储设 备的极限 ? 扩容成本高，10T的存储容量需要几百万￥ ? 单点，容灾和安全性无法得到很好的保证 6
- 7. TFS 1.0 ? 2007年6月 淘宝自主开发的分布式的文件系统 TFS（Taobao File System）1.0上线运行 主要解决海量小文件的分布式存储 集群规模：200台PC Server(146G*6 SAS 15K Raid5) 文件数量: 亿级别 系统部署存储容量: 140 TB 实际使用存储容量: 50 TB 单台支持随机IOPS 200+，流量3MBps 7
- 9. TFS1.0的特性 ? 集群由一对Name Server和多台Data Server构 成 ? 每个Data Server运行在一台普通的Linux主机上 ? 以block文件的形式存放数据文件(一般64M一个 block) ? block存多份保证数据安全 ? 利用ext3文件系统存放数据文件 ? 磁盘raid5做数据冗余 ? 文件名内置元数据信息，用户自己保存TFS文件名 与实际文件的对照关系 9
- 10. TFS 1.3 ? 2009年6月 TFS（Taobao File System）1.3上线运行 ? 集群规模 ?440台PC Server (300G*12 SAS 15K RPM) ?文件数量： 百亿级别 ?系统部署存储容量： 1580 TB ?当前实际存储容量： 600TB ?单台Data Server支持随机IOPS 900+，流量15MB+ 10
- 11. TFS1.3的逻辑结构 11 Application/Client NameServerblock id, file id/ allocate Data control messageheartbeat message crc,sizefilename refcount dataserver id (block id, file id) hda DataServer dsp1 hda hda dsp2 dsp3 hda DataServer dsp1 dsp2 dsp3 hda hda ?Mysql Dup Store NameServer heartbeat message HA heartbeat
- 15. 图片处理与缓存 ? 现状 –有200多台服务器Image Server，在Apache上实现 的，从TFS取原图生产相应的缩略图 ? 改进目的 –图片访问的热点一定存在，在Image Server实现 Cache ，提高响应速度，也减轻对后端TFS的压力 ? Image Server上处理方式 –若请求图片在Cache中，直接发送 –没命中，若本地有原图，则根据原图做处理并缓存 –没命中，从TFS读取原图并添加到缓存，处理并缓存
- 16. 系统实现 ? 将图片处理与缓存编写成基于Nginx的模块 –Nginx是目前性能最高的HTTP服务器（用户空间） –代码清晰 –模块化非常好 ? 使用GraphicsMagick进行图片处理 –比ImageMagick性能更好 ? 面向小对象的缓存文件系统 ? 前端有LVS+Haproxy将原图和其所有缩略图请求 都调度到同一台Image Server
- 17. 图片处理 ? 从TFS存储中读取文件 ? 将文件根据需要的尺寸进行缩放 ? 可根据需要将缩略图按一定质量压缩保存（75% ～94%），通过配置文件设定 –可有效地降低缩略图的体积（30%~70%） –节约传输的带宽
- 18. 本地缓存对象文件系统 ? 文件定位 –内存hash做索引 –最多一次读盘 ? 写盘方式 –Append方式写 –淘汰策略FIFO，主要考虑降低硬盘的写操作，没有必 要进一步提高Cache命中率，因为Image Server和 TFS在同一个数据中心
- 20. 淘宝CDN系统 ? CDN服务的图片规模 –150T容量的原图 + 150T容量的缩略图 –200亿左右的图片数，平均图片大小是15K –8K以下图片占图片数总量的53%，占存储容量的15% ? CDN部署规模 –20个节点，部署在网民相当密集的主要中心城市 –每个节点目前处理能力在4~10G –CDN部署的总处理能力已超过150G –目前承载淘宝流量高峰时119G，和一些集团子公司的 流量 20
- 22. CDN节点的架构对比-老架构 22 NetScaler(7LB) squid 源站 squid squid … squid NetScaler(7LB) client 频道频道1 频道2 … 频道n VIP1 VIP2
- 23. CDN节点的架构对比-新架构 23 LVS(L4) Haproxy(L7) squid 源站 squid squid … squid haproxy(L7) Haproxy(L7) LVS (L4) client 所有频道统一调度 VIP1 VIP2 心跳
- 24. CDN节点的架构对比 对比项 节点 新架构 老架构 流量分布均匀性 ☆☆☆☆☆ ☆☆☆ 可维护性 ☆☆☆ ☆☆☆ 抗攻击能力 ☆☆☆☆ ☆☆☆☆ 自主控制能力 ☆☆☆☆☆ ☆☆☆ 价格 ☆☆☆☆☆ ☆☆☆ 扩展能力 ☆☆☆☆☆ ☆☆ 灵活性 ☆☆☆☆☆ ☆☆ ?流量分布均匀性：所有的频道统一调度到128台squid，而不是将squid按频 道分组，可提高命中率2%以上 ?扩展能力：在一个VIP上新架构可以扩展到近100G的流量（当然要用万兆 网卡） ?灵活性：一致性Hash调度方法使得增加和删除服务器非常方便，只有 1/(n+1)的对象需要迁移
- 25. Squid改进和优化 ? 改进后的Squid可支持1T大小的COSS文件（ blocksize为512 Bytes） ? Squid内存优化，一台Squid服务器若有一千万对 象，大约节省250M内存，更多的内存可以用作 Squid Memory Cache ? 改进Squid的对象淘汰策略，在不牺牲对象命中率 的前提下，降低硬盘的写操作 ? 用sendfile来发送缓存在硬盘上的对象 ? 在Squid服务器上使用SSD作缓存，对数据量比较 小的图片非常有效 25
- 26. 节点运行情况 ? 节点规模：32台 DELL R710服务器 ? 逻辑结构：2 LVS + 32 Haproxy + 128 Squid ? 时间：12月21日上线运行 ? 当前最大服务流量：10.58 Gbps ? 理论最大负载能力：15Gbps以上 ? 单台R710服务器可到500Mbps以上的吞吐率 ? 单squid最大object数目：1000万 ? Cache请求命中率：97% ? Cache字节命中率：97% ? 最重要的是命中率提高，大大改善用户的访问体验 26
- 29. 低功耗硬件平台 ? 低功耗硬件平台 –低功耗的CPU，如Intel ATOM, VIA Nano等 –低功耗的Chipset；SSD或低功耗的SATA硬盘 –关闭GPU和USB Controller等 ? 适用不需要太多CPU计算的I/O类型应用 –例如CDN Cache Server、memory cache、存储节点、 静态文件Web Server等 ? 好处（大大降低成本）： –降低电力消耗，减少碳排放 –单位空间(机柜)下有更高的I/O吞吐率 –降低硬件购置成本和运营成本 29
- 31. 单机柜(6Gbps)方案:节点机架布局 42U 5U 低功耗服务器 1U 负载均衡服务器 5U 低功耗服务器 1U 负载均衡服务器 40U 1U 交换机 5U 低功耗服务器 5U 低功耗服务器 1U 交换机
- 33. 经验 ? 采用开源软件与自主开发相结合 ? 规模效应，研发投入都是值得的 ? 可以在软件和硬件多个层次优化 ? 优化是长期持续的过程 33
- 34. 讨论 34 Q & A 谢谢!