淘宝商品业务及技术架构介绍

1、伯雷伯雷20102010年年4 4月月淘宝网商品业务及技术架构介绍目录商品商品概概述述业务业务系系统统基基础础框架框架数数据据层层你还你还需要了解的需要了解的面面临临的挑的挑战战商品商品概概述述商品基础几组商品相关的数字商品组成（8+1）一基本二交易类型三组织形式四销售特征五物流六描述七状态八图片九其他商品生命周期类目属性体系图片业务业务系系统统从商品流通的角度-商品流通的全景图商品状态简图商品状态转换全景图商品流通全景图主要业务系统依赖关系图细化商品流通全景图中的各个系统一应用定位及职责（覆盖人群）二包含的业务及核心业务的主流程三从架构和技术特点（分层、依赖、网络拓扑结构、数据源等）来描述应

2、用四目前存在的问题及挑战五未来发展方向基基础础框架框架因何而在框架职责架构及技术特点数数据据层层DB架构商品核心(Domain)类目属性图片的存储及硬件部署描述的存储你还你还需要了解的需要了解的TFS/ImageTairJAVA Page CacheUIC/TC/DC/SC/PCHsf/notify面面临临的挑的挑战战海量商品的管理（存储、检索、管理、调控、组织、安全、分级等）快速搭建垂直市场、动态内容推荐区 - 个性化的导航+动态内容推荐秒杀等业务对系统造成的巨大冲击稳定、高速、支持更庞大节点的类目属性体系一个真正强大的后台，聚合了数据报表、数据挖掘/商机发现、商品调控、商品管理等功能的一个

3、指挥中心；使得对淘宝的商品进行宏观和微观调控成为可能，彻底改变目前后台只有商品管理功能的原始局面。Part1 商品概述商品概述 在淘宝网，通过C2C或B2C等渠道销售的一切物品，包括有形（手机、服装等）、无形（游戏币、充值卡等）的物品。 淘宝销售的商品属于零售类商品; 与阿里巴巴B2B在企业间销售的工业品、原材料等商品，构成了电子商务商品销售的两大类型几组商品相关的数字一商品数量商品目前在线的商品总数在5亿左右；历史库的商品总数将近40亿。同期其他主要的竞争对手，例如拍拍、有啊，商品总数仅在千万左右。一覆盖类目种类繁多，目前一级类目有56个；几乎所有的零售类商品都可以在淘宝上购买得到一CRUD

4、每天新增的商品总数在5-8百万左右；商品每天被搜索的次数：8亿次以上，商品每天被查看的次数：2.5亿次；卖家每天更新商品量：8千万次左右；每天被删除的商品总数估计在2-3百万左右一成交淘宝商品每天的销售总额在6亿左右（2010年4月份统计的数据），成交笔数在500万笔左右。其中2010年Q1的总成交额是500亿。商品组成（8+1）商品组成（8+1）：基础商品id商品id分为两种，一种是数字id，一种是32位字符串id。都是卖家在发布商品的时候，分别通过DB和JAVA程序来生成。数字id的规律是，看数字id是否能被2整除，能整除的是db2,不能整除的是db1。所属用户目前商品库的分库分表按照用户

5、id来划分，不是按照商品id 商品组成（8+1）：交易类型一口价一口价是淘宝最简单，也是最主流的交易类型，占据了淘宝交易额的绝大部分。一口价比较简单，按照固定的销售周期来上架、交易。商品组成（8+1）：交易类型拍卖拍卖是一种特殊形式的交易类型，卖家设置一个起拍价，买家在缴纳了保证金的基础之上，不断加价，最后价高者得商品。根据拍卖商品的数量，拍卖又分为单件拍和荷兰拍，规则各不相同。商品组成（8+1）：交易类型团购团购是一种已经被取消的交易类型（五彩石），目前不再介绍了商品组成（8+1）：组织形式商品的组织形式，我们目前采用的是类目属性体系。类目能够起到分类商品的作用，属性能够起到用标准化的结构来

6、描述商品的作用，以便于商品能够快速的被查找、检索。在下面会有一个详细的章节来讲述商品的类目属性体系。商品组成（8+1）：交易关键信息价格起拍价（currentBid）当前价格（reservePrice）价格相关的衍生业务：一、价格体系二、类目价格限制三、自定义价格区间四、SPU价格限制商品组成（8+1）：销售周期 销售周期销售周期是淘宝非常重要的一个基础概念，用于控制商品的上下架、排序。销售周期只有两个值，7天或14天。销售周期开始时，商品即可以上架展示；到期时商品将会下架。销售周期这个概念，衍生出的相关业务/规则有：自动重发、搜索展现和排序等 自动重发 销售周期结束后，商品即要下架。这对于卖

7、家而言，会大大增加商品管理的难度，卖家希望没有销售周期这种概念，商品永远能够在线销售。因此最早阿里软件开通了一个叫自动重发的业务，卖家在每个月缴纳5块钱之后，淘宝即通过时间程序将到期的商品重新上架。 时代在变，规则不变，但技术在进步。现在已经不再需要通过时间程序来将到期商品重新上架。对于搜索引擎，可以通过一些简单的算法计算出商品新一轮的销售周期，从而使得商品可以在该时间点能够被搜索到；对于detail等应用，可以结合卖家和商品开始时间等因素计算出商品的销售时间。搜索展现和排序 销售周期开始时，商品即在搜索引擎中能够被检索得到；主搜的默认排序中，第三排序字段是商品销售周期，按照结束时间倒序排列。

8、至于第一排序字段，以下讲解hesper应用时会有提及。商品组成（8+1）：销售周期开始销售时间（starts）表示第一个销售周期的开始时间，从这个时间开始，商品即可以在淘宝展示（能被搜索、被查看）。以后每一轮新销售周期，都是从本时间开始。开始销售时间的衍生业务包括定时上架、秒杀等。控制销售周期的开始时间，对于卖家有非常重要的意义。交易高峰期能够排在前面的商品，被查看/成交的可能性相应也会增大。卖家要控制开始时间，使用定时上架是一个很好的办法。Tips：但遗憾的是，使用定时上架，在第一轮销售周期开始时，商品并不能保证在准点就能够被搜索得到。秒杀是一个特殊的业务，这个业务其实就是借助于定时上架来实

9、现的。称杀是09年非常热门的一个词，带给技术部门其实更多的是苦涩。有兴趣的同学可以看一下内刊江湖2009年第11期。2010年，我们希望将秒杀这个业务产品化，打造一个能够应付瞬间并发暴增的稳定的产品，用于支撑秒杀等等特殊的业务需求。结束销售时间（ends）表示一个销售周期的结束时间商品组成（8+1）：库存库存五彩石之前，淘宝的库存很简单，只使用单一的一个数值表示。但面临的问题是，一个商品的“数量”可能需要细化，比如需要细化成红色有几件、蓝色有几件，分别是多少价格。因此五彩石的时候引入了sku概念。这时库存就会分成两个数值来表示：没有sku时，仍使用单一的一个数值（商品表的quantity）来表

10、示；有sku时，则以sku来表示库存。另外还有一个概念是“商品最初发布时的数量”，即商品表中的oldQuantity，表示商品第一次发布时的数量，该值以后永远也不发生改变库存管理的问题？库存数据更新管理需要花费大量时间，库存数经常出错 自动关闭的交易，库存不恢复，影响库存准确性商品组成（8+1）：物流一、运费有三种类型：1. 卖家承担2. 平邮、快递、EMS固定金额3. 使用运费模板运费模板的目的是将运费模板化，卖家可以为同一类型的商品设置使用同一个模板，使得这一批商品的运费都相同。使得方便地管理同一类型的商品的运费。模板可以分别为平邮、EMS、快递单独设置默认金额，以及根据数量逐步递增的金额

11、；另外还可以针对指定地区单独设置运费二、所在地1. Detail上会展示2. List上做筛选商品组成（8+1）：标题及描述标题（被索引，根据关键字检索时，搜索引擎只会检索两个字段，分别是商品标题和SPU标题）。目前搜索引擎对标题的处理是基于字索引。字索引好处是搜索的结果集最全。缺点在于相关性非常差，而且占用很高的内存。按照目前的架构，搜索引擎最多能够支撑起6亿左右的在线宝贝数量。另外一种索引算法是词索引；好处是性能高，相关性好，但在准确度上会有牺牲。处理标题的一些常见的业务有关键词过滤，中心词提取等。衍生的产品，像KFC（基于SPM）等。商品组成（8+1）：标题及描述描述存储在tfs上。目前

12、除支持html格式的文本之外，还支持flash及视频。发布商品时，商品的描述会被存储到文件并且持久化到tfs中。描述中可以插入图片、flash、视频等各种多媒体资源。其中图片使用自己的图片空间或外部网站的图片，flash和视频则需要从isv中获取。flash的isv中目前只有123show（）一家；视频的isv包括了国内几乎所有的大视频网站，包括优酷，土豆，56,酷6,等商品组成（8+1）：标题及描述Flash在宝贝描述里面，加上一个含有flash相关信息的域。卖家可以选择自己制作的flash并加入到宝贝描述里面目前的订购同样需要订购旺铺或是B卖家，但以后可能会放开防盗链处理：在代码中的src

13、属性值的域必须是(123show为淘宝卖家制作的flash全部都是这个域名)，如果使用其它网站的flash，包括123show其它的域名，ic会将src的值置空。Flash服务目前是按月订购，不限制使用次数的，也没有类目限制，在所有宝贝里面都可以任意使用视频视频目前只能用于宝贝里面，在发布和编辑页面有专门的一个区域，在detail里面的展示也是一个专门的区域（位于宝贝描述上面，居中）使用限制：a，必需要是旺铺或者b卖家；b,只有特定的店铺类目的卖家才允许订购该服务；c,视频只能用于允许的后台类目中在订购服务时，卖家须单独向其中一家或几家订购视频服务。在宝贝中引用视频的个数是有限制的，不限制使用

14、个数的服务需要每个月168元相相关关衍生的衍生的产产品：品：视频审视频审核核商品组成（8+1）：状态从监管的角度从监管的角度来划分正常下架（小二下架、卖家下架）删除（小二删除、卖家删除）CC（涉嫌欺诈）商品组成（8+1）：状态 - 从卖家的角度1. 出售中的宝贝监管的角度，商品状态正常卖家状态正常处于销售周期内有库存2. 仓库中的宝贝违规的宝贝（小二下架）卖家下架从未上架的宝贝到期下架的宝贝全部卖家的宝贝历史库的宝贝历史库用于存储离线的商品。历史库是一个技术上的选择，不是一个业务上的选择。对于淘宝而言，出于成本的考虑，我们无法做到存储、检索、管理卖家无限量的商品数据，因此一个解决的方案是历史库

15、，初衷是将卖家部分“不需要”、“滞销”的商品迁移到一个单独的数据库中，该数据库使用的是低成本、低性能的PC；同时历史库中的商品不参与搜索，大大减少搜索引擎的索引开销。从前面介绍的数据已经可以看到，实际上历史库的商品总数比在线的还要大。历史库最大的问题，一是影响卖家的体验；二是随着该库商品数量的不断增加，数据的存储、检索也面临极大的压力，目前其实已经无法提供正常的检索服务商品组成（8+1）：状态 - 历史库的宝贝商品组成（8+1）：图片商品图片一共包括三种类型：主图、多图、SKU图片。在稍后的章节中会详细说明类目属性体系为什么要有类目属性体系用结构化、标准化的方式，将商品科学的分类、组织；便于商

16、品的发布、搜索等，使用户能够快速、直观地了解商品类目是用于商品的分类和组织，属性和属性值用于结构化地描述商品本身。类目属性体系类目 商品所属的分类，比如化妆品、手机、火箭、大炮。类目决定了商品的归属类目是有层次的，分为一级类目、二级类目等等，之间有继承关系。比如电脑硬件这个一级类目下，有网卡、液晶显示器等二级类目。有两大类型的类目体系，一种类型是后台类目（标准类目），另外一种类型是前台类目（前台导航）。后台类目（标准类目， AUCTION_CATEGORIES）商品的实际归属类目，卖家在发布商品时，将商品发布到指定的后台类目下。Auction_auctions 表中的 cat_id 标识商品的

17、类目id比如N73，发布时发布到手机这个类目下，这个类目决定了商品的物理分类前台类目（前台导航， CM_CATEGORIES ）前台类目用于在前台（hesper）进行导航，展现，搜索定位用。前台类目中保存的，实际上是对后台类目/属性的筛选条件，即映射条件。前台类目在hesper上展现，用户通过前台类目搜索到该类目所映射的后台类目下挂靠的商品。需要注意的，一个商品并非有两个类目id（前台类目、后台类目）；商品仍然只归属于一个后台类目，类目属性体系仅有一套类目 宝贝发布，宝贝展示用同一套体系，想要调整宝贝的展示就必然会影响的宝贝的发布，宝贝发布和宝贝展示就成了一对矛盾 宝贝的存放路径很深，查找起来

18、不方便前后台分离 宝贝可以随意展示，宝贝的发布完全不受影响 宝贝很容易浮出来，查找起来很便利用途 卖家将商品发布到后台类目 List等前台应用，使用前台类目进行导航类目属性体系 - 后台类目逻辑根彩妆/香水/护肤/美体属性品牌:Avon/雅芳子属性雅芳系列:润泽保湿系列属性化妆品用途:面部护理属性化妆品规格：50ml女装/女士精品T恤属性款式属性领口款式在卖家发布商品的类目展示图： 类目属性体系 - 后台类目根一级类目：彩妆/香水/护肤/美体知名品牌Avon/雅芳标准类目：化妆品;品牌:Avon/雅芳Dior热销区夏日风情香水标准类目：化妆品;品牌:Avon/雅芳;适用季节：夏传统秘方夏日旅游

19、必备防晒霜一级类目：女装夏日旅游T恤类目属性体系 - 前台类目类目属性体系 - 前台类目前台买家搜索宝贝的类目展示图： 淘宝前台展示的类目 3C数码配件市场 来源于表 cm_categories .手机电池类目下的品牌：来源于表 cm_category_properties . 品牌下面的这些值 诺基亚、摩托罗拉等,来源于 cm_category_property_values . 前台类目变更会影响哪些？后台类目变更呢？ 前台类目变更，影响前台的搜索展现，影响宝贝的展现；如果引用了某个后台类目（仅且仅有这个前台类目），如果这个前台类目被删除，这个后台类目对应的宝贝将无法展现； 后台类目变更，

20、影响spu ，宝贝发布，出售中的宝贝，有宝贝的类目不能删除，有属性的宝贝不能删除；例如，某个后台类目一级属性具有子属性模板，有对应的spu，并且spu属性的值选择了其他，则该spu就自动具有一个子属性模板中的属性，当将这个类目的子属性模板删除后，不编辑spu的话，就会导致意想不到的问题。 如果用户乱放类目，我们如何管理？ 违规宝贝管理（CRM）类目属性体系 - 类目变更类目分级是如何组织的？按照什么标准或者方式来划分一级、二级和三级类目? 分类目是有标准的， 简单的说是，单一产品线为一个类目，如手机、和电话机就分类两个类目 什么时候要创建一个类目，这个问题没有一个特别具体的回答1.新需求：在其

21、它类目下挖掘成交比较高的产品，从商品数量，成交额，成交量等因素评估。2从类目涵盖的商品性质上而言，跟原有的二级类目有较大差异，保留在原有二级类目中无法体现，并且在一定程度上影响原二级类目的发展；类目分几层主要是看逻辑关系类目属性体系 - 类目规范类目属性体系 - 属性与属性值属性(BASE_PROPERTIES)：商品具有的特性，比如颜色、品牌、型号。属性值(BASE_VALUES)：具体的一个特征值。比如红色、诺基亚、N73.后台类目属性()：类目下的商品所具有的共同特征定义。比如手机类目具有品牌、型号、颜色、网络等属性（特征）类目属性值: 类目下的商品所具有的某一个特征的值（多个）。比如手

22、机类目的品牌属性，有诺基亚、索尼、三星等属性值。而香水类目下的品牌属性，有雅芳、香奈儿等属性值。类目属性值子属性: 类目下的商品所具有的某一个属性值所具有的属性细分。比如手机类目下，品牌属性下有一个属性值，叫诺基亚，诺基亚这个属性值具有“诺基亚型号”等子属性前台类目属性（值）与后台类目属性（值）的关系 ？前台类目属性（值）是其关联的后台类目属性（值）的并集的子集。用来选择那些商品属性用来检索和展现1）后台类目对应的前台类目 一个后台类目只能映射到一个前台类目.当多个前台类目引用相同的后台类目时,后台类目选取的某个前台类目是按照下面的规则实现的: 根据前台类目筛选条件,如果筛选条件类目id 与待

23、转换的后台类目id 相同且 只有类目 +10000;否则 先+1000 - 该筛选条件的pv个数 *100;如果非本category的，减去10分根据这个规则 最后哪个前台类目分数最高 就是这个前台类目.2）前台类目对应的后台类目 根据前台类目筛选条件,取筛选条件是默认筛选条件. 如果这个默认筛选条件是 spu ,则该spu所属的后台类目就是该前台类目所对应的后台类目. 如果默认筛选条件是类目的,则这个后台类目就是该前台类目所对应的后台类目. 如果默认筛选条件是类目属性的,则这个属性所属于的类目就是前台类目所对应的后台类目.类目属性体系 - 前后台类目映射属性的关联是怎么做到的，比如确定了型号

24、，别的属性都确定了。这是查的那张表？ 属性关系模板是为了配合非枚举/可输入属性，在非枚举/输入属性有子属性的情况下，在卖家输入的时候，需要引导卖家输入子属性。现有的系统中，是属性值和子属性的关系，不存在属性和属性的关系。比如品牌属性，卖家在发布SPU时，如果品牌是新建的，同时需要卖家输入型号；品牌和型号就存在这个关系。 子属性模板需要运营小二在后台mckinley中设置。子属性模板只能在后台叶子类目的一级属性中设置 ，保存的信息在category_properties 表 的CHILD_PROPERTY_ID 字段 . 格式是 子属性层级之间用；隔开。 在卖家发布商品时体现的业务逻辑是：类目属

25、性体系 - 子属性模板多值属性是怎么管理的。比如一件衣服的颜色可以选择多个category_properties：multi_select：是否多选 子属性的问题 子属性是挂接在一个后台类目属性值下的，不是挂接在后台类目属性下的； 属性和子属性存放在同一张表中； 同一个属性下有n个不同的属性值，即使每个属性值下面都有同一个子属性，这些子属性的id也不能重复，这是合理的；（比如手机品牌的值有诺基亚、三星、多普达，这些品牌值都有型号这个子属性，这样就需要有3个型号存在）每个属性（无论一级属性还是子属性），都有别名，我们的逻辑是优先展现别名，当别名不存在的情况下会去属性库中查询真名。类目属性体系 -

26、 子属性类目属性体系 - SPU为什么要有SPU？属性-属性值这种结构已经可以标识出一个商品全方位的特征。比如一个手机，型号、网络类型、大小、操作系统等等属性，已经可以全面的描述一个商品的特征。但在此之外，我们需要有一种机制，能够标识出每个商品所属的产品。什么是产品？举例通俗地讲：N95就是一个产品，是诺基亚公司的一个产品，这是唯一的，跟N96，N85都完全不同；淘宝上，卖家（假设有A,B,C）把这个产品进行包装，标上定价，向买家提供相应的服务，进而形成一个商品，从而在网络上进行销售。A,B,C三个卖家销售的产品从本质上是完全一样的，但商品却是不一样的：销售的价格、提供的售后服务、包装等等都各

27、不相同，对于买家而言，能享受到的服务也有区别，但产品本质上是相同的。标识出了商品所属的产品，我们就可以很方便的对商品进行管理：违规商品排查、价格限制、关联推荐、更短的购物路径、发布限制等等。什么是SPU？SPU是标识产品的一种机制。SPU是由一组类目属性/属性值组成，这些属性是这个类目下的关键属性，由关键属性可以确定一个唯一的产品。比如手机类型下，品牌和型号这两个属性可以确定一个SPU；以N95为例，品牌是诺基亚，型号是N95。类目属性体系 - SPU举例类目属性体系 - SKU为什么要有SKU？ 没有SKU前，每件商品只有一个总库存，不能根据颜色、尺码等进行细化、归类。一方面不利于卖家管理库

28、存，另外一方面交易时也给买卖双方带来不便 没有SKU前，卖家不得不在描述当中细化各种类型商品的真实库存，比如白色多少件、39码的鞋子多少双等等什么是SKU？ SKU是由销售属性组合而成的一个单元，某个类目下可能的SKU，由销售属性及销售属性值组合而成；卖家在发布商品时选择本店所具备的具体的SKU 比如男鞋类目下，销售属性有颜色及尺码。由白色+39码即可组合成一个SKUSKU 有多重要？类目属性体系 - 衍生产品Forest 淘宝最基础，最重要的核心应用之一Tips: SPU管理 -出于依赖调用的关系，SPU的写接口，在五彩石的时候已经迁移到IC中。SPU搜索引擎目前spu数量有一个亿。SPU搜

29、索引擎提供对SPU的实时检索。应用场景包括list、商品发布中的SPU选择、后台等地方。SPU搜索引擎能够检索到所有状态的SPU，包括：未确认，商家确认，小二确认和屏蔽状态等搜索中心的产品搜索（疯狂的坦克项目）（http:/ 图片一简介图片在淘宝用途相当广泛，在商品上使用到图片的地方主要有商品主图、商品多图、SKU图片、SPU图片等。出于成本的考虑，淘宝目前在部分业务上提供给卖家免费上传及使用图片的功能，同时也提供收费的产品供卖家选择：购买一定的图片存储空间，用于装修商品、店铺等。不管是免费抑或是收费的产品，最终图片的存储都是在tfs之上。多图用户或B卖家，每张图片500K大小限制，普通C卖家

30、，120K 图片 简介一图片空间店铺的一个收费产品，卖家购买了图片空间后，淘宝即提供相应的存储空间，用于存储图片资源。卖家将图片上传到图片空间后，相应的图片可以应用到商品、店铺等之上。否则卖家只能使用外部网站的图片资源，以嵌入到商品描述等。图片空间目前存储的图片张数在1.6亿左右。国内最大的社交网站（按去年10月份的数据，存储的图片在110亿张以上），在今年1月份，普通用户屏蔽外链，造成淘宝上大量宝贝不显示图片，给用户造成非常不好的用户体验，同时图片安全是2010年公司层面关注的重点之一，因此在3月份的时候，针对全网卖家免费30M图片空间。目前商品多图、描述可以使用来自图片空间的图片。部分类目

31、，比如成人类目，商品描述中只能使用图片空间的图片，不能链外网的图片 图片 图片空间一主图每个商品都有主图，主图是免费且不计图片空间容量。目前淘宝的商品，在线库+历史库有将近40亿，从这个角度来说，理论上目前存储的主图有近40亿张图片 主图一多图最早一个商品只有一张图片，即商品主图。之后为了满足卖家的需要，引入了多图这个业务，宝贝图片最多可以使用5张。多图只能从图片空间中选择 。一SKU图片SKU的图片存储在图片空间上 -SPU图片B商家可以发布SPU，发布SPU时，可以上传最多5张图片来作为该SPU的图片。这些图片全部是免费的，不计卖家图片空间的容量。买家在发布商品到SPU时，可以使用SPU的

32、图片作为商品的图片，此时全部是免费的；当然，没有开通图片空间服务的普通C卖家除外图片 多图和SKU图片图片 图片规格和压缩卖家上传的图片，淘宝只会保留原图，需要其他规格（分辩率）的图片时，tfs通过实时压缩生成（jmagick、magic+）。目前tfs支持的图片规格包括后缀（在原图片的后缀（在原图片的url之后添加）之后添加）对应规格对应规格_sum.jpg_sum.jpg8080_m.jpg_m.jpg120120_b.jpg_b.jpg220220_80 x40.jpg_80 x40.jpg8484_60 x30.jpg_60 x30.jpg6363_300.jpg_300.jpg300

33、300_30 x30.jpg_30 x30.jpg3030_40 x40.jpg_40 x40.jpg4040_250 x250.jpg_250 x250.jpg250250_310 x310.jpg_310 x310.jpg310310_160 x160.jpg_160 x160.jpg160160_170 x170.jpg_170 x170.jpg170170_80 x80.jpg_80 x80.jpg8080_120 x120.jpg_120 x120.jpg120120_110 x110.jpg_110 x110.jpg110110_110 x90.jpg_110 x90.jpg110

34、 90110 90_81x65.jpg_81x65.jpg81 6581 65_120 x120.jpg_120 x120.jpg120 120120 120_160 x160.jpg_160 x160.jpg160 160160 160_170 x170.jpg_170 x170.jpg170 170170 170_250 x250.jpg_250 x250.jpg250 250250 250_310 x310.jpg_310 x310.jpg310 310310 310_670 x670.jpg_670 x670.jpg670 670670 670_620 x10000.jpg_620 x

35、10000.jpg620 10000620 10000图片 图片放大镜功能上传1200px*1200px以上的图片，即可在宝贝详情页面提供图片放大功能图片 衍生的产品图片排查重复铺货算法图片验证码黄色图片识别Part2 业务系统商品生命周期CC（涉嫌欺诈）正常下架（小二/卖家)历史库在线库删除（小二/卖家)商品状态简图商品状态转换全景图商品流通全景图卖卖家家小二小二买买家家我的淘宝SELL淘宝助理mckinley收藏夹Search& ListSS1.45亿mallstDetail3C/VISTCTU处罚中心商品线主要业务系统依赖关系图SELL 卖家管理系统SELL 应用职责及定位Sel

36、l，顾名思义，是卖，也就是卖家的工具，从最初的denali，im中脱生而来，是淘宝卖家的对商品管理涉及的主要应用。他也是卖家和商品最直接打交道的应用，淘宝上大部分的商品是通过sell发布（除此之外还有淘宝助理，top等）上线，并通过sell进行商品的管理，运费的计算等等20092009年年1 1月月20092009年年1010月月ItemManager诞生。从denali中将商品相关的所有核心业务拆分出来，形成了IM应用SELL 两个重要的里程碑SELL诞生。从ItemManager中将卖家相关的业务拆分出来，形成了两个独立的应用：sell和buySELL主流程一：商品发布（1）类目选择搜索产

37、品 选择产品发布商品类目选择宝贝模板发布商品B商家商家C卖卖家家发布产品类目+品牌授权SELL主流程一：商品发布（2）填充商品信息1. 所有必填属性2. 标题3. 描述4. 图片5. 等等预览提交校验a.返点比例的校验b.价格、描述、类目品牌授权等校验c.图片的收集和处理d.宝贝视频的校验和上传e.类目属性的校验和组装f.宝贝描述中图片以及flash的校验g.网游垂直属性的处理h.旅游协议的校验和处理i.直充的校验和处理j.3C的校验和处理SELL主流程二：出售中/仓库中的宝贝宝贝查询编辑宝贝设置运费/促销爱心捐赠橱窗推荐删除/下架卖卖家家SELL ： PV、流量、QPSSELL的PV每天一般

38、在2500万到4000万左右每天消耗的出口带宽在 3360 G左右SELL的TPS不到30（商品发布）到数据库的连接： db1/2,misc,heart。 连接数在2-3个线上一共84台机器，CM3：56，CM4：28 SELL ： 架构及技术特点SELL ：架构及技术特点Sell有大量的场景涉及到复杂的客户端-服务器端交互，要求开发同学对客户端脚本语言有非常扎实的功底，否则定位问题、调试功能会非常吃力：类目选择、商品发布等。一个建议是熟悉ajax、json、YUI等SELL ：目前存在的问题及挑战商品发布图片压缩导致虚拟机crash商品发布页面选择的sku太多导致浏览器crash掉历史库商品

39、管理B商家授权信息的不一致性实时搜索的稳定待您处理的违规宝贝规则引擎的引入商品发布，需要校验的规则非常多，checkstep有20多个，且全部为硬编码。未来有可能引入规则引擎，通过规则引擎灵活的定制校验及业务逻辑，终极目标是规则的修改不再需要编码实现，而是在引擎中快速修改实现 SELL ：未来发展方向DETAIL 商品详情DETAIL：职责及定位Detail的业务定位很简单，就是展示一个商品的页面。但属于典型的“小应用，大作用”。Detail在交易核心流程中占据着无可替代的位置，几乎没有备份。Detail不单只是展示最基本的商品本身信息的应用，其他还包含了店铺基本信息，店铺类目，交易信息，评价

40、，促销，套餐，同时提供了引流到收藏夹、淘江湖、开心网的入口等DETAIL： 几个里程碑时间09年1月10年2月份1010年年5 5月月五彩石一期发布，detail诞生 旺铺四期结项，支持装修的全新detail诞生detail第一次大规模重构完成，将尝试基于tair的全新的数据访问模式1.店店铺头铺头 2.掌掌柜柜信息信息 3.店店铺类铺类目目 4.商品基本信息商品基本信息 5.计数计数：浏览浏览量、累量、累积积售出（商城）售出（商城）/30天售出天售出（集市）（集市）6.图图片片 7.销销售售属属性性 8.支持的服支持的服务务 9.促促销销 10.描述描述 11.评评价价 12.成交成交记录记

41、录 13.相相关关推荐推荐 14.掌掌柜柜推荐推荐 15.均价提醒均价提醒 16.邮费邮费模板模板 17.匿名留言匿名留言 DETAIL： 展示什么？DETAIL： PV、流量、QPSdetail的PV每天一般在2万到2.6亿左右每天消耗的出口带宽在 9676G 11328G左右detail的QPS不到50，还有很大可提升空间到数据库的连接： DB1,DB2,heart在23之间 misc 在01之间线上一共236台机器，CM3：118，CM4：118 DETAIL： 架构及技术特点大量的异步调用，减少主流程开销，降低主流程出错风险。数据聚合中心，依赖于很多的数据中心提供数据。不同数据的时效性

42、有很大区别，时效性低的数据，大量的依靠缓存 DETAIL： 架构及技术特点DETAIL： 存在问题及挑战作为互联网上一个典型的高并发、高数据聚合的应用，detail一方面会承载着越来越复杂的业务逻辑，另外一方面不断增加的业务逻辑又会对应用的稳定性造成很大的影响。主流程的数据路径过长，任何一个环节出问题，都会使得整个应用出现危机大量的重复运算一次请求需要渲染上百个模板，对velocity及webx的性能有很高的要求DETAIL： 未来发展方向缩短数据路径，同时减少大量的重复运算更加灵活的定制化搜索前端Hesper（定位于list）及新版搜索（定位于search），是淘宝的搜索前端应用，用于接收用

43、户的搜索请求，向搜索引擎进行检索并将最终结果组装，从而返回给用户。用户的购物路径中，搜索前端一般是第一站，搜索结果的好坏，对用户的体验、全网的成交具备最直接、最根本的影响。发展到今天，搜索前端已经不止是搜索引擎结果的组装容器那么简单，搜索前端封装了大量的影响、调控搜索行为的业务逻辑。同时搜索前端还是占据淘宝80%收入的P4P广告的播放平台，搜索前端的稳定，直接影响到淘宝的收入来源 搜索前端： 定位及职责搜索前端： 主流程（hesper为例）搜索前端： 导航传统方式折叠显示类产品属性值多选（珠宝类目）新版搜索搜索前端： 导航A: 类目预选与过滤(优先级1)：Qp服务器返回值qpcatid，都是一

44、系列的类目id，以分号分隔。进行搜索查询的时候，只返回qpcatid里指定的类目下的商品结果。B：类目混排(优先级2)：根据qp返回的类目字段id和加权值，将这些类目排序靠前C：橱窗推荐 消保优先 销售结束时间倒序搜索前端： 主搜默认排序hesper： PV、流量、QPSHesper每天的pv在6千万左右，新版搜索每天的PV在2.3到2.8亿次，hesper的qps在60以上。每天消耗的出口带宽在 2144 G左右无数据库连接线上一共134台机器，CM3：64，CM4：70 hesper： 架构及技术特点由于pv太大，因此页面大小显得格外重要，对于带宽、用户体验都会带来很大的影响。在提升主流程

45、稳定性，提高主流程速度方面采用的技术思路是，用并行计算代替串行计算。只有关键路径是串行的，其他子路径皆为并行。这与detail上大量使用异步技术有一定区别Hesper仅依赖于搜索引擎，不依赖于其他任何的数据中心。带来的一个付作用是当需要hesper： 架构及技术特点A. Hesper仅依赖于搜索引擎，不依赖于其他任何的数据中心。带来的一个副作用是无法利用数据中心提供的数据，比如用户信息，从而很难实现千人千面等业务场景 B. 搜索前端未来在导航上会更加多元化，期望能够提供一个强大的导航平台/工具，供运营来“指挥”、“摆放”淘宝的在线商品，同时引导、刺激用户的搜索/购物欲望。C. 3月中旬发布的智

46、能化商品管理项目，是商品线规划建设的搜索调控管理中心的第一步。未来调控管理中心将会提供全方位的分析报表，真正智能化的搜索行为定制工具，使运营能够快速、灵活的定制搜索行为，为淘宝在海量商品检索方面打下最扎实的基础。hesper： 问题和挑战商城、网游和3C数码垂直市场的前端list其他list： 定位及职责这几个应用，从某个角度来讲都是垂直市场的应用：全新的导航，经过定制、筛选的宝贝，有卖家审核/准入机制，同时向卖家收取佣金来作为淘宝的收入来源。他们代表的是淘宝在C2C市场之外的一种尝试Mallst ： 商城搜索前端商城的主要应用是mallst，即商城list，主要是用于淘宝商城中的商品和店铺搜

47、索。搜索结果仅包含商城的商品及SPU。商城list的导航采用商城专门的前台类目模板，同时强化品牌的概念，突出以品牌为中心的导航理念。搜索结果是以SPU+商品为单位，根据B2C的特点，搜索结果中融合了商家旗舰店推广等业务。默认排序算法是根据人气算法来实现商城卖家准入的实现，采用的是商家入驻、类目+品牌授权的形式Mallst ： 架构及技术特点Vist ： 网游前端带来带来的成交的成交订单数第一周6600第二周8000第三周10000目前成交已经破100万如果我们按照8%的佣金来计算：我们每天可以收入8万元，一个月有240万成交。重要的是，这个数字还在增长 更好的用更好的用户户体体验验。前期虽然抄

48、袭5173获得成功，但是后期如果不能在细节上超越。那我们仍然不容乐观 VIC是是个仓个仓促的方案促的方案VIC的产生，为IC的业务剥离提供了很好的实践方向，但是VIC是个仓促的东西，离产品化的路还很远。 用用户数户数据据挖挖掘掘我们需要知道用户在干什么，用户想干什么，我们才能进步。这或许需要搜索引擎的大力支持和一套完善的数据分析系统。 性能仍然是性能仍然是个问题个问题主要是在发布这一块，我们几乎沿用原sell系统的主要代码。这也影响了我们的TPS在58左右徘徊，这个数值还取决于用户在发布时尽量少的上传图片。Vist ： 面临的问题及挑战verticallist： 基本情况PV情情况况1.网络爬

49、虫情况2.总PV：(22-30)W*8 = (200-240)万/天成交情成交情况况1.最高发生于2010-01-25，1900W2.每周高位为550W - 580W之间，常发生于周一3.每周低位为390W-410W之间，常发生于周六QPS1.根据现在的TMS页面大小和线上服务能力，对3C系统可以预计的QPS承受能力估算为2502.目前监测到的最大突发QPS为187，发生于2010-03-29的某台机器，上午10点，最频繁IP来自趋势科技(美国)3.平均值：高峰期10-15问题问题和挑和挑战战1.目前3C机器经常被爬虫爬到很高的QPS1.北京金融街某IP源 10000PV/台*天2.TOP32

50、 SPIDERS脚本反映每天来自爬虫的访问量50000PV/台*天3.目前监测到的最变态爬虫会导致QPS达到180+，连续两天发生于早上6:302.DETAIL页面的SKU搜索与原始需求中按照ITEM聚合的需求存在维度差异3.TMS客户端性能依然很差，3C通过TMS导入的导航头体积也不小4.业务发展方向不明确5.第一版的主流程依然存在垃圾代码，一直计划在二期整理系统架构，但始终未提上日程verticallist： 问题及挑战a)目前存在的问题及挑战i.垂直市场的挑战在于如何搭建一个通用的垂直市场平台，使得运营能够快速的搭建出一个垂直市场。需要解决的主要问题是：商品的快速挑选/聚合；可定制、个性

51、化的垂直市场导航页；垂直市场的维护：如何做到既保证垂直市场的统一/共性，从而节省开发成本，同时又能保障垂直市场的独立、个性。b)未来发展方向i.灵活的导航ii.强大的内容聚合、推荐引擎垂直市场 问题及挑战后台mckinley后台 - 概述Mckinley是商品线业务最庞大、技术最简单、可发挥空间最大的一个应用系统。作为淘宝的商品管理后台，管理着淘宝的海量商品、类目属性、SPU管理、搜索行为定制数据、商品发布规则定制、违规信息、垂直市场管理等等，能够影响到淘宝商品前台应用系统的所有核心流程后台 - 主要业务宝贝管理运营管理网站安全时间程序后台 - 宝贝管理宝贝管理宝贝QC审查屏蔽快照宝贝批量处理

52、和恢复商品移动管理图片QC审查宝贝编辑统计宝贝批量管理后台 - 运营管理关键字管理SPU管理属性库价格限制类产品管理品牌管理后台类目前台类目后台 - 网站安全违规规则管理违规商品排查后台 - 时间程序排查库拍卖商品自动重发一口价自动重发/违规下架CTU消息订阅关键字同步类产品数据计算时间程序价格体系计算书籍SPU自动审核商品移动后台 - 未来发展方向目前存在的问题及挑战大部分模块性能很差；后台由于对数据的实时性有最高的要求，因此无法像detail等系统一样对运算结果进行缓存；而且后台很多数据的获取方式都比较复杂，需要有强大的检索工具提供检索商品管理称不上智能化，仍然停留在非常原始的时代未来发展

53、方向未来的商品后台，将首先是一个全方位的数据分析、展示中心。通过强大的报表系统，给运营提供一个清晰的视图，为管理、调控海量的商品提供数字上的支撑。在管理海量商品上更加智能、更加高效，提高运营管理商品的效率，降低成本。为突发性的安全事件提供强大的执行工具，同时提供完善的容错机制Part3 基础应用基础应用 因何而在？所谓基础应用，指的是不直接为最终用户提供服务，而作为基础的应用而独立存在，为其他前后端的应用提供数据等服务。商品线相关的基础应用，按照提供的服务一共分为三大类型：数据推送，包括forest、catserver。分别推送类目属性相关的数据，以及其他非类目属性的数据，比如关键字、价格体系

54、等。信息检索，包括ISearch为核心的各个搜索引擎，以及JAVA版本的，基于lucene和solr的VSearch统一的商品管理中心，包括IC和VIC，提供对商品最基础信息的检索以及管理接口。三种类型的基础应用，由于业务、定位不一样，因此对它们的要求也会有所不同。像forest、catserver这一类数据推送服务，不单要非常关心推送的数据模型本身，而且还要关注集群环境下的推送过程、数据容错、数据更新等；搜索引擎更多的是关注海量信息检索的高性能、高可靠性，实时搜索还要解决索引的实时更新问题，以及衍生出来的一系列产品：搜索行为分析/数据挖掘、搜索行为定制、关键字容错等；IC和VIC，目前解决的

55、是复杂的商品基础业务问题，同时希望能够提供一个稳定、可靠的商品核心数据的管理中心Forest - 概述Forest是一套用于管理类目属性的基础服务系统提供实时服务，通过hsf直接读、写数据库（后台CRM，读写）提供缓存服务， forest系统的类目相关数据, 都会推送到各个系统的内存空间 （前端，读）Forest - c/s交互Forest - domain 图Forest - domain 图Forest提供的服务类可分为两种类型，一种为缓存入口，另一种为实时入口，1）缓存服务类的入口： CatMapServices：前台类目服务 -类目地图服务入口，可以从缓存包中得到一个前台类目的对象。然

56、后通过这个类目对象获取相应的前台类目特征数据StdCategoryServices：后台类目 -标准类目服务入口，可以从缓存包中得到一个标准类目的对象。然后通过这个类目对象获取相应的类目特征数据PropertyRepoServices ：属性库管理 SpuGroupServices :spu组 SpuServices: spu关系 2) 实时服务类的入口： CatMapWriteServices：前台类目 StdCategoryWriteServices：后台类目 PropertyRepoWriteServices：属性库下面将分别对这些入口的结构做详细的介绍。Forest - 提供的主要se

57、rvice对垂直市场的完美支持，可完全定制数据包，以类目为单位垂直市场类目数据包管理工具，方便定制数据包Forest全部机器升级到64位2.02.03.03.03.53.5基于线上数据统计，80%的类目/属性数据，仅占总访问次数的不到2%，因此将部分类目/属性数据外存化，基于LRU等算法将数据交换到磁盘完成相应的文档提高机器利用率，将CM1/CM2机器全部下线实时接口改造，提高查询性能垃圾类目的自发现及清除品牌管理的检索及分组功能数据包分析工具推送机制改进，支持高峰期推送Forest到前端业务系统Forest - 产品演进计划Catserver - 概述Catserver曾经是淘宝最早的类目推

58、送服务器。经过岁月的变迁，catserver的职责也已经发生了很大的变化，目前提供除类目属性之外的数据推送服务，比如类目品牌授权、商品发布过滤关键字、商品发布价格限制、ip库等等。提供数据在本地持久化提供数据推送的监控、管理系统，用于方便的监控、跟踪客户端推送数据的版本信息Catserver 未来发展方向基础业务系统的稳定性改造，通过推送数据的持久化、更强有力的监控系统，彻底解决集群环境下数据推送的不一致新一代新一代数数据推送服据推送服务务持久化、完善监控价格体系其他类目授权品牌授权SELL/DETAIL/HESPER/SELL/DETAIL/HESPER/Catserver 产品演进路线Is

59、earch - 相关搜索产品1. 实时搜索A. 实时搜索目前主要有两个，一个是商品实时搜索（主实时），即卖家管理出售中，仓库中的宝贝所使用的实时搜索。另外一个是外店实时2. 非实时搜索两部分A. 主搜索B. 人气搜索C. 店铺内搜索D. SPU搜索E. NewB2C产品搜索F. 豆腐块搜索G. 产品搜H. 看图购I.Dump中心Isearch - 实时搜索实时搜索主要有以下特点：实时性强 - 更新的数据要求很快能被查询到更新频繁 - 每天商品更新40M次2 8 现象比较突出，少量的大卖家，占用了很大部分的系统资源 - 商品多，查询频繁绝大多数查询都有userid条件 - 查询某个user的数据

60、一、新版实时搜索在3月份时候上线。更稳定的实时搜索系统，解决老系统的丢包问题，提供系统可靠性。采用最新的isearch4，统一的版本。isupdate部分由isearch开发团队开发。采用和集团共同开发的消息分发系统，dispatcher，更稳定，可靠的消息分发机制。商品按user_id分组，极大提高系统的qpsIsearch - 实时搜索架构应用系统应用系统接口人接口人流量流量调用方式调用方式页面或应用页面或应用商品管理（sell）元绰，小邪3000wIC接口卖 家 管 理 商 品 的 查 询 页面,淘宝开发平台（TOP）武影和墨灵1750wIC接口TOP是安装淘宝助理软件mytaobao万剑300