淘宝技术架构介绍, 了解淘宝,了解淘宝的架构需求
pipeline 页面布局
Screen Layout Control
多模板引擎
Jsp Velocity FreeMarker
V2.0 淘宝项目管理工具 AntX
类似maven 脚本编程语言 AutoConfig 依赖管理，冲突检测
V2.1 的需求
提高性能 增加开发效率 降低成本
V2.1 2004.10 – 2007.01
TBStore
Read/Write
Oracle Oracle Oracle Oracle
dump
Search
Read/Write
Node Node
1
2 ……
Node n
V2.1逻辑结构
表示层
Service
业务请求转发
Framework
S
UC
UC 业务流程处理 UC
UC
P
R
AO
AO
AO
AO
I
业务逻辑层
Node 1
Node 2
Node n
V2.1 TaobaoCDN
squid apache+php lighttpd 静态页面（包括php页面）、图片、描述 最初只有杭州和上海两个站点 现在发展到北京、广州、西安、天津、武
汉、济南等近10个站点 现在每天高峰期30G流量/秒
V2.1 session框架
Put/Get Data
Node 1
Node 2
Node n
V2.2 搜索引擎
垂直/水平 分割
AAPPPP
AAPPPP
Merge
Node1
Node2 ……
Node n
Col1
Node 1
Node 2
……
Node n
Col2
Node 1
Node 2
……
Node n
Col n
Node 1
Node 2
……
Read/Write
Search
Oracle Oracle dump
Oracle Oracle
Node Node
1
2
Read/Write ……
Node Node
1
2
Node n
Node n
V2.2 TFS
类似GFS
支持数据紧缩 支持数据去重 去重后：
Lookup NNNaomoddee1eS1erver
V3.0 消息系统 Notify
Topic方式
发送事务
A后PP续
处理1
2亿消息/天
送达率：99.99%
A续PP后
处理2
操作
A业PP务 系统
消息
A消PP息 系统
AP…P…
V3.0 可用性
同城分流幵容灾 异地容灾
主业务
可切换
边缘业务
主机房一
主机房二
数据同步
异地主机 房
自劢化/智能化
Boy: I wanna the fried chicken! HSF: Sir, we will be arriving at
非功能需求 高可维护性
对淘宝技术架构的原始需求
高稳定性 高容量 高性能 高可维护性
淘宝发展历程
2500 2000 1500 1000
500 0
2008年每天：
增加800G的数据 高峰期流量超过30G/S 处理超过1000G的日志 处理40亿次的用户信息访问 缓存处理60亿次的请求
2008年：
功能分组3
Node 1
Node 2
……
Node n
Node 2
……
Node n
Node 2
……
Node n
服务2
功能分组1
Node1
功能分组2
Node1
Node2
……
Node n
Node2
……
Node n
V3.0 服务化
服务导向框架 按功能形成服务中心 产品化管理 服务中心承载了70亿/天的请求
单台服务器最高可承载1.5亿/天的请求
淘宝总共
超过22TB的宝贝图片存储 超过4亿条的在线交易记录，超过2亿的在线宝贝
非功能需求
高容量 高性能
淘宝是什么样的很大的交易网站？
淘宝是一个高速发展的很大的交易网站 2008Q3
发布项目15个 发布日常285个 发布模板440次
2008Q4
发布项目49个 发布日常1149个 发布模板1909次
the nearest KFC soon.
演进
应用
1.4 -> 1.5 -> 1.6 JSP -> Velocity… EJB +自主IoC容器-> Spring -> 淘宝服务框架 HSF 开源OR-Mapping框架(Ibatis ...) -> 淘宝数据层 TDDL 庞大的项目 -> 按功能拆分+ 服务化/产品化 紧耦合 -> 使用消息系统解耦
复制
Read
Slave2
V1.1 过渡版本
V1.0问题
数据库容量限制 数据稳定性
V1.1需求
解决数据库性能问题 为V2做好准备
V1.1 2004.1 – 2004.5
MySQL迁移至Oracle 引入SQL Relay中间件 迁移阶段开发人员写两种SQL
V1.1
Function F4unction 3
70T数据
Hear Beat
现在每天增加300G
NNooAddePe1P1 Put/Get Data
NNooddee 11
NNooddee 22
NNooddee nn
V2.2 TDBM/Tair
基亍劢态哈希算法 性能超越memcache
更多的系统资源消耗
Lookup
NNooAddePe1P1
CNoNonodfideg1eS1erver Hear Beat
淘宝技术架构介绍
2009.6
目标
了解淘宝，了解淘宝的架构需求 了解淘宝的技术演变 了解一些约束
淘宝是什么？
淘宝是一个网站
WebServer
AppServer
DBServer
淘宝是什么网站？
淘宝是一个交易网站 交易
要素
人 物 合同（订单）
过程
匘配过程 交易过程
付款 发货
沟通交流
Function 3
Weblogic
Function 2
Weblogic
Function 1
WebX
Weblogic
WebX
Weblogic
EJB
WebX
EJB
WebX
Ibatis
EJB
Ibatis
EJB
Ibatis
Ibatis
Read/Write
Oracle
dump
Search
Node 1
Node
Session框架
支持集中方式、复制方式等 对代码透明
V2.2 需求
提高系统性能 降低存储成本 支撑海量数据的搜索
V2.2 2006.10 – 2007.12
分布式存储 TFS 分布式缓存 TDBM 前端页面缓存 ESI 搜索引擎升级
V2.2
…… 淘SJIF宝bpBuaroMnitnsicsVsgtiSCWoIJbpBnearoibt3nsFiXssgunctSiWJIobpBnearoibt2nsiXFssgunctioIbWSJnpaBetr1oibisnsXsg
V1.0 2003.5 – 2004.1
2003年非典时期 马于住宅 LAMP MySQL读写分离
V1.0
Function Function 2
Apache mod_php4
Apache
pear DB
mod_php4
pear DB
Read
Read/Write
Slave1
复制
MySQL Master
Forest
……
持久层(DB/TFS/NAS)
约束
上可依赖下 下丌可依赖上 上可跨级依赖下 平级可依赖，但丌推荐，禁止循环依赖 使用Notify和页面的依赖，无限制 高级别丌可依赖低级别 简单就是美
谢谢！
功能需求
交易系统
非功能需求 高稳定性
淘宝是什么样的交易网站？
淘宝是一个很大的交易网站 每天
7亿次的页面访问，其中搜索宝贝过亿次，浏览宝贝过亿次 超过40亿次的用户访问，超过6亿次的交易访问，超过6亿ቤተ መጻሕፍቲ ባይዱ的宝贝访问 超过400万笔有效交易
高峰期
每秒超过25G的流量，核心业务每秒超过4.5G的流量 每秒生成几百笔交易，8万次的用户访问，1.5万次的商品访问
Apache
Function 2
Apache
Function 1
mod_php4
Apache
mod_php4
Apache
pear DB
mod_php4
pear DB
mod_php4
SQL Relay
pear DB
SQL Relay
pear DB
SQL Relay
SQL Relay
Oracle
V1 问题
N
BO
BO
BO
BO
G
DAO
数据持久层
DAO
DAO
DAO
Oracle
Oracle
Oracle
V2.1 数据可伸缩
垂直（按业务） 核心
水平（按规则）
业务 数据
……
核心及大数据量
淘宝技术架构分享
，HSF 使用的时候需要单独的下载一个hsf.sar 文件放置到jboss 的
；弊端也很明显：增加了环境的复杂度，需要往jboss 下扔sar
设计的主要原因。HSF 工作原理如下图：
HSF SAR 文件到Jboss 的Deploy 目录。
大型分布式的基础支撑。使开发人员无需过多的关注应用是集中式的，还是分布式的，可以更加专注于应用的业务需求的实现，这些纯技术
的需求都由HSF 来解决。
（2）HSF 的系统架构
I. HSF 交互场景图
客户端（消费端）从配置中心获取服务端地址列表—>和服务端建立连接开始远程调用—>服务端更新通过notify（类似B2B 的naplio）
系统通知客户端。服务端和客户端都有对应的监控中心，实时监控服务状态。客户端，配置中心，服务端，notify，之间的通信都是通过TB Remotion
API 去搞定的。
II. TB Remoting 架构图
底层基于分布式框架Mina，主要的代码都是通过
B2B 的Dubbo 也是基于这个NIO 框架的。Mina
商品，付款，确认，退款，评价，社区互动等。
产品：淘宝对产品定义和B2B 有差别，淘宝的业务拆分较细，服务化做的较成熟，所以前台应用对应的业务非常纯粹，如Detail 系统可
能就一个detail 页面，无数据库连接，所有数据来自底层的各种服务化中心，功能专一逻辑清晰纯粹，不过也正因为这样，淘宝的一个产品
淘宝前端应用
HSF接口
UIC IC SC TC
PC
Forest 推送给“淘宝前端应用”
淘宝共享服务
淘宝技术架构简介
• 价值
– 用同步的语义来实现异步的调用
ngx_lua原理
• 每个Nginx工作进程使用一个Lua VM，工 作进程内所有协程共享VM • 每个外部请求都由一个Lua协程处理，协程 之间数据隔离 • Lua代码调用I/O操作接口时，若该操作无 法立刻完成，则打断相关协程的运行并保 护上下文数据 • I/O操作完成时还原相关协程上下文数据并 继续运行
系统过载保护
• 判断依据
– 系统的loadavg – 内存使用（swap的比率）
• sysgurad模块
sysguard on; sysguard_load load=4 action=/high_load.html; sysguard_mem swapratio=10% action=/mem_high.html
– 防hashdos攻击 – 防SQL注入 – 防XSS
• 标准Nginx无输入体过滤器机制的问题 • 例子（防hashdos攻击）
– 如果所有POST内容都在内存中，占用内存过大 – 否则性能不高，内容可能被buffer到磁盘 – /2012/01/amechanism-to-help-write-web-applicationfirewalls-for-nginx/
ngx_lua原理
代码示例
location /http_client { proxy_pass $arg_url; } location /web_iconv { content_by_lua ' local from, to, url = ngx.var.arg_f, ngx.var.arg_t, ngx.var.arg_u local iconv = require "iconv" local cd = iconv.new(to or "utf8", from or "gbk") local res = ngx.location.capture("/http_client?url=" .. url) if res.status == 200 then local ostr, err = cd:iconv(res.body) ngx.print(ostr) else ngx.say("error occured: rc=" .. res.status) end '; }
浅谈淘宝类目属性体系：商品搜索背后的逻辑架构
浅谈淘宝类目属性体系：商品搜索背后的逻辑架构[核心提示] 淘宝拥有百万家商户和超过10亿的商品数，它如何让用户精准地找到想要的商品呢？其背后有着强大的技术支撑。
淘宝目前在线商品数超过10 亿，如何精准的帮助用户找到他想要的商品呢？经过多年的探索，淘宝通过建立一套完整的类目属性体系，终于较好的解决了这一问题，今天就跟大家一起来谈谈淘宝的类目属性体系。
一点点历史和架构2003 年淘宝刚上线时，商品量很少，没有分类。
后来，商品量上百，开始有了对商品进行单级分类，有点类似于现在的一级行业类目。
等到商品上万的时候，商品的单级分类已经不能满足需求，开始有了多级分类，就是一颗类目树了。
从06 年开始引入了属性，商家按照属性模板填写属性，用户可以按照属性筛选商品。
到了08 年，开始将前后台类目分开，用户根据前台类目筛选商品，商家将商品挂到后台类目上，前后台类目树之间建立好映射。
今天的淘宝类目属性体系主要由后台类目树、前台类目树、挂载在后来叶子类目上的商品属性模板以及管理前后台类目之间映射关系的类目管理平台组成，整体架构如下：从图中可以看出，淘宝类目属性体系是一个非常基础的数据服务，在商品发布页上商家选择后台类目上传商品信息，详情页上以面包屑的方式给用户显示商品所属的前台类目，在搜索结果页上让用户根据前台类目筛选商品。
运营同学可以通过一个管理后台来管理前后台类目之间的映射关系以及后台类目的属性模板。
后台类目后台类目面向商家，主要用于商品的分类和属性管理。
商家上传商品时见到的就是后台类目，如下图：后台类目有如下特点：后台类目树中最重要的是叶子类目，也就是类目树上不能再往下分的类目,任何商品都必须挂载到后台叶子类目上。
叶子类目挂载属性模版，商家发布商品时选择好类目之后会根据属性模版，补充必填的商品属性信息，方可成功上传商品。
后台类目相对稳定，不能随便删除，叶子类目不能重复。
前台类目前台分类面向用户，方便用户筛选查找商品，大部分时候用户见到的类目都是前台类目。
淘宝系统功能及网站结构
当当网的系统功能：1.客户服务系统当当网建立了功能强大的客户服务中心。
当当网以网上购物为主要的经营手段，用户与商家最为直接交流莫过于电话，因此，建立一个完善的客户服务中心是用户必须的。
当当网呼叫中心系统在保证话务质量的同时具有相当的规模，并随着业务的不断增大，还可以平滑的升级；所采用的呼叫中心系统完全摆脱了传统呼叫中心系统的羁绊，建立了一套基于IP的分布式呼叫中心平台，同时，可以实现高质量的话务统计。
2.智能比价系统当当网开发了智能比价系统系统。
通过此系统，当当网每天都实时对各电子商务网站的同类商品的价格进行对比。
如果对方同类商品价格低于当当网商品价格，此系统将自动调低当当网同类商品的价格。
3.相关搜索系统当当网购物系统根据客户的购物习惯自动向他们推荐相关商品。
如今当当网客户的搜索范围不仅包括当当网近百万自营商品，还把当当数千家店中店的各类商品一搜到底4.物流配送系统当当网在这180个城市拥有物流合作伙伴。
这些合作伙伴可能只是一家只有数十人的小快递公司，服务范围可能仅仅是它所在的城市。
但当当网成功的将这些物流合作伙伴整合成一个覆盖全国的物流网络，向180个城市提供送货上门和货到付款服务，并且覆盖的城市还在增加。
当当网在北京、上海、广州3个城市设立了仓储中心。
当一笔订单产生时，当当网将判断从那个仓库调货最优，然后订单被发送到用户所在的城市，该城市的快递公司收到货后立即送货上门。
当当网对于这些快速公司怎么搭配发送包裹一向不作要求，唯一的要求就是在特定的时间内将货物送到。
5.支付系统当当网其主要的支付方式有：a.货到付款：快递公司把商品送至指定地点时，由收货人当时交付货款和运费。
b.银行汇款：用户可以通过银行汇款、转帐的方式汇款至当当网。
c.邮局汇款：全国邮政服务范围所能覆盖的国内省、市、自治区、直辖市的客户均可以选择此方式支付。
d.信用卡支付：用户使用几种指定的信用卡付款。
当当网还设立了专门的论坛。
技术选型tb的描述 -回复
技术选型tb的描述-回复技术选型是指在项目或产品开发过程中，根据特定的需求、目标和条件，选择最适合的技术框架或工具。
本文将围绕着“技术选型tb的描述”这个主题展开讨论，重点侧重于tb（淘宝）这一电商平台的技术选型及相关方面的介绍。
一、淘宝的背景与介绍淘宝是中国最大的综合性电子商务平台，于2003年由阿里巴巴集团创立。
淘宝以C2C模式为基础，打造了一个拥有数亿用户的购物平台。
随着互联网的快速发展和消费行为的改变，淘宝不断优化和升级自身的技术架构，以应对日益增长和复杂化的业务需求。
二、技术选型的重要性技术选型在电商平台的开发和运营中扮演着重要的角色。
通过合理的技术选型，可以提高系统的性能和稳定性，降低系统的开发和运维成本，优化用户体验以及提升系统的可扩展性。
三、淘宝的技术架构1. 分布式架构：淘宝采用了分布式架构来应对高并发的访问量和海量的数据处理需求。
通过将业务按照不同的功能分解成独立的模块，并采用分布式计算和存储的方式，使得系统能够快速扩展和横向伸缩。
2. 高可用性和容错性：淘宝通过引入容灾机制和高可用性设计来保证系统的稳定运行。
例如，采用分布式缓存和负载均衡等技术，以及多活数据中心部署和数据冗余备份策略等，确保了系统在单点故障或数据中心级别故障时的高可用性和容错性。
3. 数据挖掘和智能推荐：淘宝依托阿里巴巴集团强大的技术能力，构建了一套完整的数据挖掘和智能推荐系统。
通过大数据分析和机器学习算法，淘宝能够根据用户的历史行为和偏好，提供个性化的商品推荐和搜索结果排序。
4. 移动化支持：随着移动互联网的普及，淘宝将移动化作为重点发展方向。
淘宝借助大数据和云计算等技术手段，构建了移动端的技术架构，包括手机客户端和移动Web应用等，以提供便捷的购物体验和丰富的移动服务。
四、技术选型的考虑因素在进行技术选型时，淘宝考虑了以下几个重要因素：1. 可扩展性：淘宝需要能够应对数亿用户的同时访问需求，因此选用的技术框架必须具备良好的可扩展性，能够支持大规模并发和海量数据处理。
淘宝商城(天猫)组织结构图
淘宝商城(天猫)组织结构2012年5月一、商城组织结构二、工作内容（一）运营经理1、负责网店整体规划、营销、推广、客户关系管理等系统经营性工作；2、负责网店日常改版策划、上架、推广、销售、售后服务等经营与管理工作；3、负责网店日常维护，保证网店的正常运作，优化店铺及商品排名；4、负责执行与配合公司相关营销活动，策划店铺促销活动方案；5、负责收集市场和行业信息，提供有效应对方案；6、制定销售计划，带领团队完成销售业绩目标；7、客户关系维护，处理相关客户投诉及纠纷问题。
(二)客服人员1、通过在线聊天工具，负责在淘宝上和顾客沟通，解答顾客对产品和购买服务的疑问；2、产品数据在线维护管理，登陆销售系统内部处理定单的完成，制作快递单，整理货物等；3、客户关系维护工作，在线沟通解答顾客咨询，引导用户在商城上顺利的购买，促成交易；4、负责客户疑难订单的追踪和查件，处理评价、投诉等。
(三)配送人员1、负责网店备货和物资的验收、入库、码放、保管、盘点、对账等工作；2、负责保持仓库内货品和环境的清洁、整齐和卫生工作；3、按发货单正确执行商品包装工作，准时准确完成包装任务；4、准确在网店后台输入发货单号，更改发货状态，对问题件能及时处理。
(四)网店美工1、负责网店产品上传宝贝的文字编辑及上传宝贝的相关工作，图片拍摄制作。
2、根据主题需要完成店铺进行整体的美化(公告栏和促销栏图片设计)。
3、根据文字需求完成网页平面设计，完成网页html编辑。
4、产品拍摄图片的美化、编辑排版；(五)网店财务员1、负责网店销售与资金到账的管理；2、负责网店与快递公司业务费用的管理；3、负责网店日常运营财务方面的处理；(六)网店推广员1、负责不定期策划淘宝商城营销活动；1、负责公司淘宝交易平台推广工作；2、策划并制定网络店铺及产品推广方案（包括淘宝推广、SEO、论坛推广、博客营销、旺旺推广等）等营销工作；3、研究竞争对手的推广方案，向运营经理提出推广建议；4、对数据进行分析和挖掘，向运营经理汇报推广效果；5、负责对店铺与标题关键字策略优化、橱窗推荐、搜索引擎营销、淘宝直通车、淘宝客等推广工作。
淘宝top平台架构 介绍
TOP架构设计实例分享
•服务分流与隔离
•原因：服务简单负载均衡造成服务互相影响。（根本原因 是服务的质量直接影响TOP处理能力和资源分配） •处理模式进化：
二级域名
软负载
软负载&虚 拟服务组
13
TOP架构设计实例分享
•服务分流与隔离
二级域名
• 隔离效果明显 • 配制僵化 • 性能基本无损失
软负载
– 作用
• 数据操作可控，保护终端用户隐私（结合cookie和标签，控制ISV业务数据操 作尺度，提高数据安全性） • 提供标准业务流程标签，简化开发者对于业务流程理解过程。 • 标签化接口方式，完成数据获取和页面渲染，后台业务升级对ISV透明化。 • 标签获取客户端信息，将监控扩展到整个业务请求过程。 • 制定行业化标签库，形成统一开发标准
APP
TOP
Service Provider
APP
业务数据交换通道
Service Provider
8
TOP架构Leabharlann 计实例分享• 异步交互服务 & 通知服务
• 保持会话，支持异步响应。（短信服务） • 异步延时服务。（大数据量信息返回）
• 订阅关系维护，支持通知服务。（系统间数据同步）
TOP架构设计实例分享
•
•
TOP商业驱动模式介绍
End User
插件分成
AppStore订购
开发者按业务分类
淘宝插件
店铺插件 淘宝SNS插件
免费TOP外部插件
社区插件 外部SNS插件
收费应用
客户端 独立WEB应用 新平台应用
自用型应用
独立网店 社区站点 导购网站
插件分成
动态广告
淘宝运营思路及架构
客户沟通，做好换货或退款事宜。极力避免缺货没有及时和 客户沟通导致客户严重不满的情况出现。
组织架构示意图
店长
网
天
推
物
美
客
店
猫
广
流
工
服
编
专
人
发
设
人
辑
员
员
货
计
员
项目 类别
项目
淘宝店铺常规运营列表
概述
店铺设置流程及重点操作内 费用项 项目
容提示
操作
权重
侧重于是标题 负责新上架商品根据淘宝网
关健字运用， 内部排名规律进行 SEO 关键
照成交付费。 客相关论坛。
超级卖霸专题
\活 动 的 开 式
进行集中展示，
并整合淘宝优
质广告资源进
行强力推广：
超级卖霸
超级卖霸活动
现有展位价格大约为万元以
每季度都会定
2000-1
内，活动推广周期七天，费
期推出不同的
0000/
用较高
专题活动，每
次
辅助
期活动也会依
据不同类型的
卖家定义的价
格，开始价格
略高，其后的
门搜索关键词
查询自己的宝
数据魔方 标准版
贝排在淘宝第 几页，比较同 运营推广部 类宝贝的价格
和销量，了解
别人为什么可
以卖得那么好
30 元/ 辅 季助
辅助
直通车
淘宝直通车是 运营推广部
每天限 常规
淘宝网为淘宝 １、直通车活动的参加：目 额 200，
卖家量身定制 前淘宝频道布页，淘宝搜索 预计
的推广工具， 首页等“热卖单品”均为直 6000/
淘宝技术架构演进之路
淘宝技术架构演进之路1. 概述本⽂以淘宝作为例⼦，介绍从⼀百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让⼤家对架构的演进有⼀个整体的认知，⽂章最后汇总了⼀些架构设计的原则。
特别说明：本⽂以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并⾮是淘宝真正的技术演进路径2. 基本概念在介绍架构之前，为了避免部分读者对架构设计中的⼀些概念不了解，下⾯对⼏个最基础的概念进⾏介绍：分布式系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上⾼可⽤系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有⾼可⽤性集群⼀个特定领域的软件部署在多台服务器上并作为⼀个整体提供⼀类服务，这个整体称为集群。
如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成⼀个整体提供集中配置服务。
在常见的集群中，客户端往往能够连接任意⼀个节点获得服务，并且当集群中⼀个节点掉线时，其他节点往往能够⾃动的接替它继续提供服务，这时候说明集群具有⾼可⽤性负载均衡请求发送到系统时，通过某些⽅式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的正向代理和反向代理系统内部要访问外部⽹络时，统⼀通过⼀个代理服务器把请求转发出去，在外部⽹络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进⼊系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。
简单来说，正向代理是代理服务器代替系统内部来访问外部⽹络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。
3. 架构演进3.1 单机架构以淘宝作为例⼦。
在⽹站最初时，应⽤数量与⽤户数都较少，可以把Tomcat和数据库部署在同⼀台服务器上。
淘宝网图片存储系统架构
本文侧重介绍淘宝网后台的图片存储系统架构、包括TFS 集群文件系统，以及前端处理服务器架构。
解决海量并发小文件的系统噩梦对于淘宝网这类型访问量极高的电子交易网站来说，对图片系统的要求和日常的照片分享完全不在一个级别。
日常照片分享往往集中在几个有限的亲朋好友之间，访问量不会特别高，而淘宝网商铺中的商品照片，尤其是热门商品，图片的访问流量其实是非常大的。
而且对于卖家来说，图片远胜于文字描述，因此卖家也格外看重图片的显示质量、上传时间、访问速度等等问题。
根据淘宝网的流量分析，整个淘宝网流量中，图片的访问流量会占到90%以上，而主站的网页则占到不到10%。
淘宝网电子商城首页截图，淘宝网的后端系统上保存着286亿多个图片文件，淘宝网整体流量中，图片的访问流量要占到90%以上。
且这些图片平均大小为17.45KB，小于8K的图片占整体图片数量61%，整体系统容量的11%与此同时，这些图片的存储与读取还有一些头疼的要求：例如，这些图片要求根据不同的应用位置，生成不同大小规格的缩略图。
考虑到多种不同的应用场景以及改版的可能性，一张原图有可能需要生成20多个不同尺寸规格的缩略图。
淘宝整体图片存储系统容量1800TB（1.8PB），已经占用空间990TB（约1PB）。
保存的图片文件数量达到286亿多个，这些图片文件包括根据原图生成的缩略图。
平均图片大小是17.45K；8K以下图片占图片数总量的61%，占存储容量的11%。
这就给淘宝网的系统带来了一个巨大的挑战，众所周知，对于大多数系统来说，最头疼的就是大规模的小文件存储与读取，因为磁头需要频繁的寻道和换道，因此在读取上容易带来较长的延时。
在大量高并发访问量的情况下，简直就是系统的噩梦。
分析自主研发和商用系统的经济效益淘宝网成立于2003年，在整个系统的构建和规划上也做过相当多的尝试和探索。
下图是淘宝网2007年之前的图片存储系统。
淘宝网之前一直采用的商用存储系统，应用NetApp公司的文件存储系统。