IT瘾淘宝推荐

电商版“龙虾”来了！阿里悟空发布，用AI帮商家7✖️24小时经营淘宝天猫店

Thu, 19 Mar 2026 12:21:00 CST

电商版“龙虾”来了！近日，阿里巴巴正式推出全球首个企业级AI原生工作平台——“悟空”，在电商领域，淘宝、天猫核心经营能力将以Skill（技能模块）形式陆续接入，商家可以像搭积木一样，把这些Skill进行组合并在悟空上创造自己的AI工作流，搭建出一支可随时随地待命的覆盖开店、选品、营销、运营、发货等各个环节的AI Agent团队。

更厉害的是，除了电商经营，商家还能通过悟空接入财税、法务、设计、技术开发等各类专业Skill，组建起一套完整的企业职能AI Agent团队。以后商家只需要做关键决策，繁琐的调研、数据分析、方案撰写这些前置工作，统统交给AI团队来完成，全面开启AI时代的企业经营。

上线首期，支持淘宝商品素材优化、店铺经营周报分析、1688找同款等核心经营领域的“AI员工”将率先到岗，此外，商家还可将自身经营经验标准化为Skill技能包，搭建起满足个性化经营的AI Agent。

以“优化商品素材”为例，有了悟空后，商家只需编排好相应AI工作流，AI Agent即会自动完成“数据分析→给出建议”等前期工作，商家一键确认更新后，AI Agent将自动执行“素材制作-更新上架-监控效果”等后期步骤。也就是说，以前需要多人协同的工作，如今通过AI可一键完成。

单个AI Agent已经很强，一支AI Agent团队实现自主的互相协同更厉害。未来，当商家的经营分析Agent发现某款商品转化率下降，则其可自动通知商品素材Agent优化更新主图，与此同步，广告投放Agent也将会自动调整推广策略，整个经营工作商家只需在关键环节进行决策，其他全由AI Agent自主协调完成。

至于商家们最关心的信息安全问题，悟空也做了充分考虑。悟空主打企业可用级安全，为电商经营者提供成熟、安全的电商服务能力和合规的大模型技术，通过数据权限管理体系和加密部署，保障商家的数据信息安全。

目前，淘宝、天猫、支付宝、1688、阿里云等阿里巴巴核心业务Skill正陆续接入悟空。作为阿里巴巴 AI能力在企业工作场景的统一出口，悟空让每个商家，哪怕是“一人店”，也能拥有一支24小时待命的AI经营团队。

雷峰网

大规模视频内容理解：淘宝视频内容标签的结构化分析和管理

Fri, 10 Sep 2021 09:38:48 CST

▐ 为什么要做标签？

在这种亟需深入理解视频内容的大背景下，不同的表征形态涌现。包括：

embedding表征
标签表征

其中embedding表征常用的方法包括多模态预训练模型、基于用户行为的deep match模型等等，集团内在这方面有大量优秀的工作，使用embedding表征视频内容最大的问题在于不可解释性，只能完成机器对视频的理解。

使用标签对内容进行表征的优势在于，标签是一种高度概括的自然语言，不仅完成了机器对视频内容的理解，同时完成了人到视频内容的理解。同时，标签库量级上百万，组合方式多样，保证了内容表征的多样性。

综上，对视频完成了标签挂载，可以完成以下目标：

用户可理解
算法可解释
运营可干预

▐ 我们需要什么样的标签？

为了回答这个问题，需要拆解成两个子问题。

我们需要什么样的标签库？

视频是一种分别非常不均匀的数据形态，其拍摄方式、包含物体、拍摄手法、表达重点均非常丰富，为了描述丰富多彩的视频，需要维护海量级、描述维度全面的标签库。由于视频热点更新速度非常快，因此标签库需要自动挖掘、更新，完成标签库的动态扩充。同时，由于标签是一种自然语言，标签和标签之间天然有一种推理关系，因此，标签不应割裂和独立，而是存在一种结构化的数据结构。

因此，标签库需要的特性总结如下：

标签量级大、标签维度全面；
可动态扩展
标签间有关联（结构化）

对于一个视频来说，需要打出什么样的标签？

对于一个视频，必然存在拍摄此视频的核心原因，我们将此原因概括为核心主旨标签，给出核心主旨标签，即可联想到此视频大致的描述方向。同时，视频中必然出现很多相关标签，这类标签可帮助了解视频细节内容。结合核心主旨标签和相关标签，就可以对视频内容进行全局到局部、总体到细节的理解，这也是符合人类认知习惯的。

以下面这个淘宝中常见的视频为例，其核心想表达的是一个复古清纯风格的服饰搭配教程，核心主旨为：白月光穿搭、复古清纯穿搭等；而如何穿搭才能展现这种风格？需要穿白色连衣裙、带发箍等等，因此其相关标签应为：白色连衣裙、可爱发箍、vintage等等。

视频1 一种典型的淘内视频打标的结果

标签体系框架设计

按照1.2中的分析，为完成对视频内容全面的理解，我们需要从标签库和打标算法两个大方向对整体标签体系框架进行设计，即：

（1）标签库动态维护，包括标签的动态挖掘和标签结构化

（2）视频内容打标算法

完成标签库维护和打标流程后，即可完成数据服务的对外输出和下游的业务应用。数据的对外输出包括数据生产和实时/离线的服务输出；业务应用包括运营工具、下游投放算法和标签外透等。我们设计的标签体系框架如下图所示。

图2 标签体系设计架构大图

经过标签体系算法流程，内容标签目前对视频内容进行打标、标签库进行动态管理取得的结果如下图所示。在后续章节中，我会根据 标签库动态管理、 视频内容打标算法流程、 下游应用三个大模块进行详细的介绍。

标签库动态管理

▐ 标签挖掘

为保证挖掘标签词的时效性、全面性，我们设计了两套互补的标签挖掘算法流程，再将挖掘出的标签融合起来进行人工审核。

基于autophrase的半监督新词挖掘算法流程

如下图所示，将内容语料库和置信的标签集送入autophrase模型，通过半监督的方式获取标签后，再经过一个判别标签是否有效的二分类模型得到最终挖掘出的标签。此方法挖掘标签的特点在于：

过审率较高（80%+）
新标签和置信集标签pattern相似
无法获取热门标签

基于标签pattern挖掘的新词挖掘算法流程

如下图所示，这是一种无监督的标签挖掘流程，先从内容语料库中挖掘出标签组合的pattern，再用pattern在语料库中进行匹配，获取挖掘的标签。此方法挖掘标签的特点在于：

过审率较低
标签pattern更加灵活多样
可以获取热门标签

目前，我们基于海量的站内/站外数据挖掘出500w+标签，通过数据清洗后的标签量为110w+，其中原子标签数量90w+，短语标签数量130w+，短语型标签每周增量约5000+。

▐ 标签结构化

高效地维护标签库，不仅在于标签地动态挖掘，更在于挖掘出标签后，如何结构化地管理这些标签。好的标签结构化引入了标签间信息，为标签推理认知的提供了基础知识。首先，我们按照词语粒度将标签分为原子标签和短语标签，其中原子标签是不可继续分词的标签，短语标签为原子标签组合而成的标签。

原子标签分类体系

我们首先为原子标签设计了一套分类体系，可对每个原子标签进行树状结构的划分，一级类目包括“时间”、“地点”、“人物/动植物”、“事情”、“物品”、“IP”、“机构名”、“数值”等8个大类，在一级类目中还有二级、三级、四级的树状延伸等50个小类。

通过原子标签分类体系，不仅可以细分管理每个原子标签，将短语标签拆解为原子标签进行理解，同时可以分析每个分类下原子标签情况，如发现短缺的情况可以及时补充，保证标签集合的完整充分。

短语标签分维度结构化

由于短语标签包含各种不同的高层语义信息，因此仅通过组成短语标签的原子标签进行理解是远远不够的，基于此，我们从不同语义维度设计了四种不同的短语标签结构化方法，包括：内容/商品标签、热门趋势标签/长期标签、人群兴趣标签/视频内容标签、问题型/陈述型标签。在应用中，可按照不同的需求选取不同类型的短语标签。

图4 短语标签分类体系

▐ 标签管理目前核心进展

目前标签库已实现动态管理、结构化，具体的指标如下图所示。

视频内容打标算法

▐ 视频内容打标算法流程设计

在确定视频内容打标算法流程之前，需要确定目前视频内容打标面临的困难和挑战，我对其总结如下：

标签库规模巨大：目前维护的标签库达百万，且长尾分布严重，无法使用多标签分类模型等常规打标签的解决方案。
标签库不断增长、动态扩充：目前标签库处在动态扩展的状态，标签经常变动，打标算法需要非常灵活&可扩展。
需对多模态信息进行理解：视频是一种多模态的内容形式，包括文本/图像/音频等多种模态的信息。对于不同的视频，不同模态的重要程度也不同，因此需要对多模态的信息进行综合全面的向量表征。
需区分不同标签在内容的权重：如上几条中讨论，对于一个视频，需要给出其核心主旨标签和相关标签。对算法来说，即最终标签结果需给出和视频内容的相关性分数排序。
人工标注非常困难：一个视频具体改打什么标签是一个非常主观的问题，对于不同的标注者，其对内容标签的标注结果会有巨大的差异。因此在打标算法流程设计中，需减少对标注的依赖。

综合上述对视频内容打标算法流程难点和挑战的分析，我们设计了基于“ 召回-排序”的两段式算法流程，召回是视频和标签粗粒匹配过程，排序是视频和标签细粒度匹配过程，调整标签的排序。此算法流程可以很好地解决视频内容打标过程中的难点。

图5 视频标签挂载流程大图

召回阶段

其的核心目标在于召回尽可能多、尽可能全的候选标签。为保证召回标签的全面，我按照以下四个维度进行召回：

内容信息

即内容自带的信息，包括创作者编辑的文本、语音识别结果（ASR）、文本识别结果（OCR）、画面信息。

以上面这个制作芝士烤土豆片的食谱教程视频为例：

商品信息

由于淘内视频的独特性，视频的目的是为了卖货，因此，商品信息也作为描述视频的一个维度。视频下挂载的商品、商品query、同款商品等信息作为商品信息维度的文本召回。

用户行为信息

淘内视频和用户有着大量的交互，用户行为本身也可以作为标签候选词集。因此内容搜索点击日志清洗出的query可作为表述用户行为的召回候选词。

关联内容信息

候选词集不仅应包括内容自带的信息，还应该包括关联信息，这一路召回主要通过检索方法实现：

跨模态检索模型：向量化视频和标签库直接进行跨模态检索，获取最有可能作为视频标签的词。
相似视频检索模型：需要打标的视频作为query，在千万级视频库中检索出topN相似视频，将相似视频的候选词共享到query视频。

在后续小节中，会对两种检索方法做更详细的介绍。

排序阶段

在排序阶段中，主要目标在于对视频和候选词集进行更细粒度匹配和对齐，完成候选词集的相关性排序，保留和视频相关的标签，去除不相关的词。排序模型的具体建模方式接下去会进行详细的介绍。

▐ 核心技术点

在上一部分中，除了常规模型ASR、OCR等，需要核心解决的技术目标为：

召回模块中的相似视频检索
召回模块中的跨模态检索模型
排序模块中使用的跨模态相关性判别模型

对于这三个需要解决的核心技术目标，我们抽象出三个需攻坚的核心技术点：

视频多模态内容表征模型
跨模态检索模型
跨模态相关性判别模型

在接下去几部分中，会对这三个核心技术点进行详细拆解和介绍。

▐ 视频多模态内容表征

我们目前提取的embedding基于自研的通用视频内容预训练模型。这个视频内容预训练模型借鉴了VilBert的自监督训练方法，继承了更多通用性强的预训练任务，包括内容挂载商品的一级、二级分类，内容的文本和视觉信息是否匹配。同时，由于淘系内容业务与推荐任务息息相关，因此，我们进行了大幅度的改造，对于推荐大场景改良了预训练网络和特异性预训练任务。

参考[5]LXMERT的预训练网络结构，具体输入：

visual branch图文内容：

（1）图文包含的所有图像经过Resnet抽取的1536维特征序列。维度为101536（2）图像帧位置信息序列：维度为110，表示图像处于图像序列位置视频视频：（1）视频关键帧经过Resnet抽取的1536维特征序列。101536（2）图像真位置信息序列：维度为110，表示图像处于帧序列位置

Language branch图文内容：

（1）title+body content经过中文bert编码的字id序列，维度为1128（2）字位置信息序列：维度1128，表示字在句子序列中的位置视频内容：（1）title+summary经过中文bert编码的字id序列，维度为1128（2）字位置信息序列：维度1128，表示字在句子序列中的位置

图6 视频理解基础模型网络框架

目前共5个预训练task：

图像序列随机mask掉图像序列的feature，最后用以visual为主的cross-modality feature进行mask掉的feature回归预测。
序列随机mask掉字序列的feature，最后用以Language为主的cross-modality feature进行mask掉的文字id分类预测。
内容挂载商品的110个一级类目分类
内容挂载商品的3807个叶子类目分类
visual信息和language信息是否匹配的二分类（即图像序列和文字序列是否来自同一内容）

同时，由于同时mask视觉/文本侧特征可能导致信息过度损失，参考[9]UNITER模型中的mask策略，优化训练策略，如下图所示。

经过10个epoch，使用100+块GPU，经过5天的训练，将6000w+淘内视频数据完成训练。预训练模型的参数更新参考了海量的视频数据，被上亿的标注数据进行了约束，最终产出的checkpoint可以作为后续跨模态检索、排序模型的Backbone网络，产出的768维向量可作为相似视频检索的视频向量。在视频内容的标签挂载算法流程中，这个pretrain model发挥了重要的作用。

内容表征的好坏是根据下游算法性能的提高作为衡量指标的，使用视频标题bert向量、LXMERT向量、UNITER向量在下游的跨模态检索模型、跨模态相关性模型中进行对比实验。

跨模态检索模型使用不同向量表征模型的对比结果

跨模态相关性判别模型使用不同向量表征模型的对比结果

相似视频检索模型

视频多模态预训练模型中最后一层768维fc可作为视频内容多模态的表征向量，对视频有很强的表征能力，因此可以使用此向量在视频库中检索出相似视频，用来扩充标签候选集。

使用相似视频检索对视频标签候选集进行扩充是一种非常有效的方式，使用相似视频检索的思路如下图所示，一个视频可以基于相似embedding检索的方法，在上千万的视频库中检索出最相似的N个视频，将这些相似视频的标签扩充此视频候选词集合。

基于相似视频检索方案的视频内容打标case如下所示：

图5 相似视频检索在标签召回的应用流程

▐ 跨模态检索

跨模态检索模型

如果视频和话题的向量分布被处理到相同分布空间，那么视频可以直接在标签库中检索到与其最相关的N个标签。因此我们设计了融合Graph的跨模态检索模型结构，完成视频直接到标签的检索。网络结构如下图所示。该模型主要包括文本编码模型、视频多模态编码模型、图网络算法模型、度量学习模型。

图7 融合Graph的跨模态检索模型网络框架

为了环节样本稀疏和均衡问题，单模态和跨模态端到端的度量学习进一步保证不同模态的语义一致性和单模态的判别性，我们引入了图网络构建。

我们根据用户点击行为构建文本-视频、文本-文本、视频-视频的同构图，但考虑到仅使用用户点击行为构建的图较为稀疏，因此同时引入了基于语义相似度建图，将相似的文本和相似的视频之间构建边，最终形成的图结构如下所示。

实验结果

检索衡量指标采用检索召回准确率Top1，Top5，Top20 以及Mean Rank值。

1K淘宝样本对检索性能如下：

MSCOCO Retrieval数据集的5K检索任务性能结果对比，其中对比方法主要限定采用双塔模型结构、特征提取无需相互计算，适用于大规模检索的方法。本文工作达到了与同期前沿工作具有竞争力的性能。

case展示

主题标签在千万级首猜精品视频池进行向量检索，手淘全屏页[3]主题标签召回示例case：

▐ 跨模态相关性判别

完成了最大程度的候选词集召回后，需要一个可以更加更精确判别视频和词语相似度的排序模型，从而将候选词从按照和视频的相关性分数进行排序，剔除掉不相关的词语。

此时的排序模型和上一小节的跨模态检索模型不同之处在于，跨模态检索模型目的是从上百万标签库中快速检索到和视频可能相关的词语，因此在训练过程中，视频侧和标签侧的网络结构不能融合。而在排序模型中，目的在于更精细化判断视频和候选词的相关性，且候选词数量有限，无需过度在乎时间复杂度，因此两模态之间可以进行充分融合，我们设计的网络结构如下图所示。

图8 视频标签排序模型网络框架

可以根据目的将网络结构分成三个较为独立的模块，即：

表征模块

如何对视频、候选词进行表征，可以全面刻画视频、候选词内容。这里我们主要讨论和调整了视频侧表征方式，使用视频标题、LXMERT多模态特征、UNITER多模态特征进行了对比实验，实验AUC结果如下所示。

融合模块

如何对两路特征进行融合，我们主要使用了两种融合策略，一种是最后一层MLP融合的late fusion策略，一种是使用attention metric进行attention fusion的策略，对比实验AUC如下所示。

对齐模块

两路特征表征和充份融合后，需要将两种分布在不同特征空间的模态（视频内容&标签）对齐到相同的空间分布中，才能完成不同模态的相关性度量。在这里，我们使用了融合了难样本挖掘的对比学习TripletLoss，以及将两种模态尽可能混合的Adversarial Loss。

我们对Triplet Loss和Adversarial Loss进行了对比实验，对比实验的AUC结果如下图所示，可以看到加入生成Loss后，由于增加了使两模态尽可能混合的目标，对最终相关性判别能力是有提高的。

加入用户反馈数据

由于标签数据在全屏页全量，每天有新增1w的用户点击数据，这部分数据往往更加精准，将这部分数据加入训练数据构造一个动态的训练数据集，相比于不加入这部分数据，相关性判别模型的AUC有将近3%的提升。

▐ 视频标签挂靠结果

通过我们设计的召回+排序的视频标签挂载流程，目前视频内容打标结果的统计数据如下所示。同时我们也按照标签不同分类对打标结果做了更加精细的分析：

业务应用

▐ 下游推荐算法链路

图11 标签在淘宝不同场景投放算法中的应用

全屏页召回链路

全屏页召回链路应用 （均已全量）：

冷启动：增加原子标签+短语标签召回路，完播率+18%
冷启动：增加短语标签相似关系召回，完播率+3%
主链路：增加原子标签+主题标签召回，有效vv+2%, 七天新视频vv+3%
主链路：增加短语标签相似关系，有效vv+1.5%, 七天vv提升3%, 商家视频占比+5%

逛逛召回链路

语义向量召回 (已全量)

使用视频标签、title作为视频侧表征训练视频召回深度语义DeepV2V，指标如下：

pctr +1.04% uctr +0.4% 人均时长持平，人均点击+1.1%，人均曝光+0.5%；

整体指标：pctr +1.2% uctr +0.45% 人均点击+1.36% 人均曝光+0.4%；

新鲜度指标：30d+发布的视频数量 +2%, 1-7d -4%；

曝光度指标：0-200vv视频数量：+16%，200-2k: +4%，20w+: -2%；

多样性指标：唯一视频数量+4.2%。

▐ 标签的前台透出

在首猜全屏页中，我们使用话题对视频进行圈选，在全屏页透出，基于认知主题知识，构建底bar话题标签体系，目前线上投放话题 12w，覆盖视频vv 58%，覆盖uv 1000w+, uv_ctr 1.4%。目前已全量。

图12 短语标签在淘宝不同场景透出的效果展示

▐ 用户的数据反馈

在完成全屏页全量后，每天会产生10w左右的视频-话题点击pair对，我们将上线后的点击反馈数据收集起来，形成线上透出，线下收集数据重新训练模型。

图13 线上用户数据反馈到排序模型数据流向图

最终在排序模型中，加入线上反馈数据后，AUC有3%的提升。

总结与展望

在视频内容标签接近两年的建设中，完成标签库的结构化管理，维护百万级别标签库，同时形成了“召回+排序”的算法打标流程。在下游搜索推荐算法、标签外透产品、运营圈选工具都取得了不错的业务效果。未来希望完成标签更全面的图谱化结构设计，不仅完成标签的识别，更能做到标签、内容、用户之间的认知和推理，相信有了关系、节点丰富多样的图谱化结构，会使视频内容理解如虎添翼。

Reference

[1] Peter Anderson, Xiaodong He, Chris Buehler, Damien Teney, Mark Johnson, Stephen Gould, andLei Zhang. Bottom-up and top-down attention for image captioning and visual question answering. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pp.6077–6086, 2018.

[2] Hao Tan and Mohit Bansal. Lxmert: Learning cross-modality encoder representations from transformers. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language

Processing, 2019.

[3] Liunian Harold Li, Mark Yatskar, Da Yin, Cho-Jui Hsieh, and Kai-Wei Chang. Visualbert: A simple

and performant baseline for vision and language. arXiv preprint arXiv:1908.03557, 2019b.

[4] Gen Li, Nan Duan, Yuejian Fang, Daxin Jiang, and Ming Zhou. Unicoder-vl: A universal encoder

for vision and language by cross-modal pre-training, 2019a.

[5] Su W, Zhu X, Cao Y, et al. Vl-bert: Pre-training of generic visual-linguistic representations[J]. arXiv preprint arXiv:1908.08530, 2019.image-20191107143317330.pngimage-20191107151306644.png

[6] Chen Y C, Li L, Yu L, et al. UNITER: Learning UNiversal Image-TExt Representations[J]. arXiv preprint arXiv:1909.11740, 2019.

[7] Zhou L, Palangi H, Zhang L, et al. Unified Vision-Language Pre-Training

for Image Captioning and VQA[J]. arXiv preprint arXiv:1909.11059, 2019.

[8] Peng, Y. , and J. Qi . "CM-GANs." ACM Transactions on Multimedia Computing, Communications, and Applications (TOMM) 15.1(2019):1-24.

[9] Portillo-Quintero J A , Ortiz-Bayliss J C , H Terashima-Marín. A Straightforward Framework For Video Retrieval Using CLIP[J]. 2021.

[10] Xu, R. , et al. "A Proposal-based Approach for Activity Image-to-Video Retrieval." (2019).

[11] Tan, M. , and Q. V. Le . "EfficientNetV2: Smaller Models and Faster Training." (2021).

[12] Miech, Antoine , et al. "Thinking Fast and Slow: Efficient Text-to-Visual Retrieval with Transformers." (2021).

[13] Li, W. , et al. "UNIMO: Towards Unified-Modal Understanding and Generation via Cross-Modal Contrastive Learning." (2020).

[14] Chen, S. , et al. "Fine-grained Video-Text Retrieval with Hierarchical Graph Reasoning." IEEE (2020).

[15] Wray M , Doughty H , Damen D . On Semantic Similarity in Video Retrieval[J]. 2021.

[16] Yuan, L. , et al. "Tokens-to-Token ViT: Training Vision Transformers from Scratch on ImageNet." (2021).

作者 |云未
编辑|橙子君 出品|阿里巴巴新零售淘系技术

END,入群👇备注： 视频

PRD：淘宝有好货需求文档

Fri, 10 Jul 2020 14:28:20 CST

编辑导语：随着移动互联网的发展，人们对网购的需求增加，用户需求呈现多样化和个性化。本文是作者通过体验手机淘宝的有好货功能模块做功能业务上的拓展，通过用户调研提出优化方向，并生成产品需求文档PRD。

需求文档：

迭代历史：

一、背景和目的

1. 需求背景

淘宝有好货位于首页正中间，能给宝贝商品带来庞大的流量，而有好货的slogan “1.3亿人推荐的品质好物”，进一步突出了有好货以精品为主的战略定位。

通过竞品分析和用户调研，发现淘宝有好货存在以下问题：

功能入口单一，流程上没有形成闭环，且有好货与淘宝的其他业务模块间缺少关联性。
在有好货中，种草社区不够完善，用户之间的互动性较低，缺少话题性。
商品品类较多，没有进行聚合，用户浏览好货商品的效率较低。

2. 需求目的

提升有好货的DAU，唤醒部分老用户，增加用户的粘性。
提升有好货的打开率，增加使用有好货功能的用户数量。
为其他业务做导流，提高商品的转化率。

3. 数据指标

日活/月活：DAU/MAU。
次日、七日、月留存率。
新增用户量。
PV点击率：点击次数/展现次数。
UV点击率：点击用户数/展现用户数。
日榜转化率：每日好物榜榜单的点击量/排行榜的总浏览量。
商品转化率：付费用户数/用户浏览总数。
跳出率：点击好物榜就离开的次数/点击好物榜后访问榜单的总次数。

二、需求概述

1. 核心功能

“好物榜”功能：在“有好货”中增加“好物榜”功能模块，并增加生鲜美食榜、情人礼物榜、旅行必备榜、居家生活榜等商品榜单内容。
“入选xxx榜第xxx名”功能：在商品详情页中增加商品入选榜单的排名情况。当用户浏览商品详情页时，商品正好是榜单推荐的内容时，就可以在商品详情页进行相应的榜单展示（“入选xxx榜第xxx名”），并引流到榜单页面。
“近xxx日售出xxx件”功能：根据商品销售情况，进行相应的内容展示。
“直播中”功能构件：当商品正在被人直播时，用户可以点击“直播中”button，进入直播页面观看直播。
评论展示：在好货分享区域下方，显示1-3条热门评论，并在下方显示“查看全部xxx条评论”几个字，用户点击后展开评论区查看相关评论内容。

2. 业务流程

3. 涉及开发方

三、需求详述

1. 好物榜

开发方：

客户端后台、推荐后台、搜索后台、卖家后台、图片库。
客户端：iOS端、Android端、前端、ipad端。

前置条件：

用户已登录，并在首页中点击有好货，进入第一个标签页面：好物榜。

规则逻辑：

热门榜单：

显示3类在榜单中热卖程度排名第一的商品。

单个榜单显示数据包括：

榜单名称、参加推荐总人数、排名标签、商品图片。

滑动至页面顶部：

用户下拉页面，逐步显示刷新文案“下拉刷新”，但还没有到达刷新状态时，松手后，刷新头部会自动隐藏。

用户下拉页面，显示刷新文案“下拉刷新”，当到达刷新状态时，松开手后即可完成内容刷新，如果下拉滑动距离过大，刷新头部会一直置顶，页面会不断下移。

内容刷新过程中，显示刷新文案“加载中…”；后台数据刷新后，显示刷新文案“刷新成功”并同时完成页面内容的刷新操作。

用户退出有好货页面后，5分钟后重新进入有好货，页面保持不变；5分钟后重新从首页进入有好货时，自动完成一次页面内容的刷新操作。

用户切出后台APP，5分钟内再次进入APP保持不变；5-15分钟后再进入APP时完成一次页面内容的刷新操作；15分钟后再进入APP时重新启动并加载首页。

页面下拉后，固定顶部导航栏区域，连续下拉时隐藏搜索栏及以下区域。

推荐榜单：

在“推荐”标签下，根据用户的历史浏览行为进行展示，为用户推荐符合其兴趣的榜单内容。

在推荐榜单的标签区域，显示垂直领域的榜单标签内容，除“推荐”外，还包括“家居生活”、“美颜护肤”、“养生健康”、“运动健身”、“数码家电”和“母婴生活”6个榜单标签。

推荐榜单（包括“推荐”标签和其余6类榜单标签）下，显示的榜单数量为10个，当用户下拉刷新页面或者重新进入有好货页面时，可以完成对推荐榜单内容的刷新操作。

单个榜单中显示的数据包括：榜单名称、当前榜单参加推荐总人数、名次、商品图片、商品标题、综合推荐值、商品推荐人数。

在页面没有进行滑动或向上滑动距离小于顶部到推荐榜单的距离时，手指在推荐榜单区域左右滑动，可以完成切换榜单标签的操作。

在滑动距离大于等于顶部到推荐榜单的距离时，顶部标签淡化消失，推荐榜单标签区域停在顶端不动，随榜单页面继续向下移动。在当前状态下，左右滑动页面，可以完成切换榜单标签的操作。（见上方右侧图片）

推荐后台中鉴别热门榜单和推荐榜单的内容情况，在同一时间段内，避免展示的榜单内容出现重复。

后置条件：

用例成功，用户进入排行榜页面，系统刷新页面并在排行榜中更新对应的榜单信息。

2. 搜索

开发方：

客户端后台、搜索后台、卖家后台、图片库。
客户端：iOS端、Android端、前端、ipad端。·前置条件：用户已登录，且处于好物榜页面中，并点击上方搜索框区域。

规则逻辑：

搜索栏中提供关键词搜索，点击输入框跳转到关键词搜索页面。
点击搜索输入框弹出字母键盘，搜索完成后页面将展示所有存在对应关键词的商品榜单内容。
点击取消按钮，退出搜索页面，返回到好物榜页面。
在关键词搜索页面提供历史搜索记录，方便用户快速搜索查找过的商品榜单。历史搜索记录中的关键词数量为1-10个，当数量超出10个时，删除栈底的搜索关键词，并将新的搜索关键词置于栈顶。
点击删除按钮，将所有历史搜索记录清空，并将“历史搜索”隐藏。·后置条件：用例成功，用户进入排行榜页面，系统刷新页面并在排行榜中更新对应的榜单信息。

3. 排行榜

开发方：

客户端后台、推荐后台、卖家后台、分享页、图片库。
客户端：iOS端、Android端、前端、分享页、ipad端。

前置条件：

用户已登录，且处于好物榜中某一排行榜内容区域。

规则逻辑：

排行榜依据销售额GMV累积计算得出，按照从大到小进行排序。GMV=访问数量*销售数量/访问数量*客单价。

单个商品区域显示数据包括：

名次、商品图片、商品标题、商品标签、达人头像、达人名称、推荐理由、推荐button。

商品标签的展示内容包括：

产品参数：型号、材质、款式、类型、颜色、风格、容量…

评价中的分类标签，例如材质很好、样式很好、做工不错、性价比高…对于畅销产品，比如化妆品、手机、支架、连衣裙等，优先展示评价中的分类标签；

而对于销量不高或偏冷门的产品，比如水壶、门窗、橱柜、日历等，则展示产品参数内容。

推理理由：显示好货详情页中达人推荐内容的第一句话的前28个字节（字母、数字占1个字节，标点符号、汉字占2个字节）。

排行榜互动：

商品推荐：点击推荐按钮，弹出底部窗口，选择推荐理由，可选推荐理由的数量为9个（多选；也可以不选）。点击确定按钮后，窗口从上到下滑动弹出，爱心图标从空心变成实心，文案从推荐变成已推荐，同时图标右边的数字+1（见上方第一、第二张图片）。
添加推荐：当用户没有选择推荐理由时，再次点击推荐按钮，弹出底部窗口，可以补充相应的推荐理由，可选推荐理由的数量为1-9个。点击确定按钮，完成推荐理由的补充，窗口从上到下滑动弹出，并在底部区域弹出“推荐理由补充成功”的提示文字，约2秒后消失（见上方第三、第四张图片）。
取消推荐：再次点击推荐按钮，弹出底部窗口，可以查看已选的推荐理由。点击“取消推荐”，取消对商品的推荐操作，窗口从上到下滑动弹出，并在底部区域弹出“已取消期待下次推荐”的提示文字，约2秒后消失（见上方第五、第六张图片）。

向上滑动时，滑动距离从0到顶部栏高度的过程中，图七红框区域由透明变成不透明，直到滑动距离大于等于顶部栏高度时，图七红框区域停在顶端固定不动，仅展示页面移动。

点击“全部榜单”，跳转到有好货的好物榜页面。

后置条件：

用例成功，用户进入某一商品的好货详情页中。

4. 入选榜单

开发方：

客户端后台、图片库、卖家后台。
客户端：iOS端、Android端、前端、分享页、ipad端。·前置条件：用户已登录，且处于某一商品的商品详情页中。

规则逻辑：

显示当前商品的入榜情况：“入选xxx榜单第xx名”。
入选区域展示数据包括：榜单图标、排行榜（固定文本）、入榜情况（“入选xxx榜单第xx名”，具体榜单名称和商品名次根据商品所属标签和排名依据自动生成）和向右的指引箭头。
点击排行榜入选区域，进入当前商品所在的排行榜展示页。

后置条件：

用例成功，用户进入某一商品所在的排行榜页面，系统刷新页面并在排行榜中更新对应的榜单信息。

5. 近期购买

开发方：

客户端后台、推荐后台、评论系统、图片库、卖家后台、直播后台。
客户端：iOS端、Android端、前端、分享页、ipad端。

前置条件：

用户已登录，且处于有好货中某一商品的好货详情页中。

规则逻辑：

显示商品的近期购买情况：“近xx日售出xxx件”。

近期购买显示规则：

对于消费频次高、近期购买量多的商品，显示“近7日售出xxx件”、“近3日售出xxx件”、“近24小时售出xxx件”等标签内容。
如果近24小时售出超100件以上，则显示“近24小时售出xxx件”；
如果近24小时内售出100件以下、近3日内售出200件以上，则显示“近3日售出xxx件”；
如果近3日内售出200件以下、近7日内售出500件以上，则显示“近7日售出xxx件”。
对于消费频次低、近期购买量少的商品，显示“近30日售出xxx件”、“累计售出xxx件”等内容。
如果“近7日售出xxx件”售出500件以下，近30日售出1000件以上，则显示“近30日售出xxx件”；
如果近30日售出1000件以下，则显示“累计售出xxx件”。

点击近期购买区域，跳转到当前商品的商品详情页。

后置条件：

用例成功，用户进入商品详情页，浏览当前商品的商详页内容。

6. 直播中

开发方：

客户端后台、图片库、卖家后台、直播后台。
客户端：iOS端、Android端、前端、ipad端。

前置条件：

用户已登录，且处于有好货中某一商品的好货详情页中。

规则逻辑：

显示当前正在直播中的商品直播间入口构件。
“直播中”构件展示数据包括：爱心图标、“直播中”文字和“去围观”button。
“直播中”构件固定在商品图片右上角区域，随页面的滑动一起向下移动。
点击“直播中”构件，跳转进入直播间页面。

后置条件：

用例成功，用户进入商品直播页，观看商品直播内容。

7. 评论展示

开发方：

客户端后台、评论系统、图片库、卖家后台。
客户端：iOS端、Android端、前端、ipad端。

前置条件：

用户已登录，且处于有好货中某一商品的好货详情页中。

规则逻辑：

显示一条当前商品评论中最新发布的评论内容。

评论展示区域显示的数据包括：用户名称、评论内容和“查看全部xxx条评论”（xxx根据当前商品在评论区的评论数量来展示）；

如果当前商品的评论数量为零，则“评论展示”自动隐藏，不展示评论内容和“查看全部xxx条评论”文字。

单击返回键或点击评论页面上方的任意区域，即可关闭评论弹窗。

点击“查看全部xxx条评论”，从下到上弹出评论窗口，可以查看当前商品的评论内容并进行相应的互动。

后置条件：

用例成功，系统从底部呼起评论组件，用户可进行互动和评论操作。

本文由@Runjer Tang原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

边缘计算听说过吗？淘宝提升了69%的首屏性能

Thu, 28 May 2020 11:04:46 CST

本文分享来自淘系内容前端团队-蒂夫

前情

在开始正题之前，我先讲一个内容详情的业务场景和其面临的性能问题

业务特点

图文内容详情业务本身有三个比较大的特点：

内容量大，几十亿的内容量，并且每天还在疯狂增长；
流量大，为了支撑这么大的业务，需要很多服务器成本；
内容数据极具静态化，页面参考如下，除了蓝色标识的数据，其他数据很少会改动；

那我们看这么一个页面的加载和渲染过程大概是什么样的？

总结问题

从上面的流程可以看出几个问题：

首屏渲染依赖多次请求，导致首屏渲染性能差，尤其是低端机
服务端压力大，每次请求都需要请求到服务端，对服务器也会带来非常大的压力
内容重复渲染，同样一篇内容每个人看到都一样，但是渲染结果又无法共享

大胆思考

这时候我们要结合业务本身的特性进行一些大胆的思考：

研发时预渲染

首先想到的是在研发过程中就对内容进行预渲染并存储起来，但是这个方案很快被 pass 了，有两个主要原因：

内容量太大：内容数量特别大，并且一篇内容在不同的场景（上百）还会展示出不同的风格，全部静态化存储 CDN 资源浪费严重
更新成本大：内容会被达人修改，或者一些打擦边球的内容需要尽快下线

按需渲染结果静态化

既然数据绝大部分是静态化的，为什么不能把用户访问时静态数据和代码渲染后的结果进行静态化，这样不是省去了 renderToHTML 的过程了吗？，如下图所示

那讲到这里，我们首先想到的是通过 SSR renderToHTMLString，然后把渲染后的结果进行缓存，这样访问到相同内容的请求可以直接将缓存结果返回，那这样有什么好处呢：

减少重复渲染，提升首屏性能
降低接口服务的压力
基于访问存储，避免资源浪费

但是同时也带来了其他的问题：

SSR 应用服务器距离用户远带来的白屏时间延长
SSR 本身的压力也会提升，因为这样意味着每一个用户请求都要经过 SSR（虽然可以走缓存）
缓存数据存储的问题，存哪里，内存肯定不满足需求，因为刚开始就讲到了内容量特别大，这时候要借助于其他的一些快速存储的云服务，显得特别复杂

这时候我们就在想，如果能够将渲染的结果或者渲染的过程放在 CDN 上就好了，因为 CDN 节点比较多，并且在世界范围部署广泛，所以我们尝试着将 SSR 渲染的结果存储在 CDN 上，但是随之带来另外一些问题：

SSR 服务器出错了怎么办，现在 CDN 是一种配置生效系统，如下图所示，我们上文说到了图文详情的流量特别大，这也就意味着各种异常情况都要考虑，像 SSR 服务器宕机带来的风险我们也必须有降级方案，保障不影响用户

对于两种特殊场景需要及时更新缓存：擦边球内容要能够及时下线，页面代码更新要能够批量更新缓存，目前通过 CDN 的配置项是解决不了这些问题的

这时我们正好了解到了 CDN 正在推广一种边缘计算的能力（EdgeRoutine，下面会做简单的介绍），简单点理解就是可以在 CDN 请求返回结果之前加上你的自定义脚本，并且可以访问 CDN 的数据，那就意味着我们可以控制 CDN 请求返回的内容或者HTTP 状态，好像基本能够解决我上面说的两个问题，所以按照当前的技术能力和我们的需求我们针对请求链路进行了改造：

具体的降级和缓存清除的逻辑没有画出来，因为那是解决安全生产的问题，我主要想强调方案调整带来的性能提升。

所以从上图可以看出，一个正常的请求首先会请求到 CDN，CDN 如果发现缓存中没有的话会回源到 SSR 服务器，这样首屏其实只需要一个网络请求，有效的提升的首屏性能和降低了服务器压力。细心的你会发现页面首屏后还进行了一次请求动态数据的动作，因为还有一个对实时性要求比较高的数据需要展示给用户，但是并不影响用户浏览，另外虽然内容不怎么会更新但也会存在更新的情况，所以我们会在浏览器端做一次缓存的时间和内容最新更新时间的对比，如果发现不一致，会主动做缓存更新，这样，既保证了性能，又避免了缓存过期

收益

通过做如上的方案我们在性能，业务指标提升，服务器压力上都有很大的收获

性能提升明显，低端机首屏 1S 内

业务指标提升明显

服务器压力降低 80%

边缘计算 ER

关于边缘计算，大家可以参考： developer.aliyun.com/article/757…

本篇文章贴出几张核心的图供大家参考：

简单总结就是我们可以在 CDN 返回结果之前进行一些逻辑计算，并且这部分代码兼容 ES6 的规范，并且可以通过 HTTP 和外界服务进行沟通，达到有效的控制的 CDN 返回的表现的目的

优势-共享

在此我想重点介绍下边缘计算的共享优势，对于边缘计算来说，它不仅可以处理一些逻辑计算，还可以将计算的结果进行存储，存储能力是 Swift 的 Open API ，实现数据的 KV 存储，这就意味着，这个存储空间可以非常大。说道这里大家可能会感觉比较抽象，可以看下面这张图，上面是指我们正常的网络请求，用户手机直连数据服务器和页面 CDN，这就意味每个人都要经历加载页面，加载数据，渲染页面等逻辑。下面是指 CDN ER 做了一层代理，这就意味着用户手机链接 CDN，CDN 负责和数据服务器和页面 CDN 进行沟通。那样这样有什么好处呢，这就意味着我们可以将像内容详情这种数据或者渲染的结果直接存储在 CDN 上，并且不用担心存储内容太多影响性能，这就就像一群人公用一部手机，你看完传递给下一个人刷新看相同的内容

优势-计算能力

既然能在 CDN 的 ER 节点上写 ES6 的代码，并且可以请求数据，这就意味着我们可以在ER上执行很多逻辑，在这里我整理一些常用的：

那基于这些能力我们还能支持哪些合适的场景落地呢，所以我们针对淘系的场景进行了调研

场景调研

整体调研有一个统一的思路，就是要找适合静态化的高流量场景，就是说页面是否有可被缓存的数据或者渲染结果，为此我们整理了一个简单的表格：

接下来我做一些简单的说明：

末端类型的页面一般是有内容主体，并且这些主体数据不是千人千面的，例如上图提到的，内容详情、商品详情、个人主页、评论列表、评论详情
搭建类业务，配置信息目前需要异步加载，模块还要异步加载，这些配置化的东西是否可以直接和页面一起输出
榜单类型的页面，同样的一个榜单，每个人看到的都一样，但是榜单要更新，但是这个更新并非真正的实时，一般为了承载更大的流量，数据都是准实时，例如分钟级更新，小时级更新，甚至一天更新一次，那在有效期内其实可以将榜单数据或者榜单的渲染结果缓存起来的

总结一下标准的页面请求过程如下：

这里说一下，其实在数据侧有很多静态化策略已经被用的游刃有余，例如借助于 CDN、Tair、OSS，如果我们能够让静态化的过程变得更加简单和通用，例如将数据或者页面渲染结果直接存储在 CDN，下次请求就可以直接复用渲染结果，有没有可能变成如下模式：

其实就是两个原则：

减少 HTTP 请求次数，尽可能一次请求出首屏；
复用渲染结果：将渲染过程放在 ER 上并缓存下来，直接复用渲染结果，或者针对我们常用的骨架图方案，是否能够换成静态数据的渲染结果；

场景标准化

最终结合 ER 的能力和我们的业务场景，我们抽象为以下四种：

SSR 静态化：指快速将 SSR 的结果缓存在 CDN 上
ESR(Edge Side Render)：顾名思义，将 renderToHTMLString 的过程放在 ER 节点上，并且缓存渲染结果
数据预请求：就是指将本来需要渲染后再请求数据的逻辑前置在 ER 上，将请求的结果合并返回给浏览器
Redirect：重定向，是指在 ER 上根据逻辑实现重定向的能力，相对于以往我们前端通过制定 location.href 的方式要快很多了，这个可以满足逻辑分流需求，例如 AB
Include：片段注入，可以注入任何文字内容到任意文件类型中，一种更加通用的方案

经过我们的测试和实践，针对前三种产出了一些性能报告也可以分享给大家，虽然不全面，但是能说明问题，由于测试的页面场景不一样，所以相互（数据预加载、 ESR、SSR 静态化）没有必要作对比，以下指标是相对没有使用 TESI 的能力进行的对比

标准化接入

虽然 ER 有这么多优势，但是接入成本还是比较大的，例如要注意 ER 容器本身的各种限制、调试成本、云资源申请成本等，所以我们需要提供一种标准的接入方式，初步了解到 W3C 有一个 ESI 的标准，维基百科介绍如下：

Edge Side Includes or ESI is a small markup language for edge level dynamic web content assembly. The purpose of ESI is to tackle the problem of web infrastructure scaling. It is an application of edge computing.

简单翻译一下：ESI 是一种边缘级 web 动态化的小型标记语言。ESI 的目的是解决 web 基础设施的扩展问题。它是边缘计算的一种应用方案

原理如图：

其实就是说，可以通过标签注入的方式，实现动静内容混合混合输出，比较符合我们的诉求，并且其在语法上也比较丰富

但问题是 ESI 是一种 XML 的标准，阿里有很多页面资源类型并不是 HTML，例如 weex、小程序等等，它们加载的页面并不是 HTML，并且我们要满足标准化场景的接入，所以我们需要在 ESI 的基础上进行改造-TESI（Taobao Edge Side Includes），合适的才是最好的

基本的代码形式如何，我们以数据预加载为例，如下 H5 中出现 TESI 标签（鼠标选中部分）

TESI 标签描述了一个 http 接口的信息，并且配置了其缓存时长 s-maxage，ER 会解析这个标签，并且在 ER 上发起请求，并将请求的数据按照 s-maxage 配置的值进行缓存，这就意味着下一次请求到相同的节点，就会直接返回缓存结果

渲染结果如下：

我们看其实像数据预加载这种情况，在 HTML 中会渲染成一个 script 标签，其中存储的是一个全局变量方便运行时获取。

其实 TESI 标签不仅可以用于 HTML 中，JS 中可以出现 TESI 标签，如下：

渲染后

其基本渲染原理如下，比较简单，这里不做赘余：

还有其他几种类型的标签如下：

标签名	描述
tesi:data	数据预加载
tesi:esr	边缘渲染
tesi:ssr	SSR 静态化
tesi:redirect	逻辑跳转
tesi:include	区块引入

稳定降级

整个 ER 执行的过程会遇到各种各样的问题，甚至 ER 都有挂掉的风险，所以需要有稳定降级的预案保证不影响用户，所以我们会将 CDN 源站指向页面 CDN 的源站，这样，及时 ER 解析出现问题，可以把解析前的页面直接返回给浏览器

缓存管理

存储

ER 提供了两种缓存：内存缓存（以下简称 Cache）和 Swift KV 缓存（以下简称 KV），这两种模式在存取速度、体积大小、QPS 上都有差别，总结基本如下：

指标	VS	胜出
存储空间	Cache ﹤ KV	KV，可达几十 GB
QPS	Cache ﹥ KV	Cache
存取速度	Cache ﹥ KV	Cache
存储副作用	Cache ﹥ KV	KV

这里指的存储副作用是指，存储大小对于 ER 性能的影响，存储在缓存中，如果存储体积接近内存大小，首先会影响 ER 执行性能，严重会导致 ER 容器重启

综合以上两种对比结果来看各有千秋，但合适的场景用合适的模式才是最好，为此我们设计了二级缓存模式，一级缓存存入内存，二级缓存存入 KV，主要完成如下三个重点逻辑：

动态计算热度内容推入一级缓存
采用 LRU（最近最久未使用算法）的模式实现一级缓存和二级缓存的数据推出，充分利用缓存空间
每一个标签设定指定的缓存空间，避免缓存分配不均，导致相互影响

缓存失效

缓存的内容需要具备快速清除的能力，因为数据会更新、页面 bundle 会更新，特别是遇到紧急情况，例如线上问题紧急修复，需要能够实现缓存及时清除，所以需要一定的策略来满足需求，总体清除的逻辑会依赖请求，根据标签的身份信息进行清除

接入过程

为了满足系统稳定性和安全生产的要求，TESI 标签的生产过程是需要被管控起来的，所以我们要提供一个 TESI 的运维系统主要满足以下几个需求：

运维系统使用过程如下：

运维系统主要为了生成一个可用的 TESI 标签，真正发布生效我们会借助于 DEF 发布系统，这样既沿用了标准，安全生产相关能力我们也不用重复建设了，基本流程如下：

附录

名词介绍：

ER：EdgeRoutine
ESR: Edge Side Render
SSR: Server Side Render
ESI: Edge Side Includes
TESI: Taobao Edge Side Includes
DEF: 阿里前端发布系统
Swift：阿里云 CDN 文件存储

几种常用服务类型简介：

其基本的配置信息和执行过程如下，大家可以参考下：

最后

还是亘古不变的话题，如果你对边缘计算感兴趣，欢迎加入我们共同建设，如果你对我们的业务感兴趣，也欢迎你的加入，业务了解： zhuanlan.zhihu.com/p/128956855

简历投递：yabing.zyb@alibaba-inc.com

主题备注：前端-公司-名字

[转]排名算法（二）--淘宝搜索排序算法分析

Mon, 31 Dec 2018 16:36:34 CST

原文：https://blog.csdn.net/u011966339/article/details/78052569

淘宝搜索排序的目的是帮助用户快速的找到需要的商品。从技术上来说，就是在用户输入关键词匹配到的商品中，把最符合用户需求的商品排到第一位，其它的依次排在后续相应的位置。为了更好的实现这个目标，算法排序系统基本按三个方面来推进：

一、算法模型

当用户输入关键词进行搜索的时候，系统依据算法模型来给匹配到的每个商品进行实时的计算，并按照分数的大小对商品进行排序。

对于好的算法模型，首先需要考虑我们能够有哪些特征因子可以应用。比如在网页搜索中，算法模型基本就是按网页的重要性和相关性给网页计算一个分数，然后进行排序。这里的相关性，和重要性就是网页排序模型中两个重要的因子。具体来说相关性因子是指搜索关键字在文档中出现的度数，当这个度数越高时，则认为该文档的相关程度越高。重要度因子比如 Google 的 Pagerank，可以理解为一个网页入口超级链接的数目：一个网页被其他网页引用得越多，则该网页就越有价值。特别地，一个网页被越重要的网页所引用，则该网页的重要程度也就越高。

考虑淘宝搜索的时候，有些特征因子是很容易能想到的，比如：

A、文本的相关性：关键词和商品的匹配，匹配的程度，是否重要词的匹配，匹配词之间的距离等，都可能影响相关性。比如搜索“小鸭子洗衣机”的时候，一个商品的中心词是洗衣机的要比卖洗衣机配件商品的相关性高，小鸭子连在一起的相关性要比“小”和“鸭子”分开时候的相关性高等。文本相关性最基本的计算方式可以参考 BM25 等。

B、类目热点：淘宝数据的一个重要特质是每个商品都挂靠在类目属性体系下面，每个商品都做了一个很好的分类。在搜索过程中，同一搜索词的大量用户行为数据很容易聚焦到相应的热点类目，比如“手机”的搜索行为会集中到手机类目，而不是配件类目。

C、图片质量：图片是电子商务网站非常重要的一个数据，图片是否精美吸引人，图片上是否有各种各样的“牛皮癣”，和商品匹配度等都很大程度上影响着用户的点击和购买决策。

D、商品质量：每个商品都有不同的质量，商品的描述真实性，是否物美价廉，受人欢迎的程度等。

E、作弊因子：类似于全网搜索有关键词堆砌，link spam，网页重复等等作弊的问题，电子商务搜索也面临同样的问题，比如商品关键词堆砌，重复铺货，重复开店，广告商品引流等等，也有商品特有的问题如价格作弊，交易作弊等，需要利用统计分析或者机器学习来做异常行为，异常规律的发现和识别并运用到排序中。

F、公平因子：淘宝的商品很丰富，每个搜索词下都有足够多的商品在竞争，需要在相似质量的情况下让更多的商品和卖家有展示的机会，而不是像网页搜索一样是一个基本静态的排序，照成商品点击和展示的马太效应。

类似的商品，卖家，买家，搜索词等方面的特征因子有很多，一个排序模型就是把各种各样不同的特征因子组合起来，给出一个最终的关键词到商品的相关性分数。只用其中的一到两个特征因子，已经可以对商品做一些最基本的排序。如果有更多的特征参与到排序，我们就可能得到一个更好的排序算法。组合的方法可以有简单的人工配置到复杂的类似 Learning to Rank 等的学习模型。

那么如何衡量不同算法之间的优劣呢？

二、线下评估

算法模型的评估一般分为线下的评估和线上的评估，线下的评估很多都体现在搜索中常用的相关性（Relevance）指标。相关性的定义可以分为狭义相关性和广义相关性两方面，狭义相关性一般指检索结果和用户查询的相关程度。而从广义的层面，相关性可以理解为用户查询的综合满意度。当用户在搜索框输入关键词，到需求获得满足，这之间经历的过程越顺畅，越便捷，搜索相关性就越好。

在淘宝搜索衡量狭义相关性的时候，一般是使用 PI（Per Item）测试的方法：

A、抽取具有代表性的查询关键词，组成一个规模适当的关键词集合

B、针对这个关键词集合，从模型的产出结果中查询对应的结果，进行人工标注（人工判断为相关性好、中、差等），对人工评测的结果数据，使用预定义好的评价计算公式比如 DCG 等，用数值化的方法来评价算法模型的结果和标注的理想结果的接近程度。

利用人工标注数据来计算相关性的分数，来判断模型的好坏；在这个过程中人工不可避免的会有主观的判断，但综合了多人的判断结果还是可以获得一个有统计意义的结果，另一方面标注数据也可以帮助我们找到一个算法表现不理想的地方，有针对性的提升。
广义的相关性线下评测比较困难，受人工主观因素的影响更大，一般使用 SBS（Side by Side）的评测方法，针对一个关键词，把两个不同算法模型产出的结果同时展示在屏幕上，每次新模型和对比模型展示的位置关系都是随即的，人工判断的时候不知道哪一边的数据是新模型的结果，人工判断那一边的搜索结果好，以最终的统计结果综合来衡量新模型和老模型的搜索表现。

线下评测的方法和指标有很多，不同的搜索引擎会关注不同的指标，比如以前 Yahoo 的全网搜索引擎比较关注 RCFP（Relevance，Coverage，Freshness，Perspective）等，淘宝搜索线下评测时候一般统计 DCG 和 SBS 的指标。

线下的评测方法从统计上有一定的指导意义，能从一定程度上区分模型的好坏，但要真正验证算法模型的好坏，还需要接受真实的流量来验证。

三、线上测试

为了真实验证一个算法模型的好坏，需要有一个系统能提供真实的流量来检验。淘宝搜索实现的 BTS（Bucket Testing System）系统就是这样的一个环境，在用户搜索时，由搜索系统根据一定的策略来自动决定用户的分组号（Bucket id），保证自动抽取导入不同分组的流量具有可对比性，然后让不同分组的用户看到的不同算法模型提供的结果。用户在不同模型下的行为将被记录下来，这些行为数据通过数据分析形成一系列指标，而通过这些指标的比较，最后就形成了不同模型之间孰优孰劣的结论。只要分组的流量达到一定的程度，数据指标从统计意义上就具有可比性。

不同的 BTS 系统会关注不同的数据指标，在淘宝搜索，有一些重要的指标是很多算法模型测试的时候关注的：

访问 UV 成交转化率：来淘宝搜索的 UV，最终通过搜索结果成交的用户占比。
IPV-UV 转化率：来淘宝搜索的 UV，有多少比例的用户点击了搜索结果
CTR：搜索产生的点击占搜索产生的 PV 的比例
客单价：每个成交用户在淘宝搜索上产生成交的平均价格
基尼系数：基尼系数是一个经济学名词，考量社会财富的集中度；如果社会财富集中到很少一部分富人手中的时候，基尼系数就会增大，社会的稳定性和可持续发展性就会出现问题；淘宝搜索借用了这个概念来衡量搜索带给卖家的 PV 展示，和点击的集中度，在保证用户体验的前提下，给更多的优质或小小而美的卖家展示的机会。
大部分时候我们都有好几个模型和功能在线上测试，我们用 BTS 的方式来观察测试的情况，如果提升稳定就逐渐开放给所有用户，如果没有提升，我们也能从中获得经验帮助我们更好的理解用户。

作者：App_12062011 发表于 2018/12/31 16:36:34 原文链接 https://blog.csdn.net/App_12062011/article/details/85471485

阅读：2

手机淘宝推荐中的排序学习-博客-云栖社区-阿里云

Mon, 20 Aug 2018 16:38:47 CST

周梁：淘宝推荐机器学习技术专家，中国科学院自动化研究所机器学习博士，主要研究工作方向是机器学习、大规模并行算法优化。先后从事过广告CTR预估，MPI机器学习平台搭建，手淘个性化推荐等多方面工作。

排序学习是推荐、搜索、广告的核心问题。在手机淘宝的推荐场景中，受制于展示空间的限制，排序学习显得尤为重要。在淘宝，如何从十亿的商品中，挑选出用户今天喜欢的商品，也是个巨大的挑战。本次我们分享排序学习在手机淘宝中的应用，其中包括：解决了哪些问题，遇到了哪些挑战，以及做了哪些改进。

手淘推荐介绍

图1手淘推荐业务全覆盖

用户提升体验，千人千面；商家提供流量，提升转换；平台引导行为，流量分配。

图2手淘推荐系统

Match：基于内容，行为的推荐。场景，社交，人群，个人的长期兴趣，短期行为。

图3排序学习的原因

排序学习分类：PointWise：

PairWise：

ListWise：直接优化整个集合序列，不再做Transform,优化目标NDCG.

业务实例

图4店铺内推荐业务

业务：只可以推荐同店铺商品，可以是相似搭配。目标：CTR.方法：PointWise。

图5模型

样本构造：

模型目标：预测<user,item> ctr，并按照ctr排序。

手机埋点的困难：曝光，点击收集，Native 版本，H5 版本。

正负样本处理：

1. 点击/曝光PV

2. (点击 + 折算成交)/曝光PV

3. (点击 + 折算的成交)/(有效点击以上PV截断)

4. (点击 + 折算的成交)/(泊松采样的虚拟PV)

特征设计

ID类特征，User、Item 、Context基本特征，移动特定场景相关特征：设备ID VS 用户ID；城市区域特征；手机型号特征，PC & Mobile 特征融合。

每个特征权重反映该特征在数据中的统计意义，方便进行特征组合和模型debug，比较方便引入在线学习。

特征工程

图6年龄匹配

图7年龄匹配

特征组合，交叉特征，例如年龄匹配。

个性化模型，特征交叉

– User：U1={张三，男，年龄35}，U2={李四，男，年龄29}

– Item:I1={鼠标}，I2={枕头}

– 训练集：U1点了I1，没点I2

– 预测：U2对I1、I2的喜好

– 特征归并，{张三，男，年龄35，鼠标}，无泛化能力

– 特征交叉：{张三，男，年龄35，鼠标，男_鼠标}

– 对常见问题的解决方法

– 性别匹配：user性别与item性别交叉

– 年龄匹配：user年龄与item年龄交叉

– 购买力匹配：user购买力与item购买力交叉

– 用户类目偏好：user id与item类目id交叉

– Position bias：训练时引入pos id为特征

– 多Matchtype融合：引入Matchtype id为特征

– 人群属性偏好：人群特征同item id做交叉

实时用户特征

用户的Session 特征怎么办？：用户当前时刻看了多少本类目商品；用户是否已经在别的场景下看过了本商品；用户是否已经购买本类目同款商品。

在线学习：离线特征提取，在线模型学习（FTRL）

图8在线学习

行业市场业务

图9

业务：个性化行业模块排序，个性化图文排序，最大化点击。

目标：行业流量的均衡。

方法：优化auc，Pairwise-ranknet。

PairWise思考：只考虑了两篇文档的相对顺序，对于不同的查询相关文档集的数量差异很大，投入产出比看，pairwise最佳。

业务场景Position因素：前两个图的面积明显占优，统计数据显示CTR明显占优。

流量均衡考虑。

图10 BPR模型

BPR:Bayesian Personalized Ranking。

构造pair样本是关键：

1. Click > Skip Above

2. Last Click > Skip Above

3. Click > Earlier Click

4. Click > No-Click Next

图11女装瀑布流

业务：瀑布流个性化，多目标优化。目标：CTR,CVR,客单价。方法：优化NDCG,listwise-lambdamart。

图12多目标融合

优化NDCG

DCG (Discounted Cumulative Gain)

NDCG(Normalized Version)

图13

左图pairwise错误相比右图小（13 VS 11）；希望出现红色的梯度方向和强度；直接优化NDCG。

LambdaRank 不再从Cost Function出发推导梯度，反而直接计算梯度来优化NDCG等一类的IR指标。

Mart（Multiple Additive Regression Tree）与 Lambda 结合，得到 LambdaMart。

特征表示：

连续特征表示，便于Mart训练以及特征选择、组合
User，Item，Context的各个维度反馈特征
User Session 维度特征
各种子目标模型的Score
LBS特征反馈

图14样本构造

多目标构成ListWise，输入Lambdamart，按照等权重构造梯度权重。

等权重构造梯度权重的问题：样本有偏；训练较慢。

改进策略：按人工加权方式修正梯度强度；针对多种不同等级pair构造中，每个List只挑选最大违反的同类型pair做当前轮训练。

图15计划&展望

日志：手机日志收集，终端较多，多App间协作。

特征：家庭用户特征同账户问题，地域特征，PC、Mobile 特征对齐。

目标：业务目标多，LTR有较大的应用空间。

实时：在线模型更新，用户行为特征挖掘。

除了淘宝，还能去哪买好看的装饰画

Sat, 09 Jun 2018 21:43:10 CST

单调的墙面需要想象力的妆点，一幅好的装饰画代表的则是主人家的品味。前阵子看到PChouse推送的 装饰画选购攻略，身为广州土著的我忍不住也想来分享一下我的淘画私窦。遗憾的是，在这次的拜访过程中，我发现不少有趣的空间都已不复存在，譬如东山口的浮图space、文德路的小红楼等。 所以，如果你家还差一幅装饰画， 抓紧时间到下面这几家店看看吧！ 且行且珍惜。
" width="640">

艺术＋书店

地址：广州市黄边北路151号时代玫瑰园三期时代美术馆1楼
" width="640">
艺术＋书店由广东时代美术馆携手广州的老字号民营书店学而优共同打造，以 社区型书店 、关注当代艺术、提供新鲜生活元素为经营方向，同时还展售有时代美术馆专属的艺术＋优品。
" width="640"> " width="640">
● 重点推荐：创意海报这里独家贩卖的创意海报，一张才 30元！款式多样，总有一款适合你！而且海报是采用极具厚重感的 防水油画布印制的，并不像一般的海报那样容易损坏。
" width="640"> " width="640">* 创意海报的包装

103store

地址：广州市天河区天河南二路六运五街27号103室
" width="640">
一个充满并可接纳各种创意的艺文空间，贩卖店主自己做的手作木艺，举办多元的创意展览，还会不定期开展各种活动课程。前阵子举办的“103store开业周年庆暨小红楼纪念展”重现了“已故”小红楼里的各种好玩独特的视觉艺术作品，有 独立艺术家的纸本创作、亦有 收藏级的教学老画。
" width="640"> " width="640">
● 重点推荐：DIY课程在这里，你不仅可以买到装饰挂画，更能尝试自己创作一幅独一无二的专属作品。103store每两周一次的 Midnight Drawing Club（午夜画画聚乐部），逢周一晚上举办，每晚一个主题，即便是绘画零基础的小白，在主持人Mafia的引导下亦能做出有趣的创作。贴心的店家连相框都准备好了呢！
" width="640"> " width="640"> " width="640">

* 过往学员作品展示

逵园艺术馆

地址：广州市越秀区恤孤院路9号
" width="640">
被誉为东山洋房五大名园之一的红砖老别墅，在最大程度保留原貌的基础上活化成为集艺廊、咖啡馆、文化活动和艺术生活体验为一体的创新艺术空间，艺廊不定期举办各类艺术展览，其中 以画展居多。
" width="640">
● 重点推荐：艺术家油画作品逵园展出的油画作品多出自优秀的新生代艺术家之手，兼具艺术感和装饰感。最重要的是， 好看！又不贵！有些较小幅的作品三位数便有交易，即便是普通工薪阶层亦能消费得起。买一张挂在家里，赏心悦目的同时还能顺便过一回收藏家的瘾，如果一不小心押到了宝，作品升值了，那就更了不得了。
" width="640"> " width="640">

* 逵园过往展览作品

三多轩

地址：广州市越秀区文德路83号
" width="640">
文德路是出了名的字画一条街，在这里不仅可以买到 传统的文房四宝，进行 书画装裱，还有大量的书画作品任君挑选。这其中，有一家的名号特别响亮，那就是三多轩。广州的“三多轩”，与北京"荣宝斋"、"上海朵云轩"并称为中国三大文房名店，至今已经有190多年历史。三多轩经历了数次搬迁和浮沉，如今位于文德路83号的这家是2000年破产后政府为保护老字号，将其承包给其他公司经营的延续。
" width="640">
● 重点推荐： 名人字画和字画一条街上批发的商品不同，三多轩主打少有的名人字画，不过，因为店内的面积不大，因此现场可供挑选的作品有限，有特殊需要的话可以跟店主进一步沟通。
" width="640">

* 三多轩现场展售作品

浩天古旧书店

地址：广州市越秀区文明路148号（文德六巷內）
" width="640">

广州为数不多的旧书店，位于一条偏僻小巷里。不仅 贩卖图书，还可见各种 年代久远的二手物品，譬如老式的电话、挂钟、煤油灯、邮票、碗碟等。对年纪尚轻的我来说，在这里不仅仅是找寻回忆，更是大开眼界。

" width="900">

● 重点推荐 ：老地图

这里不仅有五六十年代的旧画报、罕见的广州老照片，最特别的是那些在图书馆都未必能见着的 城府地图。裱在画框之中，封存的不仅是一幅极具特色的复古装饰，更是一段引人遐想的历史。
" width="900">* 部分作装裱展示的老地图

---------------------------------------------

更多美家灵感，欢迎关注PChouse家居杂志公众号 （PChouse2012）

华强北成老外淘金地？揭秘淘宝上的iPhone黑色产业

Thu, 13 Jul 2017 22:41:08 CST

之前我们报道过老外来华强北掘金，花2000元组装出一台全新的苹果6S手机，现在又有老外发文感叹华强北的强大，国内群众表示：就喜欢看老外没见过世面的样子！今天我们不妨来聊聊，淘宝上那些“特殊”的iPhone的产业吧！

老外与他DIY的6S

近日，福布斯发布报道称，该站一名记者在几个月前，仅仅使用300元人民币，就把 iPhone 6改造成了一部iPhone 7。

老外对华强北大神这几点称赞有加： 1、不是对iPhone 6换壳打磨，而是将所有零件移位到iPhone 7的外壳中。 2、仿制iPhone 7摄像头凸起（大眼）。 3、整个过程仅30分钟完成。

虽然老外对华强北大神无比钦敬，而且还觉得300元改造费很划算，但只能说该老外被套路了，淘宝随便一搜，200不用就有交易，而且还有各种“人性化”服务，我们来看看都有哪些：

换壳

首先是后壳改造，价格便宜，而且各种颜色都可以选，咋一看好像还行，但仔细想想这种后壳是很不靠谱的，这个价钱是不可能买到原装iPhone 7外壳的，更不用说加上人工费了，所以用上的只能是高仿外壳，手感有着天壤之别。

而且这种外壳是跟着7代走的，所以3.5mm耳机孔也给取消掉了，以后只能用反人类的雷电接口，值得吗？更不用说这种大规模的“手术”，很容易让手机带来后遗症，售后问题麻烦的只有自己。

虽然如此低成本就能让自己的爱机焕然一新，但仔细想想中间有着太多的取舍了，越折腾你会发现自己的手机比以前差多了，怎么用怎么不舒服，倒不如买台新手机算了，所以没事就别乱改造自己的手机了，新鲜感过后，无趣可能更甚从前。

扩容

比起换壳，扩容的实用性就强太多了。由于iPhone的ROM差价实在太高了，所以囊中羞涩的朋友一般会买16G 的乞丐版，结果当然是哭着说内存不够用了，而扩容业务正好能解决这类人群的痛点。

价格方面，iPhone 6/6p 系列升级 32G/64G/128G，需要 180/380/580元左右，6s/6sp系列要贵上几十块。其实三百多换个64G还是很不错的，比16G多上4倍的空间，使用起来宽裕很多。从苹果6开始几代机型都没有大改进，10月推出的全面屏iPhone价格肯定会创新高，而且不好买，所以把过保的老6扩容一下，再战个2年不成问题。

有人担心扩容会减少手机的寿命，老实讲，扩容比换壳简单太多了，通过工具将原内存的数据写入到新内存，再把2个闪存芯片替换，最后刷机激活即可，对于工具齐全，技术过硬的华强北师傅来说，简直是小菜一碟，你还可以顺带把不给力的电池换了，直接满血复活。

解网络锁

苹果手机真的让人又爱又恨，很好用很好看，很能装逼，最重要的是很贵，预算吃紧的朋友会被低价吸引，而去购买有锁的iPhone，买回来就陷入无尽的卡贴折磨，后悔不已，机灵的商家则趁机推出号称能告别卡贴、一劳永逸的解锁业务。

解锁业务里面有着太多套路，简单介绍一下：

有锁是指苹果服务器通过IMEI对此机器进行运营商网络锁定。非此运营商的卡是会无服务的。

官解意思是运营商解锁，变为真正的无锁机。

黑解是通过非正常手段更改IMEI的激活策略，让该IMEI通过服务器的认证，在一段时间内成为无锁机。

目前美版ATT/Sprint、日版AU/SB 都能官解，即使进了黑名单给钱依然能解，至于黑解渠道并不是时常开放的，所以解锁的同志无需太担心，黑解也不一定就会被反锁，找家口碑好点的店家就好，其实现在卡贴技术已经非常成熟，没以前那么鬼畜了，不想折腾的朋友可以安心用卡贴了。

目前各地区的iPhone价格差距并不大，没必要为便宜几百块选择有锁的机器，因为官解的价格已经500元起跳了，加起来跟买一个港版/国行相差无几，当然你有特殊渠道能入手差价巨大的好货另说，一般用户就没必要去贪小便宜，把心思花在更重要的地方吧。

解ID锁

除了网络锁，苹果手机还有一种锁机方式叫ID锁，这种解锁是所有业务中最“邪恶的”，分分钟在挑战人性。

这种带ID锁的手机，基本是被盗或者是丢失的，贪小便宜的人买了第一件事就是要把这个ID锁给破解掉，解锁的难度高吗？美国FBI花了无数人力物力才艰难破解的ID锁，你觉得淘宝的小作坊能轻易的秒解吗？

其实这种解锁说白了就是钓鱼解锁，仅仅是通过屏幕上显示的手机号或邮箱，联系到真正的失主。通过钓鱼或者诱骗的方式，索要到机主的密码。

更狠的会通过破解绑定邮箱的方式修改密码，APPLE ID安全性极高，基本是没人碰的，网易邮箱就爆出遭黑客撞库数据泄露的报道，选择安全性高的邮箱很有必要。

淘宝还好有什么动静可以申请退款，但有精美官网，专属客服的解锁团队就要小心了，什么官解、高级权限、独家技术等等都是骗人的，只会让你一步一步的跌入解锁陷阱。

钓鱼邮件

小编是极其鄙视这种购买赃机、贪图小便宜的行为，因为不仅自己会受骗，而原失主也遭受损失，最后获益的只会是小偷和这些无良商家。

换新

苹果手机除了价格贵，身子也很娇贵，碎屏是常有之事，这时候当然是到天才吧修了，不过官方维修费用很可能让你吃不消，屏幕换新能修的话价格咬咬牙还可以，但如果客服跟你说要整机更换的话，那么就要支付2K以上的费用了。

到没授权的小店维修，价格能下去一大半，但机器会失去保修资格，不值得。得益于苹果只换不修的保修策略（现在被坑得多，也开始维修了），相关售后人员私底下提供加钱换新机服务，碎屏、进水、变形都可以加钱帮你换新机。

价钱方面以碎屏换新为例，换新成功的机子 600元起跳，如果机器情况恶劣的收费更高，但现在苹果不会一味的换新，换主板或者小件的 400元起步，拒保的话也会收 200元，因为店家是把碎屏机的屏幕修好，才拿去售后换新机的，拒保的话店家会收这部分的修理费。

图片来源淘宝

整个换机过程需要10个工作日左右的时间，流程还是比较正规的，至于会不会被店家坑，换零件之类的，这些就不用太多虑了，毕竟官换出来的机子就是全新的，保修信息能通过激活策略查询。

寻回

苹果手机除了自己喜欢，小偷也很喜欢，被盗率非常高，手机丢了不要紧，最重要的是怕里面的个人信息被滥用，后果不堪设想，通常报警的话，找回率偏低，基本是石沉大海，为了提高找回率，淘宝上惊现外国人报案帮找回iPhone业务。

由于中国是礼仪之邦，机关部门为了不丢国人面子，于是对这类案件比较上心，情有可原，聪明的商家机灵地操办起了这项业务，中间有着很多不可描述的套路。

收费居然要1200元，找回不找回都要收钱，注定是少数人适用的，如果手机真的特别重要势必要找回，那么在没别的办法的情况下，这种服务自然有它存在的价值。

可以说苹果这个企业是非常伟大的，单纯一个产品能衍生这么多产业链，养活这么多人，但终究只是一台手机，并没有更多的含义在里面，大家没必要为了这个一件消费品而伤财费神，毕竟用上苹果生活也不会好过一点。

查看评论

聊聊淘宝天猫个性化推荐技术演进史

Thu, 11 May 2017 08:00:00 CST

引言：个性化推荐技术直面用户，可以说是站在最前线的那个。如今，从用户打开手机淘宝客户端（简称“手淘”）或是手机天猫客户端（简称“猫客”）的那一刻起，个性化推荐技术就已经启动，为你我带来一场个性化的购物之旅。本文将细数个性化推荐的一路风雨，讲讲个性化推荐技术的演进史。

本文选自[《尽在双11——阿里巴巴技术演进与超越》。

1、个性化推荐All-in无线

无线个性化推荐起步于2013年10月。现在往回看，当时的阿里很好地把握住了移动端快速发展的浪潮，以集团All-in无线的形式吹响了移动端战斗的号角。个性化推荐团队也是从All-in无线这一事件中孵化的。我们从零开始搭建了个性化推荐算法体系及个性化算法平台TPP。TPP这一个性化算法平台对个性化推荐团队的成长起到了至关重要的作用。基于TPP，个性化算法团队成员们验证算法的速度得到了极大的提高，优化算法的速度从而也得到了极大的提高。仅仅花了不到两个月的时间，个性化推荐的第一版算法就在“有好货” 中初露锋芒：结合基于主动学习的选品算法平台TSP，个性化推荐团队一举打造了“有好货”针对高端人群的优质导购体验。

2014年，随着个性化推荐算法团队对业务问题有了更好理解，以及技术研发的深入，我们逐步开发并上线了排序引擎RTP、标签探索算法PairTag及在线学习引擎Olive（如下图所示）等多项核心技术。个性化推荐算法也因此被快速地应用到“发现好店”、“爱逛街”、“猜你喜欢”及购物链路等手淘的各个主要场景中。其中，手淘底部的“猜你喜欢”商品瀑布流推荐是亿万用户每天登录手淘后必逛的场景，为人们搜寻和发掘自己喜好的商品提供了便捷的渠道。“猜你喜欢”也一举成为中国电商中最大的推荐产品。

正是在All-in无线后的这一年，个性化推荐开始在阿里逐步成长起来。

2、个性化推荐初逢双11

2015年，个性化推荐第一次在双11中大放异彩。还记得当年9月中旬，我们正在维也纳参加推荐系统最大的会议RecSys。逍遥子突然来电，告知在2015年双11上要全面开启个性化推荐，随行的同事们都很兴奋，但我们又不得不面临缺乏双11实战经验的实际问题。当然，机会和风险往往是并存的。面对挑战，我们很快开始规划进程和分工。回到杭州之后，团队全员进入备战状态，我们的努力在双11当天得到了回报。2015年11月12日凌晨，推荐算法团队、手淘及天猫的众多小伙伴们并不觉得疲乏，大家的脸上都闪烁着喜悦。个性化推荐算法在双11大放光芒，一个又一个令人瞠目的数字足以为证。个性化推荐的第一战场“双11主会场”更是自双11开展多年以来首次达到了个位数的跳失率，其引导人数和人均引导页面数都是前一年的2～3倍。不得不说，这些令人振奋的结果都要归功于之前两年中个性化推荐在无线端的落地。

2015年双11主会场个性化算法（即“天坑一号”，如下图）包括三个层次：楼层顺序个性化、楼层内坑位个性化、坑位素材个性化。这三个层次自顶向下，在用户体验上形成一套完整的方案。其中：

楼层顺序个性化使得女神看到的楼层顺序可能是女装、美妆、天猫国际等，欧巴看到的楼层顺序可能是男装、旅行、数码等。
楼层内坑位内容个性化，使得在同一个楼层内，不同用户看到的商品或店铺不同，比如同样都是美食控，喜欢辣味的用户可能看见麻辣牛肉干，喜欢甜味的用户可能看见巧克力。
坑位内容素材个性化，使得同一个楼层的同一个坑位，即便算法预测两个用户都需要巧克力，但一个喜欢费列罗而另一个喜欢德芙，也会在入口图上展示不同的品牌。

这三层个性化中涉及多策略推荐算法、排序学习、合图等多项技术。整个项目的进展用六个字来总结就是“时间紧任务重”。在多个团队的辛勤工作及紧密协作下，我们第一次全方位地将自All-in以来所积累的个性化推荐技术用于如此复杂的场景之中。

个性化推荐在“双11主会场”取得成功的因素有很多。其中，最值得称道的莫过于“首图个性化”。在指甲壳大小的空间上，我们对产品创意素材和文字进行精雕细琢和个性化投放。这一改变极大地提升了用户活跃度，并催生了2015年双11主会场的个性化项目。该项目的成功上线成倍地降低了会场跳失率。更重要的是，个性化推荐为用户带来了全新的无线端购物体验，并且为阿里在电商领域的茁壮成长带来了显著的助力作用。个性化推荐算法团队因此荣获2015年CEO特别贡献奖。下面引用阿里巴巴CEO逍遥子嘉奖信里的一段话：“这次双11的一大亮点是，我们基于大数据的无线产品和技术的创新，使得整个运营效率有了大幅度提升。淘系的活跃用户得到了充分的引导和互动，得到了大量个性化的展示和推荐，事实证明了大数据的巨大威力。我们用大数据赋能了双11，赋能了我们自己的运营能力。”
正是在2015年双11之后，个性化推荐的故事开始为人们津津乐道。

3、个性化推荐再战双11

2015年双11之后，个性化推荐团队乘风起航，继续发力。正是这一年的持续发展，使得个性化推荐在2016年双11中更进一步，遍及无线端的各个场景。包括主会场在内的几乎全部活动会场、产品都实现了个性化算法投放。个性化推荐团队的代表作“海神”以及“鲁班”（下图为鲁班批量生产的创意Banner）都是首次在双11中亮相。

在2016年双11中，面对更为复杂的个性化需求，乐田及工程师们将全面升级后的个性化推荐完美地展现在双11主会场中。虽然2016年的双11主会场与2015年的“天坑一号”主会场极其相似，但这一次个性化推荐产品做得更为精细了。其中，GBDT+FTRL、Wide & Deep Learning和AdaptiveLearning这三项最前沿的机器学习技术被应用到了主会场的三层结构中，极大地提升了在线模型的效果及实时预测的效率。

除了常规的个性化推荐之外，我们在2016年双11开始尝试融合商家流量分配的个性化推荐。逍遥子在2015年双11总结中提到：“我们还要更上一层楼，利用大数据赋能给所有的商家，帮助他们运营好消费者，这样才能让我们在大数据时代践行‘让天下没有难做的生意’的使命。”随着个性化场景的不断升级，商家很多时候都对流量的波动束手无策。对那些有运营能力的商家来说，我们希望其通过更多优质的商品和优秀的服务换来更多的流量或销量上的部分确定性。因为推荐各场景大小不一、定位差异大，有导购类场景、有成交类场景等，我们需要根据场景本身的特性来进行流量智能调控。因此，商家赋能个性化推荐系统 — Matrix应运而生。Matrix系统主要用于调节用户体验、卖家流量诉求和投资回报率、电商平台健康度等方面的效用，平衡场景的短期收益和长期收益。在2016年双11中，Matrix在部分场景的上线为今后的卖家赋能积累了宝贵的经验。

4、个性化推荐的智能未来

个性化推荐从无到有，直到演进成为CEO逍遥子口中的“电商基础设施”，这一切来得极为不易。面对更具挑战的未来，个性化推荐可以做得更好、更智能，而基于全局信息的个性化推荐将会是达成这一目标的重要途径。
众所周知，个性化推荐涉及多种不同层次、不同粒度的子任务。从推荐内容上来说，个性化推荐分为商品推荐、店铺推荐、品牌推荐、评论推荐等；从推荐目标上来说，个性化推荐分为点击率预测、转化率预测、成交量预测等。虽然我们当前设计的个性化推荐算法在TPP上实现了流程一体化，但我们对每个推荐场景面临的子问题却是单独建模的。如果能从全局的角度分析用户的喜好，个性化推荐必然能够更上一层楼。

2016年，我们已经通过深度强化学习（Deep Reinforcement Learning）技术对全局信息共享下基于多任务学习　　（Multi-task Learning）的个性化推荐进行了初步探索。从数据流通链路来看（比如下图所示的手淘场景数据流通图），我们可以很自然地将全链路多场景的推荐任务理解为推荐系统面向用户的连续决策过程。随着用户对不同推荐场景的持续浏览和交互，推荐系统对于用户实时需求和意图的理解会越来越清晰，因此也可以更准确地为用户推荐更为合适的内容。深度强化学习已经在人工智能领域掀起了新的浪潮，这一技术必将成为个性化推荐智能化的最强武器。

5、总结

个性化推荐所取得的成就是一个“意料之外却情理之中”的结果。仅仅经历了短短几年的时间，淘宝和天猫就从以人工运营为主分配流量和资源位的方式成功转变为以大数据和人工智能为导向的新方式。与此同时，我们初步建立了人工经验与算法投放协同工作的机制。自2013年年底All-in无线以来的沉淀和积累终于逐步转化成了果实。经过不断地积累和打磨，个性化推荐技术变得越发成熟和犀利，相信个性化推荐的未来会更好。

End.

转载请注明来自36大数据（36dsj.com)： 36大数据» 聊聊淘宝天猫个性化推荐技术演进史

[原]淘宝Buy+负责人胡晓航：从技术和产品维度看Buy+ VR购物

Wed, 16 Nov 2016 19:20:56 CST

导语：阿里巴巴是怎么做VR购物的？VR购物会成为电商的未来吗？此次公开课我们邀请到了Buy+负责人胡晓航，为你解答所有这些疑问。

一年一度的网购狂欢节“双十一”刚刚过去，这不仅仅是购物者的盛宴，也是各种新技术登场的时刻，其中就包括Buy+ VR购物。

有很多人喜欢网购体验，端着手机、电脑、Pad一页页浏览商品，但也有许多人怀念线下购物，那种和姐妹一起逛街、聊天，拿起一件商品查看标签和价格的感觉。VR购物或许就可以在这两种体验中找到一个中间值，让你同时拥有网购和实体店的体验。

Buy+于11月1日在手机淘宝上线，一个可以用VR手机盒子体验的购物应用，带你穿越到世界各地的商场购物，遇到喜欢的还可以直接线上下单。

除了这个手机版，此前阿里还公布过通过3D建模打造的HTC Vive VR购物体验。那么，阿里巴巴是怎么做VR购物的？VR购物会成为电商的未来吗？此次公开课我们邀请到了Buy+负责人胡晓航，为你解答所有这些疑问。

胡晓航简介

胡晓航，Buy+负责人，负责VR业务的探索。手淘无线技术专家，虚拟互动的负责人，给双十一提供各种好玩的虚拟互动。

以下内容整理自胡晓航在硬创公开课上的分享：

大家好！我是来至阿里巴巴的宋五，目前负责Buy+和造物神计划。今天从三个维度看BUY+，一是数据、二是愿景、三是技术和产品。

Buy+的数据

首先简单过一下可以公开的数据。

这次的Buy+其实是在11月11日上线的，已经完成了整个购物链路，而不是停留在修demo的阶段了。我们还是想去尝试一下用户对VR购物持有怎样的态度。

从以上数据看出，大家对新鲜事物还是有兴趣去体验一下的。特别值得一提的是Buy+用户的年龄分布，还是以25-29岁的年轻人居多。以后VR的产品可能瞄准的也是这群人。

这次整个Buy+完成了三个国家七个场景的购物，商品数的话不多就百级别。想分享的故事就是在家就可以随时随地买遍全球。

Buy+的愿景

我们对Buy+的定义是探索极致的购物体验，一方面，通过 VR技术重建购物的环境和商品，利用合理的交互给大家提供比较真实的购物体验；另一方面，通过每次发布的产品去促进整个VR市场的发展，在用户端对VR有更多的认知。所以这方面投入了很多的心血。

目前已经尝试了PC的Buy+，在造物节的时候用HTC的VIVE做了两个场景，一个是买包的一个是买内衣的，体验的效果还不错，不过那时候只是一个demo，没有完成全链路。

这次的Buy+我们已经把全链路做通了，用户可以在手机淘宝的APP上完成整个购物链路。

我们希望用简单的方式，让普通用户有机会体验到VR的东西。当然我们未来还会尝试通过其他的手段，比如Detail AR把东西投影到现实的场景中看他的大小、形状、颜色。还有 Detail 3D去展现全方位的商品详情。我们还在尝试用VR构建线下的店铺，让线上用户对商家更有信任感。

Buy+的技术和产品

下面聊一聊大家比较关心的技术层面和产品层面的东西。我会通过以下四点展开来说：

一、为什么是全景视频+手机淘宝+Cardboard

首先，为什么用全景视频和Cardboard，并且在手机淘宝上来呈现。

因为现在Vive的方案是比较重的，除了VR设备还要买一台PC机，做出来的方案很难有大量的用户能够体验到。这样受众面非常窄，而且我们在造物节上做过一版Vive的体验。这次我们的考虑是让更多的消费者体验到VR，所以我们选择在移动端来实现这次的Buy+。

另外，考虑到客户端普及度的问题，我们没有用独立的App去做，而是在手淘上。这样可以让最大的用户群体验到VR购物，不需要下载用户不认识的新App。

由于我们希望更广泛的用户体验到VR购物，这也给我们的技术实现带来了很大困难。比如我们选择在手机淘宝App上实现，那么如果用了一个非常大游戏引擎，承载这些内容和交互，那会把手机淘宝App变得非常大。

为什么是全景视频？因为如果全用3D方案，建模起来需要时间成本；采用Cardboard而没有用一体机也是从成本的角度考虑。另外，我们送出了20万Cardboard。

二、场景建模

在全景视频+手淘+Cardboard 的情况下，场景建模我们选择了全景视频，因为成本和时间的考虑。

但也出现了一些困难，因为选择了全景视频后，环境的清晰度下降了，空间移动也变得困难。

这两块在接下来的商品建模和交互方式方面我也会讲到。

三、商品建模

商品建模方面，之所以有没用3D模型，是因为受到了交互方式的局限。Cardboard搭配手机，即使是完完整整的3D模型，交互方式也无法发挥3D模型应有的作用。比如，把3D模型拿过来，近距离地看，走动，都不行。所以这些用的是360度环拍的照片，每隔一定角度我们取一张照片。

有一个事情工作量非常大，就是在场景中旋转的照片需要把背景变成透明的，起初的时候觉得比较简单，通过绿幕拍完直接抠掉就好了，但实际情况并没有这么理想。

所以这部分投入了非常大的工作量。

四、交互方式

交互方式上，主要只有一个交互方式，就是盯住触发按钮。很多人发现的是其实Cardboard上点击的按键也是可以用的，但我们没有宣传。对于新事物，教用户更多的新交互方式也是有教育成本和风险的，一次教太多，用户反而可能不知所措。

因为已经是基于手机+全景视频了，所以交互上没有特别好的方式让你体验到PC上Vive的体验，没法拿着商品，也没法走动。

Buy+里标注的商品

不知道大家注意到一个细节没有，采用了全景视频以后，停下来商品总是能标定得非常准确。如果在纯3D的模型里这是非常简单的，但现在是一个视频，要每时每刻都知道物品在哪里，是非常有难度的。

假设一个视频每秒有60帧，是60张图片，如果用手工一张一张去标商品在哪里，这个工作量肯定是接受不了的。

最后我们尝试了一些方案，碰到过的“坑”这里分享一下：

1、图片识别

作为技术人员，我们首先想到的是做图片识别。有一个标定的图片，然后跑算法，一帧一帧去算，看每张图片里是不是有你想要的物品。

但是这个方案经过讨论以后很快就被否定，也没有去尝试，因为走到每个位置时看到的物品的面都不一样，这给图像识别带来很大难度。而且很多商品在场景中看上去并不是那么大，对图像识别的要求实在太高，按照目前的技术无法实现。

2、颜色识别

于是我们想到了一个办法，把整个全景视频拍两遍，第一遍正常拍，第二遍在有商品的位置用一个有特殊颜色的物品代替。然后用颜色的识别来取出商品相应的位置；

这里有两个难点，首先两次拍摄的速度必须是一样的，另外需要把场景中特殊颜色的位置全部用图像算法抠出来。

我们真实尝试时发现了两个问题，一是如果代替物很小，在整个图片中的像素表现是不够的；二是很容易被其它颜色干扰，比如灯光，每个商店的灯光不一样，而且环境中可能会有与物体颜色一样的东西。经过多次尝试后发现，这个方案也是不可行的。因为我们对现场的灯光跟环境基本没有控制力。

3、转换坐标系

这时我们又尝试了另外一个方案，我们开始拍的时候把视频的第一帧拿出来，所有物体离摄像头的距离都测出来。然后根据摄像头的匀速运动判断商品下一帧会在什么位置。

这个方案理论上蛮通的，但实现的时候也遇到很大技术困难，首先是匀速运动的问题，这个用轨道车可以解决。第二点，整个坐标系转化的问题，测量时一个很小的误差会导致坐标系转化（平面坐标转化为三维坐标）产生很大的误差。还有，每个摄像头的参数不一样，这导致每次坐标系转化的参数都要重新通过数据去训练。

我们尝试去训练Insta 360的一个设备，最后训练完拿到坐标系的参数，误差还可以。但是后来尝试其它摄像头，发现这个参数是完全不可用的。到此我们的第三种方案也基本可以认为是不可行的。

空间移动方案

这次我们完成了两个方向的全自由移动，原理也是蛮简单的，我们把一个视频拍完以后，转成一个倒播的视频。只需要在正向走动的时候播正向的视频。

3D商品的展示和交互体系

3D商品的展现，我们选择了一个蛮实用的方案，就是每个物品环拍一圈，然后每隔一定度数取一张照片，把它形成一个连播的文件。用户进来的时候，就默认先播一圈，但这里也有蛮坑的事情。如果商品和背景需要融合得很好的话，需要把背景抠成透明的。我们做了几百个商品，每个商品都有很多张图片，基本上属于不能完成的工作量。

我们通过绿幕的手段，结合一些图片提取的方法让效率变得很高，最终把这件事情完成。

刚才提到功能上线在手淘，像这种超级app对包的大小非常敏感，导致我们没法用一些现成的游戏引擎。里面所有UI和交互都是我们自己用Open GL研发的。

我们构建了自己的坐标体验，事件的调度体系，UI复用还有粒子系统，动画系统和事件检测机制。

Buy+项目的开发投入和内容制作

整个项目做了3个月左右，我们做了所有的开发、尝试，在3个国家取了7个场景。最后把场景和Buy+的产品融合起来。

各方都是并行开始的，在还没有开发完产品的时候通过讨论和技术的实现就已经定了内容的方案，内容组的同事就已经出发去拍摄了，开发组的同事还在开发，需求偶尔还会有一些变更。

可以想像，在这种情况下做出的内容要和系统完全匹配的难度是非常高的。

这里不得不提一些拍摄内容的注意点，现在市面上拍摄有两个设备用得比较多，一个是GoPro一个是360，使用场景也不一样。GoPro的货柜间距要求会大一点，大概1点多米，360的话间距小一点，每边是0.6-0.8米的样子。

比如拍日本药妆店，货柜放的非常近，因为安全距离的问题很难拍，所以用了360的摄像头，当然360的摄像头肯定没有GoPro那么好。

还有拍摄VR视频时建议能用静止就静止，如果一定要移动，就稳稳匀速移动，不然有转弯或不是匀速的话，戴上去一分钟大家就会晕得要死。

这就是选择手机上做VR购物引起的问题，现在手机上没有好技术来实现空间移动。

由于安全距离的问题，对小商品的细节描述会遇到问题，比如货柜上的手表会看不清楚。

最后我们用子场景来解决，也就是走到一个区域时，我们让你进入另外一个场景，这个场景是全景图片，这个时候商品细节表现会好一些。

刚才一些注意点好多刚开始定方案时是没想到的，到实际拍时，技术的同学跟过去才发现这些问题，也导致了产品上非常多的一些反复。

最后我们大概投入了7、8个市场运营和技术人员完成内容拍摄和后期制作，投入了大概20个开发人员把底层产品开发完毕，可以想像过程有多少紧张。

本地开发的适配问题

除了工作量跟没有经验可以借鉴外，其实还有一个蛮重要的问题，这次所有开发用的是原生Native，而不是H5的方案。由于双十一所有的产品都要做一程度的保密，所以没办法做大规模灰度验证。因为按以往的开发惯例和经验，Native的东西上线需要做一些线上的灰度，让线上一些真实的用户来发现一些隐藏的问题。

Buy+在手淘里的入口

既然不能去做线上灰度，如何保障线上技术稳定呢？我们做了几个方面的事情，首先，我们适配了目前70几款主流的设备，保证其在这些设备上的运行是没有问题的。

并且每一次改版都需要重新去适配，因为也不知道改版对兼容性会造成什么样的问题，特别是Android，它有4.X、5.X、6.X，甚至7.X的系统，在每个版上的表现是不一样的，适配问题上真的是投入了巨大的人力物力。

另外，我们做了很多的降级预案，比如我们把性能比较差的机器直接列入了降级名单，让它看全景的图片，而不是像现在看有标定又有移动的全景视频方案。

当然，所有的机型都可以加白名单和黑名单，也准备了很多降级开关，比如万一崩溃比较多，而且是针对某些机型的话，也可以顺手将这些机型降成全景图片，甚至屏蔽其玩Buy+。

听起来加白名单黑名单这件事很简单，其实并不是这样。特别针对Android来说，不可能将市面上所有机器都做一轮适配，行的加白名单，不行的黑名单，这个事情是几乎做不到的。白名单的事每年都在提，但根本没多少用处，因为不可能将所有机器都列出来。

唯一可能采用的方案就是黑名单，但也有问题，就是只能发现一款加入一款，这样很难确保线上不会出现大面积崩溃。这次我们基本上把Android 4.X以下的机器都降级了。Android上还有部分机器陀螺仪不行，这部分也全部降级了。

iOS也不是完全没有问题，如果操作系统升上10.0时也会遇到陀螺仪调不同接口返回的情况不一样。

总之，如果采用Native的方案，要保证线上尽量少的崩溃，需要考虑的问题是非常多的。其实到上线的最后一刻，我们还是没有信心说这个东西上去完全没有问题，不会出现大面积崩溃，当然最后的结果验证我们的努力是没有白费的。

全链路购物

最后一点技术的问题，提一下全链路购物的事情，大部分的VR从业者开发的同学不是特别了解交易链路和支付链路的事情，它其实是一个蛮庞大和复杂的系统。举个简单的例子，做一个商品详情，看上去展现的东西并不多，测试的同学会告诉你这里面有几千个Test Case，大家可以感受一下它的复杂度。

当然商品详情这种还算比较简单，如果涉及到优惠价格体系和支付宝链路的话，里面的复杂度不是几个人或者某几个团队可以搞清楚。所以这次开发都有核心的业务团队参与了，比如支付有支付专业的团队帮助开发，支付宝的同学也过来跟我们一起做VR适配。

Buy+里的支付环节

即使是这样，其实在完成整个交易链路的时候还是遇到了蛮多问题，比如优惠方案是怎么样的，在Buy+渠道只能有Buy+的优惠，但是你会发现，一旦给了他优惠，在其它地方搜索了Buy+的商品也会有优惠价格。这样种种交易链路上的问题都要一个个去趟开。

造物神计划

整个造神计划，我们的宗旨是，让新的内容产生得更加容易。目前还是聚焦在3D模型的建模上，只有更好的3D场景和商品，我们才能在VR领域走得更远。所以这次双十一上，我们也借助buy＋重启了造神计划。希望和大家一起把3D建模这件事情做到极致。

目前我们推出了3种不同级别的解决方案，第一种是DIVA（Digital Interactive Visual Augmentation数字化交互视觉增强）。

它在手机淘宝上已经开始应用了。核心的技术其实也是通过180轴的转动，拍照片、视频，再提取里面的关键帧，根据陀螺仪的信息显示里面的关键帧，可以大幅度提升商品和用户的交互过程。

第二种方案，我们采用的方案是视频扫描方案。这种方案相对于上一种方案的成本可能会高一些。扫出一个商品，价格可能在200-300元左右，为这个扫描我们还是做了很多平台化的事情。比如我们所有的的扫描、贴图、计算、模型计算都把它放在了云端，不需要你去买一个特别好的PC机去承载这些东西。

光场方案

最后一种方案，是还在“寓言”中的方案——光场扫描。这个方案对建模难度非常高的商品是有比较好的效果。举个例子说，如果你用3D扫描仪去扫出来的手机可能只能做出iPhone的亚黑色，但用光场的技术去做，可以做出iPhone的亮黑色。

这是一个造神计划的邀约链接：http://zao.alibaba.com，大家有兴趣的话可以一起参与到3d建模中来。

问答环节

网易游戏工程师：为什么Buy+现在采用的移动方式没有选用VR应用中常见的那种瞬移的方式——就是看向哪个点，就瞬间传送到那个点？

胡：如果用瞬移的方式，无论从场景采集的复杂度和眩晕度来讲，我觉得可能都比这种直线移动会好一点，毕竟我在体验的时候觉得，移动过程中加载的那些视频资源挺浪费的，因为我只会盯着地面移动，而且停下来的位置有时离商品很远，不如预设几个点来的好。

网易游戏工程师提的方案我们考虑过。我们现在没有用3D场景，但是我们考虑过用全景图片。一个场景一个场景的跳跃移动，这个在我们的降级方案里面用了，我们觉得这个的自由度没有视频的好。视频的移动是去模拟正常的逛店铺的感觉。

怎么平衡瞬移和模拟正常移动两种方案的优劣，和如何进一步优化，我们现在也已经有了新的方案会去尝试。

云治（Buy+产品负责人）：瞬间移送最好要有模型，纯全景图或视频是没有空间定位的。场景最大的问题在于你要真实感，现阶段比较低成本靠谱的就是全景图和全景视频，缺陷是没有空间定位。如果用场景模型，有了空间定位，缺点是很难建模到照片级别的真实感，或者手工优化成本太大。不过目前我们已经找到同时具备照片质量+空间定位的低成本方案了。

三星研究院研究员：1、 “光场扫描“具体什么设备？2 、全景视频拍摄用什么设备移动的？

胡：商店里面是轨道车，不能用轨道车的地方就是人的头盔上安装拍摄设备，用电动车。

三星研究院研究员：商品的照片级渲染如何能够降低后期人工修正成本，是否可以让广大商家自行增加？

云治：在商品方面，商家没有这方面的技术能力的，一般都是找ISV。你们就理解一个最简单的逻辑，商家的商品拍摄通常都是寄给ISV来拍摄的，然后ISV回传素材，商家把素材发布到线上。这样成本、效率、质量都是要考虑的部分。在场景方面，现在的全景店铺还没有到说成本有多少的时候，基本上属于探索阶段，商业的价值还没有说清楚。

雷锋网原创文章，转载请注明来源出处

作者：leiphone 发表于2016/11/16 11:20:56 原文链接

阅读：0 评论：0 查看评论

小米工程师回应Android应用为啥启动慢|淘宝躺枪

Thu, 15 Dec 2016 22:07:10 CST

关于安卓系统体验差、不流畅的言论一直存在，尤其是应用启动速度相比 iOS 有着不小的差距。

对此，前锤子科技 CTO 钱晨@工头 Jeff 今天在微博上发问，启动 app 动作迟缓(卡顿)的本因是什么？

这一问题引发了业内不少人士的讨论，其中小米 MIUI 开发的@Mkey_小米表示，造成卡顿的原因有很多种，具体来讲，包括应用启动时 CPU 给的不到位；内存不到位，甚至必须杀后台才能把当前的启动起来，还不行就走更慢的回收过程；还有一部分原因是应用写的差，比如淘宝，一启动五六十个线程，好像食堂开饭一样饥渴。

而魅族的开发者@高爷也紧跟着回复，表示这种现象九成是开发者的锅，魅族的 ROM 在出厂时内置大部分应用都是要求秒开的。三星员工@戈蓝V也表示，用户一般认为是手机的问题，同样暗指大部分是开发者的责任。

那么问题来了，为啥在 iOS 上那么规矩，跑到 Android 上就成流氓了呢？

本文链接

淘宝头条指数发布“2016上半年淘宝手机网购报告”

Fri, 29 Jul 2016 18:35:00 CST

魅族一月连开4场发布会，华为、乐视、中兴、酷派等频推新品，iPhone7面世的传言不绝于耳……2016年上半年的手机行业在各个厂商的“机海战术”中残酷厮杀。

半年回首，哪个品牌最受欢迎？哪个品牌最吸金？哪些城市是手机消费的热区？又有年龄段的人成为购机主力？

近日，淘宝头条指数联合淘宝潮电街，发布“2016上半年淘宝手机网购报告”，排出“最热卖手机品牌”、“最吸金手机品牌”、“网购手机最多的省份top20”、“男/女性最青睐的十大手机品牌”等多份榜单，以淘宝网购大数据洞窥整个手机行业的特征和趋势。其中，苹果和小米雄霸各大榜单的前两位，而美图手机成为手机网购浪潮中的另类——成为销量前20的品牌中唯一的女性购买量超越男性的手机品牌。

整体消费趋势：无线化、年轻化、男性化

从整个行业操作系统的特征看，安卓操作系统的霸主地位仍难以撼动，占比65%，iOS系统占比27%，其他系统共享剩下的8%。

在消费支付特征上，76%的网购交易在无线端完成，PC端的份额不断缩减。

在消费人群上，网购年轻化趋势明显，29岁以下群体总占比超过60%，网购最多的是19-24岁这个群体，占比32%。

若从消费人群的性别层面看，手机网购行业呈现男性化主导的趋势，65%的手机网购由男性完成。男性最青睐的10大手机品牌是：苹果、小米、三星、魅族、华为、诺基亚、乐视、荣耀、酷派、OPPO。女性最青睐的10大手机品牌是：苹果、小米、三星、华为、魅族、诺基亚、OPPO、美图、荣耀、乐视。值得一提的是美图手机，女性购买美图手机的数量是男性的2倍多，这也是网售销量前20品牌中唯一的女性购买量超过男性的手机品牌。

消费热区城市：北上广在手机网购花销榜都输给深圳

苹果、小米、三星、华为、魅族，这5个手机品牌无论从整体网售销量还是成交额上都雄霸前列。诺基亚、酷派进入了“最热卖手机top10”，但却在销售额排行榜上跌出前十。索尼、美图销量未进前十，但却都进入了“最吸金手机top10”。

从消费热区看，网购手机数量最多的20个省份是：广东、江苏、浙江、山东、福建、四川、河南、河北、广西、湖北、安徽、湖南、上海、江西、北京、贵州、陕西、辽宁、云南和重庆。

而在消费热区城市方面，广州、上海、深圳、北京的网购量最多，但北上广在网购手机的花销榜上却都输给了深圳，这说明深圳市场更偏向消费价格更高的手机。此外，北上广之间也存在消费差异：黑莓在广州遇冷，在北京火热；魅族、乐视在广州的受欢迎程度又高于北京、上海。

淘宝头条指数

淘宝头条指数，是集网购趋势报告、消费行为数据研究等于一体、面向大众的数据可视化内容解读平台产品，聚焦生活消费领域。

淘宝头条指数，依托阿里系生态数亿用户丰富的浏览购物、人群消费、生活互动大数据，与淘系生态各方参与者、研究者合作，为市场和用户提供生活消费领域的权威数据和专业分析，是流行趋势的验证者，行业方向的驱动者，亿万用户的服务者。

目前，淘宝头条指数开始已与DT财经、“新榜”等新媒体平台深度合作。

浅析淘宝分布式调用跟踪系统

Sun, 01 May 2016 00:37:57 CST

分布式系统为什么需要分布式跟踪？

电商平台由数以百计的分布式服务构成，每一个请求路由过来后，会经过多个业务系统并留下足迹，并产生对各种Cache或DB的访问，但是这些分散的数据对于问题排查，或是流程优化都帮助有限。

对于这么一个跨进程/跨线程的场景，汇总收集并分析海量日志就显得尤为重要。要能做到追踪每个请求的完整调用链路，收集调用链路上每个服务的性能数据，计算性能数据和比对性能指标（SLA），甚至在更远的未来能够再反馈到服务治理中，那么这就是分布式跟踪的目标了。

在业界，twitter的zipkin和淘宝的鹰眼就是类似的系统，它们都起源于Google Dapper 论文，就像历史上Hadoop发源于Google Map/Reduce 论文，HBase源自Google BigTable 论文一样。

这样的系统通常有几个设计目标：

（1）低侵入性——作为非业务组件，应当尽可能少侵入或者无侵入其他业务系统，对于使用方透明，减少开发人员的负担。

（2）灵活的应用策略——可以（最好随时）决定所收集数据的范围和粒度。

（3）时效性——从数据的收集和产生，到数据计算和处理，再到最终展现，都要求尽可能快。

（4）决策支持——这些数据是否能在决策支持层面发挥作用，特别是从DevOps的角度。

（5）可视化才是王道。

先来一个直观感受

数据流转过程：

图1-1淘宝鹰眼的数据收集和存储

鹰眼的调用链绘制界面：

图1-2 淘宝鹰眼的调用链

鼠标移动到调用链的每一层点击，可以看到执行时长、宿主机IP、数据库操作、传入参数甚至错误堆栈等等具体信息。

淘宝如何实现的

同一次请求的所有相关调用的情况，在淘宝EagleEye里称作调用链。同一个时刻某一台服务器并行发起的网络调用有很多，怎么识别这个调用是属于哪个调用链的呢？可以在各个发起网络调用的中间件上下手。

在前端请求到达服务器时，应用容器在执行实际业务处理之前，会先执行EagleEye的埋点逻辑（类似Filter的机制），埋点逻辑为这个前端请求分配一个全局唯一的调用链ID。这个ID在EagleEye里面被称为TraceId，埋点逻辑把TraceId放在一个调用上下文对象里面，而调用上下文对象会存储在ThreadLocal里面。调用上下文里还有一个ID非常重要，在EagleEye里面被称作RpcId。RpcId用于区分同一个调用链下的多个网络调用的发生顺序和嵌套层次关系。对于前端收到请求，生成的RpcId固定都是0。

当这个前端执行业务处理需要发起RPC调用时，淘宝的RPC调用客户端HSF会首先从当前线程ThreadLocal上面获取之前EagleEye设置的调用上下文。然后，把RpcId递增一个序号。在EagleEye里使用多级序号来表示 RpcId，比如前端刚接到请求之后的RpcId 是0，那么它第一次调用 RPC 服务A时，会把RpcId改成0.1。之后，调用上下文会作为附件随这次请求一起发送到远程的HSF服务器。

HSF服务端收到这个请求之后，会从请求附件里取出调用上下文，并放到当前线程ThreadLocal上面。如果服务A在处理时，需要调用另一个服务，这个时候它会重复之前提到的操作，唯一的差别就是RpcId会先改成 0.1.1再传过去。服务A的逻辑全部处理完毕之后，HSF 在返回响应对象之前，会把这次调用情况以及TraceId、RpcId都打印到它的访问日志之中，同时，会从ThreadLocal清理掉调用上下文。

如图2-1展示了一个浏览器请求可能触发的系统间调用。

图2-1一个浏览器请求可能触发的系统间调用

图2-1描述了EagleEye在一个非常简单的分布式调用场景里做的事情，就是为每次调用分配TraceId、RpcId，放在ThreadLocal的调用上下文上面，调用结束的时候，把TraceId、RpcId打印到访问日志。

类似的其他网络调用中间件的调用过程也都比较类似，这里不再赘述了。访问日志里面，一般会记录调用时间、远端IP地址、结果状态码、调用耗时之类，也会记录与这次调用类型相关的一些信息，如URL、服务名、消息topic等。

很多调用场景会比上面说的完全同步的调用更为复杂，比如会遇到异步、单向、广播、并发、批处理等等，这时候需要妥善处理好ThreadLocal上的调用上下文，避免调用上下文混乱和无法正确释放。另外，采用多级序号的RpcId设计方案会比单级序号递增更容易准确还原当时的调用情况。

最后，EagleEye分析系统把调用链相关的所有访问日志都收集上来，按TraceId汇总在一起之后，就可以准确还原调用当时的情况了。

图2-2一个典型的调用链

如图2-2所示，就是采集自淘宝线上环境的某一条实际调用链。调用链通过树形展现了调用情况。调用链可以清晰地看到当前请求的调用情况，帮助问题定位。如上图，mtop应用发生错误时，在调用链上可以直接看出这是因为第四层的一个(tair@1)请求导致网络超时，使最上层页面出现超时问题。这种调用链，可以在EagleEye系统监测到包含异常的访问日志后，把当前的错误与整个调用链关联起来。问题排查人员在发现入口错误量上涨或耗时上升时，通过EagleEye查找出这种包含错误的调用链采样，提高故障定位速度。

调用链数据在容量规划和稳定性方面的分析

如果对同一个前端入口的多条调用链做汇总统计，也就是说，把这个入口URL下面的所有调用按照调用链的树形结构全部叠加在一起，就可以得到一个新的树结构（如图2-3所示）。这就是入口下面的所有依赖的调用路径情况。

图2-3 对某个入口的调用链做统计之后得到的依赖分析

这种分析能力对于复杂的分布式环境的调用关系梳理尤为重要。传统的调用统计日志是按固定时间窗口预先做了统计的日志，上面缺少了链路细节导致没办法对超过两层以上的调用情况进行分析。

例如，后端数据库就无法评估数据库访问是来源于最上层的哪些入口；每个前端系统也无法清楚确定当前入口由于双十一活动流量翻倍，会对后端哪些系统造成多大的压力，需要分别准备多少机器。有了EagleEye的数据，这些问题就迎刃而解了。

http://express.ruanko.com/ruanko-express_79/tech-overnight3.html

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

京东、淘宝、国美、Ebay、亚马逊都要做 VR 购物，但真正的战争可能要五年后才开始

Thu, 08 Sep 2016 20:32:48 CST

一个幽灵，VR 购物的幽灵，在各大电商平台 CEO 的心上徘徊。为了抓住这个幽灵，各大电商玩家们似乎已经从最初的保守观望转为跃跃欲试，要在这个新领域大干一场。9 月 6 日，京东宣布成立电商领域首个 “ VR/AR 产业推进联盟 ” ，组建 VR 实验室，发布 APP “ VR 购物星系 ” 。至此，无论是国内的京东、淘宝、国美，还是国外的 Ebay 和亚马逊，都已经逐渐露出了自己对于 VR 方面的发展动向和计划。那么，这场电视平台的 VR 战争究竟打算如何打？人们对于 “ VR 购物 ” 的幻想还有多久才能变为现实？

我们来看看各方现在的动向吧：

京东：建立 VR 产业联盟，发起 “ 群狼战术 ”

9 月 6 日，京东在北京举办了 VR / AR 战略发布会。从这次 VR / AR 发布会上看，京东打算在这两方面同时发力：购物 APP “ VR 购物星系 ” 提供的虚拟购物体验，产品参数说明以外，还能运用声纹、手势进行支付。 AR 家装产品计划则允许消费者在家装时直接通过 AR 产品看到自己的家装修之后的效果，设计师也可以远程 “ 入镜 ”，帮助消费者进行现场挑选及设计。

不过，最让人印象深刻的，还是京东的 “ 群狼战术 ”。相比淘宝的虚拟现实计划，京东 VR 一直较为低调。但此次发布会上，京东却显示出它已在虚拟现实布局已久：宣布联合英特尔、HTC、英伟达、暴风魔镜等 30 多家上下游企业成立电商领域的首个 VR / AR 产业联盟。未来三年内将与暴风魔镜达成采购合作，将销售 1500 万台 VR 头显；另外，京东还与 NVIDIA 达成采购合作，三年内将销售 1800 万片 VR 显卡。京东此次在合作上更多选择偏向大众普及型的暴风魔镜，可能是希望通过硬件普及，来解决 VR 购物消费者人群较少的问题。而针对商家缺乏 VR 技术，京东则希望提供一套统一的建模工具，使用者制作统一标准的电商应用和 VR/AR 内容，减低商家参与的门槛。这些方式，实际上正瞄准了购物端缺乏应用，购物端终端不普及，销售端缺乏展示能力，平台不统一这几个长期困扰 VR 购物的问题。远期目标中，京东甚至还涉足 VR 除购物以外的其他领域，要 “ 统一 VR、AR 标准和建立内容分发平台 ” 。京东这种高调宣言，无疑有跟老对手淘宝叫板的成分，但是 “ 群狼战术 ” 的声势与潜力，却也是人们不得不正视的事实。

淘宝：刷爆朋友圈的 “ Buy+ ” 要上线了，但这也许只是第一步

淘宝最让人所知的，无疑是两个月前的淘宝购物节上的 “ Buy+ ”。当时，这一体验曾经刷爆朋友圈。“ Buy + ” 之所以能够如此火热是有原因的：它提供了 “ 更换大小/颜色 ”，“ 买家秀 ”，“ 卖场展示 ” 等环节，是第一个较为完整的描述出 VR 购物体验的应用（尽管还难称成熟）。此外，相较于其他家只有体验者和商品互动的 VR 购物应用， “ Buy+ ” 还增加了虚拟导购员和社交的角色。

如果按照淘宝之前的宣传，本月 “ Buy + ” 就要上线了，但要以实际的购物体验而论，“ Buy + ” 仍然还有许多问题。最大的局限也是整个 VR 购物目前的局限：由于显示和采集现实画面仍有瓶颈，因此不得不以 3D 建模来替代真实物品。因而，除了颜色和款式以外，具体大小、材质、细节都无法测量。如果要提供更逼真和深入的体验，这付出的成本又是第三方的淘宝商家无法承担的。

不过，淘宝也许还有后手，在京东建立产业联盟之后，淘宝也可能会出台对应的策略，并且阿里对 VR 技术投入绝不吝惜：2月，阿里领投了 Magic Leap 的 7.94 亿美元融资，如果混合现实技术真的如宣传一样成功，它会是 “ Buy + ” 之后的核心技术吗？

国美：不是最大，但可能最靠谱

国美在这个地方出现可能会使你感到疑惑。它的量级看起来无法与前两个相比。这可能忽略了一个事实，国美经营的家装领域，相比较服装或者是其他产品品类，可能反而是最适合 VR 的。毕竟，VR 家装比起传统而言却是具有实实在在的优势，不仅是虚拟房屋里的直观和沉浸感，而且还可以让人做出巨大的改动：改变房屋结构，一秒切换墙纸，或是只为看看效果就把家具位置全部改换一遍，这些都只能在 VR 场景里面可能实现。这么看，从 VR 技术来看，国美的 VR 家装也许是电商平台中最靠谱，最容易成功的一个。

而在打法上，国美走了一条扎实的线下体验店路线。2016 年，国美将 VR 将成为重点发展项目，在全国 97 家线下门店打造 VR 智能体验区。国美在线依托线下门店建设集移动 VR 体验区、PC 端 VR 体验区以及场景式 VR 体验区三位一体的综合型 VR 体验场，如与暴风魔镜合作建立 VR 体验馆。在今天，国美在线又推出了家装 VR 系统。宣称用户可以 “ 自由更换设计风格和建材，现场下单交定金，实时监测装修过程，实现 F2C 的中间环节打通。 ”

eBay：第一家虚拟现实百货商店

在各个电商巨头中， eBay 是最早行动的一个。 5 月 16 日，电商零售巨头 eBay 同澳大利亚零售商 Myer 百货合作，推出了全球首家虚拟现实百货商店。当时 eBay 还为客户免费提供 1.5 万件虚拟现实设备 shopticals 。不过，从 5 月到现在以来，还没有看到 eBay 在 VR 购物中下一步的动向。

亚马逊：招兵买马中

亚马逊的 VR 战略很早就开始了，但是对 VR 感兴趣的是亚马逊影业，而不是亚马逊电商。这在很长一段时间也让人们猜测亚马逊是否对 VR 购物并不感兴趣。

不过，这个看法可能要改变了，上周，亚马逊通过一条招聘信息透露了自己的未来动向。 “ 2016 年，我们将搭配 Oculus Rift , HTC Vive 以及 PlayStation VR 游戏头戴设备发布实体和线上的增强现实购物体验，并登陆任天堂仍未正式公布的下一代游戏机上。” 这不禁让人们心怀期待，亚马逊会在 VR 购物上有怎样的表现？

展望 VR 购物：麻烦的不止是购物，而是技术的局限

综上所述，随着各巨头纷纷入场， “ VR 购物 ” 现在如火如荼。然而，真正要把宣称的话实现，并不是一件易事。

事实上，目前的 VR 购物一直争议不断，原因主要是用户量稀少，还有有着 “ 投入大 ”，“ 体验差 ”，“ 平台杂 ” 等种种恶评。但更实质的问题是，除了在少数领域，家装领域，大部分的品类上，VR 购物目前并不能比普通网购给消费者提供更多有价值的参考（例如服装，VR 试装平台宣称能给种种信息，却连最基本的尺码匹配问题都无法解决），3D 建模的粗糙多面体如果作为网游装备还无可厚非，如果要当做真实的商品参考，恐怕会让不少人望而却步。

京东 VR/AR 实验室技术总负责人赵刚表示， VR 购物应用离真正面向用户开放，至少还要 2-3 年。这实际上是一个非常乐观的预言。这背后的深层原因其实是：VR 购物最大的瓶颈不仅是 VR 购物终端的设计，而且是现有 VR 平台的局限。要达到全面的（而不是尝鲜的）VR 购物体验，在显示质量，传感技术，动作交互，场景模拟方面都必须超越目前的最高水平。巨头们的介入，短期内与其说是产生真正有用的 VR 购物体验，倒不如说是吸引曝光，同时做技术探索与储备。从这一点看，现在只不过是巨头们的跑马圈地，或者是 “ 前哨战 ”，真正的大战，看起来要五年以后才会开始呢。

淘宝SPM流量跟踪体系的研究

Thu, 22 Oct 2015 22:07:35 CST

一、什么是SPM

SPM是淘宝社区电商业务（xTao）为外部合作伙伴（外站）提供的一套跟踪引导成交效果数据的解决方案。下面是一个跟踪点击到宝贝详情页的引导成交效果数据的SPM示例：http://detail.tmall.com/item.htm?id=3716461318&&spm=2014.123456789.1.2 其中spm=2014.123456789.1.2 便是下文所说的SPM编码。

SPM编码：用来跟踪页面模块位置的编码，标准spm编码由4段组成，采用a.b.c.d的格式（建议全部使用数字），其中，

a代表站点类型，对于xTao合作伙伴（外站），a为固定值，a=2014
b代表外站ID（即外站所使用的TOP appkey），比如您的站点使用的TOP appkey=123456789，则b=123456789
c代表b站点上的频道ID，比如是外站某个团购频道，某个逛街频道，某个试用频道等
d代表c频道上的页面ID，比如是某个团购详情页，某个宝贝详情页，某个试用详情页等

如果是站内，则SPM编码会有第五个参数，具体为：

a：网站ID，每一个单独的网站（域名），分配唯一的ID，如www.taobao.com的aID为1，list.taobao.com的aID为a217f，item.taobao.com的aID为a217v，tmall是3，聚划算是608，搜索是a230r
b：网页ID，为同一个网站下每一个网页，分配唯一的ID，页面A ID为7274553，页面BID为7289245
c：频道ID，为网站中不同区域划分频道，每个频道分配唯一ID，
d：产品ID，为每个频道内的每个独立产品，分配唯一ID
e：同一个链接请求，为每次请求分配一个随机特征码，保证每次点击spm值的唯一性。

注意：spm的四位总长度32位，并且不支持%、&等特殊字符，请尽量使用英文以及数字

SPM的应用场景因为spm编码本身是有层次的，因此，我们可以：

单独统计spm的a部分，我们可以知道某一类站点的访问和点击情况，以及后续引导和成交情况。
单独统计spm的a.b部分，我们可以用来评估某一个站点的访问和点击效果，以及后续引导和成交情况。
单独统计spm的a.b.c部分，我们可以用来评估某一个站点上某一频道的访问和点击效果，以及后续引导和成交情况。
单独统计spm的a.b.c.d部分，我们可以用来评估某一个频道上某一具体页面的点击效果，以及后续引导和成交情况。

SPM的效果指标和数据查看基于SPM可以得到的效果统计指标：

PV：通过指定spm编码引导到宝贝详情页面的PV
UV：通过指定spm编码引导到宝贝详情页面的UV
支付宝成交人数：通过指定spm编码引导到宝贝详情页面的用户当天对同店商品的支付宝成交人数
支付宝成交笔数：通过指定spm编码引导到宝贝详情页面的用户当天对同店商品的支付宝成交笔数
支付宝成交金额：通过指定spm编码引导到宝贝详情页面的用户当天对同店商品的支付宝成交金额
客单价=支付宝成交金额/支付宝成交人数，代表通过指定spm编码引导过来的购买用户的消费能力
转化率=支付宝成交人数/UV，代表通过指定spm编码引导的用户最终转化为购买用户的比率

除此之外，还有许多其他参数，分别代表其他含义或者适用于其他业务统计需求。如pos代表的是位置，另外一个比较重要的参数为：scm=1003.632.1102.1

1003：投放系统ID，比如1003标识阿拉丁投放系统
632：算法ID，标识投放的具体算法
1102：标识投放算法的版本信息
1：标示投放针对的具体投放人群分类等信息

类似的跟踪方式还有凡客的体系，凡客与淘宝最主要的区别是跟踪参数ref的参数一直有继承，即是下一个点击会继承上一个点击产生ref，目前是继承到10级，然后就开始从原始的减少，一直保持10级。具体如下：

http://item.vancl.com/2810450.html#ref=hp-hp-yc-1_1-v:n|hp-hp-head-logo-v:n|s-s-c_rs_28806-1_3-6373505_Sort01_qb_000-v|hp-hp-classman-3_2-v:n

二、SPM体系有何作用

流量实现精准定位

流量可以标识到频道、页面、区块、位置任意层级
资源位的稳定唯一标识意味着效果可持续跟踪
位置和内容的分离标识，将土地和庄稼分开评估

运算资源消耗降低

通过编码的配置圈定多样的流量业务归属
CPU运算资源的大幅度减低

建立效果评估体系

流量资源价值的统一评估标准
建立以资源位为中心的数据体系和运营体系

流量运营的宏观调控+市场经济时代

资源位估值和定价
资源位的分层管理和运营
资源位商业化通道和流动机制
资源位竞价和排期

三、如何搭建SPM体系

流程约定 — 通过侵入页面发布流程，规范打点过程
工具支持 — 提供低成本进行流量资源布点工具集
技术保障 — 用户点击链接时，由全局js生成标识编码，有效避免标识重复和疏漏

参考资料：页TBI-梵易-页面资源位监测和价值分析(PPT)

淘宝数据产品技术架构分析

Thu, 31 Dec 2015 17:55:00 CST

淘宝网拥有国内最具商业价值的海量数据。截至当前，每天有超过30亿的店铺、商品浏览记录，10亿在线商品数，上千万的成交、收藏和评价数据。如何从这些数据中挖掘出真正的商业价值，进而帮助淘宝、商家进行企业的数据化运营，帮助消费者进行理性的购物决策，是淘宝数据平台与产品部的使命。

为此，我们进行了一系列数据产品的研发，比如为大家所熟知的量子统计、数据魔方和淘宝指数等。尽管从业务层面来讲，数据产品的研发难度并不高；但在“海量”的限定下，数据产品的计算、存储和检索难度陡然上升。本文将以数据魔方为例，向大家介绍淘宝在海量数据产品技术架构方面的探索。

淘宝海量数据产品技术架构

数据产品的一个最大特点是数据的非实时写入，正因为如此，我们可以认为，在一定的时间段内，整个系统的数据是只读的。这为我们设计缓存奠定了非常重要的基础。

图1 淘宝海量数据产品技术架构

按照数据的流向来划分，我们把淘宝数据产品的技术架构分为五层（如图1所示），分别是数据源、计算层、存储层、查询层和产品层。位于架构顶端的是我们的数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。这一系列的数据是数据产品最原始的生命力所在。

在数据源层实时产生的数据，通过淘宝自主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到一个有1500个节点的Hadoop集群上，这个集群我们称之为“云梯”，是计算层的主要组成部分。在“云梯”上，我们每天有大约40000个作业对1.5PB的原始数据按照产品需求进行不同的MapReduce计算。这一计算过程通常都能在凌晨两点之前完成。相对于前端产品看到的数据，这里的计算结果很可能是一个处于中间状态的结果，这往往是在数据冗余与前端计算之间做了适当平衡的结果。

不得不提的是，一些对实效性要求很高的数据，例如针对搜索词的统计数据，我们希望能尽快推送到数据产品前端。这种需求再采用“云梯”来计算效率将是比较低的，为此我们做了流式数据的实时计算平台，称之为“银河”。“银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。

容易理解，“云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。这是因为，对于“云梯”来说，它的定位只是做离线计算的，无法支持较高的性能和并发需求；而对于“银河”而言，尽管所有的代码都掌握在我们手中，但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中，避免不了分层，最终仍然落到了目前的架构上。

为此，我们针对前端产品设计了专门的存储层。在这一层，我们有基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom，在后面的文字中，我将重点介绍这两个集群的实现原理。除此之外，其他第三方的模块也被我们纳入存储层的范畴。

存储层异构模块的增多，对前端产品的使用带来了挑战。为此，我们设计了通用的数据中间层——glider——来屏蔽这个影响。glider以HTTP协议对外提供restful方式的接口。数据产品可以通过一个唯一的URL获取到它想要的数据。

以上是淘宝海量数据产品在技术架构方面的一个概括性的介绍，接下来我将重点从四个方面阐述数据魔方设计上的特点。

关系型数据库仍然是王道

关系型数据库（RDBMS）自20世纪70年代提出以来，在工业生产中得到了广泛的使用。经过三十多年的长足发展，诞生了一批优秀的数据库软件，例如Oracle、MySQL、DB2、Sybase和SQL Server等。

图2 MyFOX中的数据增长曲线

尽管相对于非关系型数据库而言，关系型数据库在分区容忍性（Tolerance to Network Partitions）方面存在劣势，但由于它强大的语义表达能力以及数据之间的关系表达能力，在数据产品中仍然占据着不可替代的作用。

淘宝数据产品选择MySQL的MyISAM引擎作为底层的数据存储引擎。在此基础上，为了应对海量数据，我们设计了分布式MySQL集群的查询代理层——MyFOX，使得分区对前端应用透明。

图3 MyFOX的数据查询过程

目前，存储在MyFOX中的统计结果数据已经达到10TB，占据着数据魔方总数据量的95%以上，并且正在以每天超过6亿的增量增长着（如图2所示）。这些数据被我们近似均匀地分布到20个MySQL节点上，在查询时，经由MyFOX透明地对外服务（如图3所示）。

图4 MyFOX节点结构

值得一提的是，在MyFOX现有的20个节点中，并不是所有节点都是“平等”的。一般而言，数据产品的用户更多地只关心“最近几天”的数据，越早的数据，越容易被冷落。为此，出于硬件成本考虑，我们在这20个节点中分出了“热节点”和“冷节点”（如图4所示）。

顾名思义，“热节点”存放最新的、被访问频率较高的数据。对于这部分数据，我们希望能给用户提供尽可能快的查询速度，所以在硬盘方面，我们选择了每分钟15000转的SAS硬盘，按照一个节点两台机器来计算，单位数据的存储成本约为4.5W/TB。相对应地，“冷数据”我们选择了每分钟7500转的SATA硬盘，单碟上能够存放更多的数据，存储成本约为1.6W/TB。

淘宝内部分享：MySQL & MariaDB性能优化

Thu, 22 Jan 2015 02:00:04 CST

MySQL是目前使用最多的开源数据库，但是MySQL数据库的默认设置性能非常的差，必须进行不断的优化，而优化是一个复杂的任务，本文描述淘宝数据库团队针对MySQL数据库Metadata Lock子系统的优化，hash_scan 算法的实现解析的性能优化，TokuDB·版本优化，以及MariaDB·的性能优化。本文来自淘宝团队内部经验分享。

往期文章：淘宝内部分享：怎么跳出MySQL的10个大坑

MySQL·　5.7优化·Metadata Lock子系统的优化

背景

引入MDL锁的目的，最初是为了解决著名的bug#989，在MySQL 5.1及之前的版本，事务执行过程中并不维护涉及到的所有表的Metatdata 锁，极易出现复制中断，例如如下执行序列：

Session 1: BEGIN;
Session 1: INSERT INTO t1 VALUES (1);
Session 2: Drop table t1; ——–SQL写入BINLOG
Session 1: COMMIT; —–事务写入BINLOG

在备库重放 binlog时，会先执行DROP TABLE，再INSERT数据，从而导致复制中断。

在MySQL 5.5版本里，引入了MDL, 在事务过程中涉及到的所有表的MDL锁，直到事务结束才释放。这意味着上述序列的DROP TABLE 操作将被Session 1阻塞住直到其提交。

不过用过5.5的人都知道，MDL实在是个让人讨厌的东西，相信不少人肯定遇到过在使用mysqldump做逻辑备份时，由于需要执行FLUSH TABLES WITH READ LOCK (以下用FTWRL缩写代替)来获取全局GLOBAL的MDL锁，因此经常可以看到“wait for global read lock”之类的信息。如果备库存在大查询，或者复制线程正在执行比较漫长的DDL，并且FTWRL被block住，那么随后的QUERY都会被block住，导致业务不可用引发故障。

为了解决这个问题，Facebook为MySQL增加新的接口替换掉FTWRL 只创建一个read view ，并返回与read view一致的binlog位点；另外Percona Server也实现了一种类似的办法来绕过FTWRL，具体点击文档连接以及 percona的博客，不展开阐述。

MDL解决了bug#989，却引入了一个新的热点，所有的MDL锁对象被维护在一个hash对象中；对于热点，最正常的想法当然是对其进行分区来分散热点，不过这也是Facebook的大神Mark Callaghan在report了bug#66473后才加入的，当时Mark观察到MDL_map::mutex的锁竞争非常高，进而推动官方改变。因此在MySQL 5.6.8及之后的版本中，引入了新参数metadata_locks_hash_instances来控制对mdl hash的分区数(Rev:4350)；

不过故事还没结束，后面的测试又发现哈希函数有问题，somedb. someprefix1 … .somedb .someprefix8 的hash key值相同，都被hash到同一个桶下面了，相当于hash分区没生效。这属于hash算法的问题，喜欢考古的同学可以阅读下bug#66473后面Dmitry Lenev的分析。

Mark进一步的测试发现Innodb的hash计算算法比my_hash_sort_bin要更高效， Oracle的开发人员重开了个bug#68487来跟踪该问题，并在MySQL5.6.15对hash key计算函数进行优化，包括fix 上面说的hash计算问题(Rev:5459)，使用MurmurHash3算法来计算mdl key的hash值。

MySQL 5.7 对MDL锁的优化

在MySQL 5.7里对MDL子系统做了更为彻底的优化。主要从以下几点出发：

第一，尽管对MDL HASH进行了分区，但由于是以表名+库名的方式作为key值进行分区，如果查询或者DML都集中在同一张表上，就会hash到相同的分区，引起明显的MDL HASH上的锁竞争。

针对这一点，引入了LOCK-FREE的HASH来存储MDL_lock，LF_HASH无锁算法基于论文”Split-Ordered Lists: Lock-Free Extensible Hash Tables”，实现还比较复杂。注：实际上LF_HASH很早就被应用于Performance Schema，算是比较成熟的代码模块。由于引入了LF_HASH，MDL HASH分区特性自然直接被废除了。对应WL#7305， PATCH(Rev:7249)

第二，从广泛使用的实际场景来看，DML/SELECT相比DDL等高级别MDL锁类型，是更为普遍的，因此可以针对性的降低DML和SELECT操作的MDL开销。

为了实现对DML/SELECT的快速加锁，使用了类似LOCK-WORD的加锁方式，称之为FAST-PATH，如果FAST-PATH加锁失败，则走SLOW-PATH来进行加锁。

每个MDL锁对象（MDL_lock）都维持了一个long long类型的状态值来标示当前的加锁状态，变量名为MDL_lock::m_fast_path_state 举个简单的例子：（初始在sbtest1表上对应MDL_lock::m_fast_path_state值为0）

Session 1: BEGIN;
Session 1: SELECT * FROM sbtest1 WHERE id =1; //m_fast_path_state = 1048576, MDL ticket 不加MDL_lock::m_granted队列
Session 2: BEGIN;
Session 2: SELECT * FROM sbtest1 WHERE id =2; //m_fast_path_state=1048576+1048576=2097152，同上，走FAST PATH
Session 3: ALTER TABLE sbtest1 ENGINE = INNODB; //DDL请求加的MDL_SHARED_UPGRADABLE类型锁被视为unobtrusive lock，可以认为这个是比上述SQL的MDL锁级别更高的锁，并且不相容，因此被强制走slow path。而slow path是需要加MDL_lock::m_rwlock的写锁。m_fast_path_state = m_fast_path_state | MDL_lock::HAS_SLOW_PATH | MDL_lock::HAS_OBTRUSIVE
注:DDL还会获得库级别的意向排他MDL锁或者表级别的共享可升级锁，但为了表述方便，这里直接忽略了，只考虑涉及的同一个MDL_lock锁对象。
Session 4: SELECT * FROM sbtest1 WHERE id =3; // 检查m_fast_path_state &HAS_OBTRUSIVE，如果DDL还没跑完，就会走slow path。

从上面的描述可以看出，MDL子系统显式的对锁类型进行了区分（OBTRUSIVE or UNOBTRUSIVE），存储在数组矩阵m_unobtrusive_lock_increment。因此对于相容类型的MDL锁类型，例如DML/SELECT，加锁操作几乎没有任何读写锁或MUTEX开销。对应WL#7304, WL#7306 ， PATCH（Rev:7067,Rev:7129）(Rev:7586)

第三，由于引入了MDL锁，实际上早期版本用于控制Server和引擎层表级并发的THR_LOCK 对于Innodb而言已经有些冗余了，因此Innodb表完全可以忽略这部分的开销。

不过在已有的逻辑中，Innodb依然依赖THR_LOCK来实现LOCK TABLE tbname READ，因此增加了新的MDL锁类型来代替这种实现。实际上代码的大部分修改都是为了处理新的MDL类型，Innodb的改动只有几行代码。对应WL#6671，PATCH(Rev:8232)

第四，Server层的用户锁（通过GET_LOCK函数获取）使用MDL来重新实现。

用户可以通过GET_LOCK()来同时获取多个用户锁，同时由于使用MDL来实现，可以借助MDL子系统实现死锁的检测。注意由于该变化，导致用户锁的命名必须小于64字节，这是受MDL子系统的限制导致。对应WL#1159, PATCH(Rev:8356)

MySQL·性能优化·hash_scan 算法的实现解析

问题描述

首先，我们执行下面的TestCase：

 --source include/master-slave.inc
 --source include/have_binlog_format_row.inc
 connection slave;
 set global slave_rows_search_algorithms=’TABLE_SCAN’;
 connection master;
 create table t1(id int, name varchar(20);
 insert into t1 values(1,’a’);
 insert into t2 values(2, ’b’);
 ......
 insert into t3 values(1000, ’xxx’);
 delete from t1;
 ---source include/rpl_end.inc

随着 t1 数据量的增大，rpl_hash_scan.test 的执行时间会随着 t1 数据量的增大而快速的增长，因为在执行 ‘delete from t1;’ 对于t1的每一行删除操作，备库都要扫描t1,即全表扫描，如果 select count(*) from t1 = N, 则需要扫描Ｎ次 t1 表，则读取记录数为： O(N + (N-1) + (N-2) + …. + 1) = O(N^2)，在 replication 没有引入 hash_scan，binlog_format=row时，对于无索引表，是通过 table_scan 实现的，如果一个update_rows_log_event/delete_rows_log_event 包含多行修改时，每个修改都要进行全表扫描来实现，其 stack 如下：

#0 Rows_log_event::do_table_scan_and_update
#1 0x0000000000a3d7f7 in Rows_log_event::do_apply_event 
#2 0x0000000000a28e3a in Log_event::apply_event
#3 0x0000000000a8365f in apply_event_and_update_pos
#4 0x0000000000a84764 in exec_relay_log_event 
#5 0x0000000000a89e97 in handle_slave_sql (arg=0x1b3e030) 
#6 0x0000000000e341c3 in pfs_spawn_thread (arg=0x2b7f48004b20) 
#7 0x0000003a00a07851 in start_thread () from /lib64/libpthread.so.0
#8 0x0000003a006e767d in clone () from /lib64/libc.so.6

这种情况下，往往会造成备库延迟，这也是无索引表所带来的复制延迟问题。

如何解决问题：

RDS 为了解这个问题，会在每个表创建的时候检查一下表是否包含主建或者唯一建，如果没有包含，则创建一个隐式主建，此主建对用户透明，用户无感，相应的show create, select * 等操作会屏蔽隐式主建，从而可以减少无索引表带来的影响;
官方为了解决这个问题，在5.6.6 及以后版本引入参数 slave_rows_search_algorithms ，用于指示备库在 apply_binlog_event时使用的算法，有三种算法TABLE_SCAN,INDEX_SCAN,HASH_SCAN，其中table_scan与index_scan是已经存在的，本文主要研究HASH_SCAN的实现方式，关于参数slave_rows_search_algorithms的设置。

hash_scan 的实现方法：

简单的讲，在 apply rows_log_event时，会将 log_event 中对行的更新缓存在两个结构中，分别是：m_hash, m_distinct_key_list。 m_hash：主要用来缓存更新的行记录的起始位置，是一个hash表； m_distinct_key_list：如果有索引，则将索引的值push 到m_distinct_key_list，如果表没有索引，则不使用这个List结构；其中预扫描整个调用过程如下： Log_event::apply_event

 Rows_log_event::do_apply_event
    Rows_log_event::do_hash_scan_and_update 
      Rows_log_event::do_hash_row  (add entry info of changed records)
        if (m_key_index < MAX_KEY) (index used instead of table scan)
          Rows_log_event::add_key_to_distinct_keyset ()

当一个event 中包含多个行的更改时，会首先扫描所有的更改，将结果缓存到m_hash中，如果该表有索引，则将索引的值缓存至m_distinct_key_list List 中，如果没有，则不使用这个缓存结构，而直接进行全表扫描；

执行 stack 如下：

#0 handler::ha_delete_row 
#1 0x0000000000a4192b in Delete_rows_log_event::do_exec_row 
#2 0x0000000000a3a9c8 in Rows_log_event::do_apply_row
#3 0x0000000000a3c1f4 in Rows_log_event::do_scan_and_update 
#4 0x0000000000a3c5ef in Rows_log_event::do_hash_scan_and_update 
#5 0x0000000000a3d7f7 in Rows_log_event::do_apply_event 
#6 0x0000000000a28e3a in Log_event::apply_event
#7 0x0000000000a8365f in apply_event_and_update_pos
#8 0x0000000000a84764 in exec_relay_log_event 
#9 0x0000000000a89e97 in handle_slave_sql
#10 0x0000000000e341c3 in pfs_spawn_thread
#11 0x0000003a00a07851 in start_thread () 
#12 0x0000003a006e767d in clone ()

执行过程说明：

Rows_log_event::do_scan_and_update

  open_record_scan()
    do
      next_record_scan()
        if (m_key_index > MAX_KEY)
           ha_rnd_next();
        else
           ha_index_read_map(m_key from m_distinct_key_list)       
        entry= m_hash->get()
        m_hash->del(entry);
        do_apply_row()
     while (m_hash->size > 0);

从执行过程上可以看出，当使用hash_scan时，只会全表扫描一次，虽然会多次遍历m_hash这个hash表，但是这个扫描是O(1),所以，代价很小，因此可以降低扫描次数，提高执行效率。

hash_scan 的一个 bug

bug详情：http://bugs.mysql.com/bug.php?id=72788
bug原因：m_distinct_key_list 中的index key 不是唯一的，所以存在着对已经删除了的记录重复删除的问题。
bug修复：http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/8494

问题扩展：

在没有索引的情况下，是不是把 hash_scan 打开就能提高效率，降低延迟呢？不一定，如果每次更新操作只一条记录，此时仍然需要全表扫描，并且由于entry 的开销，应该会有后退的情况；
一个event中能包含多少条记录的更新呢？这个和表结构以及记录的数据大小有关，一个event 的大小不会超过9000 bytes, 没有参数可以控制这个size；
hash_scan 有没有限制呢？hash_scan 只会对更新、删除操作有效，对于binlog_format=statement 产生的 Query_log_event 或者binlog_format=row 时产生的 Write_rows_log_event 不起作用；

TokuDB·版本优化·7.5.0

TokuDB　7.5.0大版本已发布，是一个里程碑的版本，这里谈几点优化，以飨存储引擎爱好者们。

a) shutdown加速

有用户反馈TokuDB在shutdown的时候，半个小时还没完事，非常不可接受。在shutdown的时候，TokuDB在干什么呢？在做checkpoint，把内存中的节点数据序列化并压缩到磁盘。

那为什么如此耗时呢？如果tokudb_cache_size开的比较大，内存中的节点会非常多，在shutdown的时候，大家都排队等着被压缩到磁盘（串行的）。

在7.5.0版本，TokuDB官方针对此问题进行了优化，使多个节点并行压缩来缩短时间。

BTW: TokuDB在早期设计的时候已保留并行接口，只是一直未开启。

b) 内节点读取加速

在内存中，TokuDB内节点(internal node)的每个message buffer都有２个重要数据结构：

1) FIFO结构，保存{key, value}
2) OMT结构，保存{key, FIFO-offset}

由于FIFO不具备快速查找特性，就利用OMT来做快速查找(根据key查到value)。这样，当内节点发生cache miss的时候，索引层需要做：

1) 从磁盘读取节点内容到内存
2) 构造FIFO结构
3) 根据FIFO构造OMT结构(做排序)

由于TokuDB内部有不少性能探(ji)针(shu)，他们发现步骤3)是个不小的性能消耗点，因为每次都要把message buffer做下排序构造出OMT，于是在7.5.0版本，把OMT的FIFO-offset(已排序)也持久化到磁盘，这样排序的损耗就没了。

c) 顺序写加速

当写发生的时候，会根据当前的key在pivots里查找(二分)当前写要落入哪个mesage buffer，如果写是顺序(或局部顺序，数据走向为最右边路径)的，就可以避免由＂查找＂带来的额外开销。

如何判断是顺序写呢？TokuDB使用了一种简单的启发式方法(heurstic)：seqinsert_score积分式。如果：

1) 当前写入落入最右节点，对seqinsert_score加一分(原子)
2) 当前写入落入非最右节点，对seqinsert_score清零(原子)

当seqinsert_score大于100的时候，就可以认为是顺序写，当下次写操作发生时，首先与最右的节点pivot进行对比判断，如果确实为顺序写，则会被写到该节点，省去不少compare开销。方法简单而有效。

MariaDB·　性能优化·filesort with small LIMIT optimization

从MySQL 5.6.2/MariaDB 10.0.0版本开始，MySQL/MariaDB针对”ORDER BY …LIMIT n”语句实现了一种新的优化策略。当n足够小的时候，优化器会采用一个容积为n的优先队列来进行排序，而不是排序所有数据然后取出前n条。这个新算法可以这么描述：（假设是ASC排序）

建立一个只有n个元素的优先队列（堆），根节点为堆中最大元素
根据其他条件，依次从表中取出一行数据
如果当前行的排序关键字小于堆头，则把当前元素替换堆头，重新Shift保持堆的特性
再取一条数据重复2步骤，如果没有下一条数据则执行5
依次取出堆中的元素（从大到小排序），逆序输出（从小到大排序），即可得ASC的排序结果

这样的算法，时间复杂度为m*log(n)，m为索引过滤后的行数，n为LIMIT的行数。而原始的全排序算法，时间复杂度为m*log(m)。只要n远小于m，这个算法就会很有效。

不过在MySQL 5.6中，除了optimizer_trace，没有好的方法来看到这个新的执行计划到底起了多少作用。MariaDB 10.013开始，提供一个系统状态，可以查看新执行计划调用的次数：

Sort_priority_queue_sorts
描述: 通过优先队列实现排序的次数。(总排序次数=Sort_range+Sort_scan)
范围: Global, Session
数据类型: numeric
引入版本: MariaDB 10.0.13

此外，MariaDB还将此信息打入了Slow Log中。只要指定 log_slow_verbosity=query_plan，就可以在Slow Log中看到这样的记录：

# Time: 140714 18:30:39
 # User@Host: root[root] @ localhost []
 # Thread_id: 3  Schema: test  QC_hit: No
 # Query_time: 0.053857  Lock_time: 0.000188  Rows_sent: 11  Rows_examined: 100011
 # Full_scan: Yes  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
 # Filesort: Yes  Filesort_on_disk: No  Merge_passes: 0  Priority_queue: Yes
 SET timestamp=1405348239;SET timestamp=1405348239;
 select * from t1 where col1 between 10 and 20 order by col2 limit 100;

“Priority_queue: Yes” 就表示这个Query利用了优先队列的执行计划(pt-query-digest 目前已经可以解析 Priority_queue 这个列)。更多精彩内容，敬请期待！

淘宝内部分享：怎么跳出MySQL的10个大坑

Sun, 18 Jan 2015 02:00:03 CST

编者按：淘宝自从2010开始规模使用MySQL，替换了之前商品、交易、用户等原基于IOE方案的核心数据库，目前已部署数千台规模。同时和Oracle, Percona, Mariadb等上游厂商有良好合作，共向上游提交20多个Patch。目前淘宝核心系统研发部数据库组，根据淘宝的业务需求，改进数据库和提升性能，提供高性能、可扩展的、稳定可靠的数据库(存储)解决方案。目前有以下几个方向：单机，提升单机数据库的性能，增加我们所需特性；集群，提供性能扩展，可靠性，可能涉及分布式事务处理；IO存储体系，跟踪IO设备变化潮流，研究软硬件结合，输出高性能存储解决方案。本文是来自淘宝内部数据库内容分享。

MySQL · 性能优化· Group Commit优化

背景

关于Group Commit网上的资料其实已经足够多了，我这里只简单的介绍一下。

众所周知，在MySQL5.6之前的版本，由于引入了Binlog/InnoDB的XA，Binlog的写入和InnoDB commit完全串行化执行，大概的执行序列如下：

 InnoDB prepare  （持有prepare_commit_mutex）；
 write/sync Binlog；
 InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex)。

当sync_binlog=1时，很明显上述的第二步会成为瓶颈，而且还是持有全局大锁，这也是为什么性能会急剧下降。

很快Mariadb就提出了一个Binlog Group Commit方案，即在准备写入Binlog时，维持一个队列，最早进入队列的是leader，后来的是follower，leader为搜集到的队列中的线程依次写Binlog文件, 并commit事务。Percona 的Group Commit实现也是Port自Mariadb。不过仍在使用Percona Server5.5的朋友需要注意，该Group Commit实现可能破坏掉Semisync的行为，感兴趣的点击 bug#1254571

Oracle MySQL 在5.6版本开始也支持Binlog Group Commit，使用了和Mariadb类似的思路，但将Group Commit的过程拆分成了三个阶段：flush stage 将各个线程的binlog从cache写到文件中; sync stage 对binlog做fsync操作（如果需要的话）；commit stage 为各个线程做引擎层的事务commit。每个stage同时只有一个线程在操作。

Tips：当引入Group Commit后，sync_binlog的含义就变了，假定设为1000，表示的不是1000个事务后做一次fsync，而是1000个事务组。

Oracle MySQL的实现的优势在于三个阶段可以并发执行，从而提升效率。

XA Recover

在Binlog打开的情况下，MySQL默认使用MySQL_BIN_LOG来做XA协调者，大致流程为：

1.扫描最后一个Binlog文件，提取其中的xid；
2.InnoDB维持了状态为Prepare的事务链表，将这些事务的xid和Binlog中记录的xid做比较，如果在Binlog中存在，则提交，否则回滚事务。

通过这种方式，可以让InnoDB和Binlog中的事务状态保持一致。显然只要事务在InnoDB层完成了Prepare，并且写入了Binlog，就可以从崩溃中恢复事务，这意味着我们无需在InnoDB commit时显式的write/fsync redo log。

Tips：MySQL为何只需要扫描最后一个Binlog文件呢？原因是每次在rotate到新的Binlog文件时，总是保证没有正在提交的事务，然后fsync一次InnoDB的redo log。这样就可以保证老的Binlog文件中的事务在InnoDB总是提交的。

问题

其实问题很简单：每个事务都要保证其Prepare的事务被write/fsync到redo log文件。尽管某个事务可能会帮助其他事务完成redo 写入，但这种行为是随机的，并且依然会产生明显的log_sys->mutex开销。

优化

从XA恢复的逻辑我们可以知道，只要保证InnoDB Prepare的redo日志在写Binlog前完成write/sync即可。因此我们对Group Commit的第一个stage的逻辑做了些许修改，大概描述如下：

Step1. InnoDB Prepare，记录当前的LSN到thd中；
Step2. 进入Group Commit的flush stage；Leader搜集队列，同时算出队列中最大的LSN。
Step3. 将InnoDB的redo log write/fsync到指定的LSN
Step4. 写Binlog并进行随后的工作(sync Binlog, InnoDB commit , etc)

通过延迟写redo log的方式，显式的为redo log做了一次组写入，并减少了log_sys->mutex的竞争。

目前官方MySQL已经根据我们report的bug#73202锁提供的思路，对5.7.6的代码进行了优化，对应的Release Note如下：

When using InnoDB with binary logging enabled, concurrent transactions written in the InnoDB redo log are now grouped together before synchronizing to disk when innodb_flush_log_at_trx_commit is set to 1, which reduces the amount of synchronization operations. This can lead to improved performance.

性能数据

简单测试了下，使用sysbench, update_non_index.lua, 100张表，每张10w行记录，innodb_flush_log_at_trx_commit=2, sync_binlog=1000，关闭Gtid

 并发线程        原生                  修改后
 32             25600                27000
 64             30000                35000
 128            33000                39000
 256            29800                38000

MySQL · 新增特性· DDL fast fail

背景

项目的快速迭代开发和在线业务需要保持持续可用的要求，导致MySQL的ddl变成了DBA很头疼的事情，而且经常导致故障发生。本篇介绍RDS分支上做的一个功能改进，DDL fast fail。主要解决：DDL操作因为无法获取MDL排它锁，进入等待队列的时候，阻塞了应用所有的读写请求问题。

MDL锁机制介绍

首先介绍一下MDL(METADATA LOCK)锁机制，MySQL为了保证表结构的完整性和一致性，对表的所有访问都需要获得相应级别的MDL锁，比如以下场景：

session 1: start transaction; select * from test.t1;
session 2: alter table test.t1 add extra int;
session 3: select * from test.t1;

session 1对t1表做查询，首先需要获取t1表的MDL_SHARED_READ级别MDL锁。锁一直持续到commit结束，然后释放。
session 2对t1表做DDL，需要获取t1表的MDL_EXCLUSIVE级别MDL锁，因为MDL_SHARED_READ与MDL_EXCLUSIVE不相容，所以session 2被session 1阻塞，然后进入等待队列。
session 3对t1表做查询，因为等待队列中有MDL_EXCLUSIVE级别MDL锁请求，所以session3也被阻塞，进入等待队列。

这种场景就是目前因为MDL锁导致的很经典的阻塞问题，如果session1长时间未提交，或者查询持续过长时间，那么后续对t1表的所有读写操作，都被阻塞。对于在线的业务来说，很容易导致业务中断。

aliyun RDS分支改进

DDL fast fail并没有解决真正DDL过程中的阻塞问题，但避免了因为DDL操作没有获取锁，进而导致业务其他查询/更新语句阻塞的问题。

其实现方式如下：

alter table test.t1 no_wait/wait 1 add extra int;
在ddl语句中，增加了no_wait/wait 1语法支持。

其处理逻辑如下：

首先尝试获取t1表的MDL_EXCLUSIVE级别的MDL锁：

当语句指定的是no_wait，如果获取失败，客户端将得到报错信息：ERROR : Lock wait timeout exceeded; try restarting transaction。
当语句指定的是wait 1，如果获取失败，最多等待1s，然后得到报错信息：ERROR : Lock wait timeout exceeded; try restarting transaction。

另外，除了alter语句以外，还支持rename，truncate，drop，optimize，create index等ddl操作。

与Oracle的比较

在Oracle 10g的时候，DDL操作经常会遇到这样的错误信息：

ora-00054:resource busy and acquire with nowait specified 即DDL操作无法获取表上面的排它锁，而fast fail。

其实DDL获取排他锁的设计，需要考虑的就是两个问题：

雪崩，如果你采用排队阻塞的机制，那么DDL如果长时间无法获取锁，就会导致应用的雪崩效应，对于高并发的业务，也是灾难。
饿死，如果你采用强制式的机制，那么要防止DDL一直无法获取锁的情况，在业务高峰期，可能DDL永远无法成功。

在Oracle 11g的时候，引入了DDL_LOCK_TIMEOUT参数，如果你设置了这个参数，那么DDL操作将使用排队阻塞模式，可以在session和global级别设置，给了用户更多选择。

MySQL · 性能优化· 启用GTID场景的性能问题及优化

背景

MySQL从5.6版本开始支持GTID特性，也就是所谓全局事务ID，在整个复制拓扑结构内，每个事务拥有自己全局唯一标识。GTID包含两个部分，一部分是实例的UUID，另一部分是实例内递增的整数。

GTID的分配包含两种方式，一种是自动分配，另外一种是显式设置session.gtid_next，下面简单介绍下这两种方式：

自动分配

如果没有设置session级别的变量gtid_next，所有事务都走自动分配逻辑。分配GTID发生在GROUP COMMIT的第一个阶段，也就是flush stage，大概可以描述为：

Step 1：事务过程中，碰到第一条DML语句需要记录Binlog时，分配一段Gtid事件的cache，但不分配实际的GTID
Step 2：事务完成后，进入commit阶段，分配一个GTID并写入Step1预留的Gtid事件中，该GTID必须保证不在gtid_owned集合和gtid_executed集合中。分配的GTID随后被加入到gtid_owned集合中。
Step 3：将Binlog 从线程cache中刷到Binlog文件中。
Step 4：将GTID加入到gtid_executed集合中。
Step 5：在完成sync stage 和commit stage后，各个会话将其使用的GTID从gtid_owned中移除。

显式设置

用户通过设置session级别变量gtid_next可以显式指定一个GTID，流程如下：

Step 1：设置变量gtid_next，指定的GTID被加入到gtid_owned集合中。
Step 2：执行任意事务SQL，在将binlog从线程cache刷到binlog文件后，将GTID加入到gtid_executed集合中。
Step 3：在完成事务COMMIT后，从gtid_owned中移除。

备库SQL线程使用的就是第二种方式，因为备库在apply主库的日志时，要保证GTID是一致的，SQL线程读取到GTID事件后，就根据其中记录的GTID来设置其gtid_next变量。

问题

由于在实例内，GTID需要保证唯一性，因此不管是操作gtid_executed集合和gtid_owned集合，还是分配GTID，都需要加上一个大锁。我们的优化主要集中在第一种GTID分配方式。

对于GTID的分配，由于处于Group Commit的第一个阶段，由该阶段的leader线程为其follower线程分配GTID及刷Binlog，因此不会产生竞争。

而在Step 5，各个线程在完成事务提交后，各自去从gtid_owned集合中删除其使用的gtid。这时候每个线程都需要获取互斥锁，很显然，并发越高，这种竞争就越明显，我们很容易从pt-pmp输出中看到如下类似的trace：

 ha_commit_trans—>MySQL_BIN_LOG::commit—>MySQL_BIN_LOG::ordered_commit—>MySQL_BIN_LOG::finish_commit—>Gtid_state::update_owned_gtids_impl—>lock_sidno

这同时也会影响到GTID的分配阶段，导致TPS在高并发场景下的急剧下降。

解决

实际上对于自动分配GTID的场景，并没有必要维护gtid_owned集合。我们的修改也非常简单，在自动分配一个GTID后，直接加入到gtid_executed集合中，避免维护gtid_owned，这样事务提交时就无需去清理gtid_owned集合了，从而可以完全避免锁竞争。

当然为了保证一致性，如果分配GTID后，写入Binlog文件失败，也需要从gtid_executed集合中删除。不过这种场景非常罕见。

性能数据

使用sysbench，100张表，每张10w行记录，update_non_index.lua，纯内存操作，innodb_flush_log_at_trx_commit = 2，sync_binlog = 1000

 并发线程       原生               修改后
 32           24500              25000
 64           27900              29000
 128          30800              31500
 256          29700              32000
 512          29300              31700
 1024         27000              31000

从测试结果可以看到，优化前随着并发上升，性能出现下降，而优化后则能保持TPS稳定。

MySQL · 捉虫动态· InnoDB自增列重复值问题

问题重现

先从问题入手，重现下这个 bug

use test;
drop table if exists t1;
create table t1(id int auto_increment, a int, primary key (id)) engine=innodb;
insert into t1 values (1,2);
insert into t1 values (null,2);
insert into t1 values (null,2);
select * from t1;
+----+------+
| id | a |
+----+------+
| 1 | 2 |
| 2 | 2 |
| 3 | 2 |
+----+------+
delete from t1 where id=2;
delete from t1 where id=3;
select * from t1;
+----+------+
| id | a |
+----+------+
| 1 | 2 |
+----+------+

这里我们关闭MySQL，再启动MySQL,然后再插入一条数据

insert into t1 values (null,2);
select * FROM T1;
+----+------+
| id | a |
+----+------+
| 1 | 2 |
+----+------+
| 2 | 2 |
+----+------+

我们看到插入了（2,2），而如果我没有重启，插入同样数据我们得到的应该是（4,2)。上面的测试反映了MySQLd重启后，InnoDB存储引擎的表自增id可能出现重复利用的情况。

自增id重复利用在某些场景下会出现问题。依然用上面的例子，假设t1有个历史表t1_history用来存t1表的历史数据，那么MySQLd重启前,ti_history中可能已经有了（2,2）这条数据，而重启后我们又插入了（2，2），当新插入的(2,2)迁移到历史表时，会违反主键约束。

原因分析

InnoDB 自增列出现重复值的原因：

MySQL> show create table t1G;
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`a` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=innodb AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

建表时可以指定 AUTO_INCREMENT值，不指定时默认为1，这个值表示当前自增列的起始值大小，如果新插入的数据没有指定自增列的值，那么自增列的值即为这个起始值。对于InnoDB表，这个值没有持久到文件中。而是存在内存中（dict_table_struct.autoinc）。那么又问，既然这个值没有持久下来，为什么我们每次插入新的值后， show create table t1看到AUTO_INCREMENT值是跟随变化的。其实show create table t1是直接从dict_table_struct.autoinc取得的（ha_innobase::update_create_info）。

知道了AUTO_INCREMENT是实时存储内存中的。那么，MySQLd 重启后，从哪里得到AUTO_INCREMENT呢? 内存值肯定是丢失了。实际上MySQL采用执行类似select max(id)+1 from t1;方法来得到AUTO_INCREMENT。而这种方法就是造成自增id重复的原因。

MyISAM自增值

MyISAM也有这个问题吗？MyISAM是没有这个问题的。myisam会将这个值实时存储在.MYI文件中（mi_state_info_write）。MySQLd重起后会从.MYI中读取AUTO_INCREMENT值（mi_state_info_read)。因此，MyISAM表重启是不会出现自增id重复的问题。

问题修复

MyISAM选择将AUTO_INCREMENT实时存储在.MYI文件头部中。实际上.MYI头部还会实时存其他信息，也就是说写AUTO_INCREMENT只是个顺带的操作，其性能损耗可以忽略。InnoDB 表如果要解决这个问题，有两种方法。

1）将AUTO_INCREMENT最大值持久到frm文件中。
2）将 AUTO_INCREMENT最大值持久到聚集索引根页trx_id所在的位置。

第一种方法直接写文件性能消耗较大，这是一额外的操作，而不是一个顺带的操作。我们采用第二种方案。为什么选择存储在聚集索引根页页头trx_id，页头中存储trx_id,只对二级索引页和insert buf 页头有效（MVCC)。而聚集索引根页页头trx_id这个值是没有使用的，始终保持初始值0。正好这个位置8个字节可存放自增值的值。我们每次更新AUTO_INCREMENT值时，同时将这个值修改到聚集索引根页页头trx_id的位置。这个写操作跟真正的数据写操作一样，遵守write-ahead log原则，只不过这里只需要redo log ,而不需要undo log。因为我们不需要回滚AUTO_INCREMENT的变化（即回滚后自增列值会保留，即使insert 回滚了，AUTO_INCREMENT值不会回滚）。

因此，AUTO_INCREMENT值存储在聚集索引根页trx_id所在的位置，实际上是对内存根页的修改和多了一条redo log（量很小）,而这个redo log 的写入也是异步的，可以说是原有事务log的一个顺带操作。因此AUTO_INCREMENT值存储在聚集索引根页这个性能损耗是极小的。

修复后的性能对比，我们新增了全局参数innodb_autoinc_persistent 取值on/off； on 表示将AUTO_INCREMENT值实时存储在聚集索引根页。off则采用原有方式只存储在内存。

./bin/sysbench --test=sysbench/tests/db/insert.lua --MySQL-port=4001 --MySQL-user=root --MySQL-table-engine=innodb --MySQL-db=sbtest --oltp-table-size=0 --oltp-tables-count=1 --num-threads=100 --MySQL-socket=/u01/zy/sysbench/build5/run/MySQL.sock  --max-time=7200 --max-requests run
set global innodb_autoinc_persistent=off;
tps: 22199 rt:2.25ms
set global innodb_autoinc_persistent=on;
tps: 22003 rt:2.27ms

可以看出性能损耗在%1以下。

改进

新增参数innodb_autoinc_persistent_interval 用于控制持久化AUTO_INCREMENT值的频率。例如：innodb_autoinc_persistent_interval=100，auto_incrememt_increment=1时，即每100次insert会控制持久化一次AUTO_INCREMENT值。每次持久的值为：当前值+innodb_autoinc_persistent_interval。

测试结论

innodb_autoinc_persistent=ON, innodb_autoinc_persistent_interval=1时性能损耗在%1以下。
innodb_autoinc_persistent=ON, innodb_autoinc_persistent_interval=100时性能损耗可以忽略。

限制

innodb_autoinc_persistent=on， innodb_autoinc_persistent_interval=N>1时，自增N次后持久化到聚集索引根页,每次持久的值为当前AUTO_INCREMENT+(N-1)*innodb_autoextend_increment。重启后读取持久化的AUTO_INCREMENT值会偏大，造成一些浪费但不会重复。innodb_autoinc_persistent_interval=1 每次都持久化没有这个问题。
如果innodb_autoinc_persistent=on，频繁设置auto_increment_increment的可能会导致持久化到聚集索引根页的值不准确。因为innodb_autoinc_persistent_interval计算没有考虑auto_increment_increment变化的情况，参看dict_table_autoinc_update_if_greater。而设置auto_increment_increment的情况极少，可以忽略。

注意：如果我们使用需要开启innodb_autoinc_persistent，应该在参数文件中指定

innodb_autoinc_persistent= on

如果这样指定set global innodb_autoinc_persistent=on;重启后将不会从聚集索引根页读取AUTO_INCREMENT最大值。

疑问：对于InnoDB表，重启通过select max(id)+1 from t1得到AUTO_INCREMENT值，如果id上有索引那么这个语句使用索引查找就很快。那么，这个可以解释MySQL 为什么要求自增列必须包含在索引中的原因。如果没有指定索引，则报如下错误，

ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key 而myisam表竟然也有这个要求，感觉是多余的。

MySQL · 优化改进· 复制性能改进过程

前言

与oracle 不同，MySQL 的主库与备库的同步是通过 binlog 实现的，而redo日志只做为MySQL 实例的crash recovery使用。MySQL在4.x 的时候放弃redo 的同步策略而引入 binlog的同步，一个重要原因是为了兼容其它非事务存储引擎，否则主备同步是没有办法进行的。

redo 日志同步属于物理同步方法，简单直接，将修改的物理部分传送到备库执行，主备共用一致的 LSN，只要保证 LSN 相同即可，同一时刻，只能主库或备库一方接受写请求； binlog的同步方法属于逻辑复制，分为statement 或 row 模式，其中statement记录的是SQL语句，Row 模式记录的是修改之前的记录与修改之后的记录，即前镜像与后镜像；备库通过binlog dump 协议拉取binlog,然后在备库执行。如果拉取的binlog是SQL语句，备库会走和主库相同的逻辑，如果是row 格式，则会调用存储引擎来执行相应的修改。

本文简单说明5.5到5.7的主备复制性能改进过程。

replication improvement (from 5.5 to 5.7)

(1) 5.5 中，binlog的同步是由两个线程执行的

io_thread: 根据binlog dump协议从主库拉取binlog, 并将binlog转存到本地的relaylog；

sql_thread: 读取relaylog，根据位点的先后顺序执行binlog event，进而将主库的修改同步到备库，达到主备一致的效果；由于在主库的更新是由多个客户端执行的，所以当压力达到一定的程度时，备库单线程执行主库的binlog跟不上主库执行的速度，进而会产生延迟造成备库不可用，这也是分库的原因之一，其SQL线程的执行堆栈如下：

sql_thread:
exec_relay_log_event
    apply_event_and_update_pos
         apply_event
             rows_log_event::apply_event
                 storage_engine operation
         update_pos

(2) 5.6 中，引入了多线程模式，在多线程模式下，其线程结构如下

io_thread: 同5.5

Coordinator_thread: 负责读取 relay log，将读取的binlog event以事务为单位分发到各个 worker thread 进行执行，并在必要时执行binlog event（Description_format_log_event， Rotate_log_event 等）。

worker_thread: 执行分配到的binlog event，各个线程之间互不影响；

多线程原理

sql_thread 的分发原理是依据当前事务所操作的数据库名称来进行分发，如果事务是跨数据库行为的，则需要等待已分配的该数据库的事务全部执行完毕，才会继续分发，其分配行为的伪码可以简单的描述如下：

get_slave_worker
  if (contains_partition_info(log_event))
     db_name= get_db_name(log_event);
     entry {db_name, worker_thread, usage} = map_db_to_worker(db_name);
     while (entry->usage > 0)
        wait();
    return worker;
  else if (last_assigned_worker)
    return last_assigned_worker;
  else
    push into buffer_array and deliver them until come across a event that have partition info

需要注意的细节

内存的分配与释放。relay thread 每读取一个log_event, 则需要 malloc 一定的内存，在work线程执行完后，则需要free掉；
数据库名与 worker 线程的绑定信息在一个hash表中进行维护，hash表以entry为单位，entry中记录当前entry所代表的数据库名，有多少个事务相关的已被分发，执行这些事务的worker thread等信息；
维护一个绑定信息的array , 在分发事务的时候，更新绑定信息，增加相应 entry->usage, 在执行完一个事务的时候，则需要减少相应的entry->usage；
slave worker 信息的维护，即每个 worker thread执行了哪些事务，执行到的位点是在哪，延迟是如何计算的，如果执行出错，mts_recovery_group 又是如何恢复的；
分配线程是以数据库名进行分发的，当一个实例中只有一个数据库的时候，不会对性能有提高，相反，由于增加额外的操作，性能还会有一点回退；
临时表的处理，临时表是和entry绑定在一起的，在执行的时候将entry的临时表挂在执行线程thd下面，但没有固化，如果在临时表操作期间，备库crash，则重启后备库会有错误；

总体上说，5.6 的并行复制打破了5.5 单线程的复制的行为，只是在单库下用处不大，并且5.6的并行复制的改动引入了一些重量级的bug

MySQL slave sql thread memory leak (http://bugs.MySQL.com/bug.php?id=71197)
Relay log without xid_log_event may case parallel replication hang (http://bugs.MySQL.com/bug.php?id=72794)
Transaction lost when relay_log_info_repository=FILE and crashed (http://bugs.MySQL.com/bug.php?id=73482)

(3) 5.7中，并行复制的实现添加了另外一种并行的方式，即主库在 ordered_commit中的第二阶段的时候，将同一批commit的 binlog 打上一个相同的seqno标签，同一时间戳的事务在备库是可以同时执行的，因此大大简化了并行复制的逻辑，并打破了相同 DB 不能并行执行的限制。备库在执行时，具有同一seqno的事务在备库可以并行的执行，互不干扰，也不需要绑定信息，后一批seqno的事务需要等待前一批相同seqno的事务执行完后才可以执行。

详细实现可参考： http://bazaar.launchpad.net/~MySQL/MySQL-server/5.7/revision/6256 。

reference： http://geek.rohitkalhans.com/2013/09/enhancedMTS-deepdive.html

MySQL · 谈古论今· key分区算法演变分析

本文说明一个物理升级导致的 “数据丢失”。

现象

在MySQL 5.1下新建key分表，可以正确查询数据。

drop table t1;

create table t1 (c1 int , c2 int) 
PARTITION BY KEY (c2) partitions 5; 
insert into t1  values(1,1785089517),(2,null); 
MySQL> select * from t1 where c2=1785089517;
+------+------------+
| c1   | c2         |
+------+------------+
|    1 | 1785089517 |
+------+------------+
1 row in set (0.00 sec)
MySQL> select * from t1 where c2 is null;
+------+------+
| c1   | c2   |
+------+------+
|    2 | NULL |
+------+------+
1 row in set (0.00 sec)

而直接用MySQL5.5或MySQL5.6启动上面的5.1实例，发现(1,1785089517)这行数据不能正确查询出来。

alter table t1 PARTITION BY KEY ALGORITHM = 1 (c2)  partitions 5;
MySQL> select * from t1 where c2 is null;
+------+------+
| c1   | c2   |
+------+------+
|    2 | NULL |
+------+------+
1 row in set (0.00 sec)
MySQL> select * from t1 where c2=1785089517;
Empty set (0.00 sec)

原因分析

跟踪代码发现，5.1 与5.5,5.6 key hash算法是有区别的。

5.1 对于非空值的处理算法如下

void my_hash_sort_bin(const CHARSET_INFO *cs __attribute__((unused)),
                     const uchar *key, size_t len,ulong *nr1, ulong *nr2)
{
  const uchar *pos = key; 

  key+= len;

  for (; pos < (uchar*) key&nbsp;; pos++)
  {
    nr1[0]^=(ulong) ((((uint) nr1[0] & 63)+nr2[0]) * 
             ((uint)*pos)) + (nr1[0] << 8);
    nr2[0]+=3;
  }
}

通过此算法算出数据(1,1785089517)在第3个分区

5.5和5.6非空值的处理算法如下

void my_hash_sort_simple(const CHARSET_INFO *cs,
                         const uchar *key, size_t len,
                         ulong *nr1, ulong *nr2)
{
  register uchar *sort_order=cs->sort_order;
  const uchar *end;

  /* 
    Remove end space. We have to do this to be able to compare
    ’A ’ and ’A’ as identical
  */        
  end= skip_trailing_space(key, len);

  for (; key < (uchar*) end&nbsp;; key++)
  {
    nr1[0]^=(ulong) ((((uint) nr1[0] & 63)+nr2[0]) * 
            ((uint) sort_order[(uint) *key])) + (nr1[0] << 8);
    nr2[0]+=3;
  }
}

通过此算法算出数据(1,1785089517)在第5个分区，因此，5.5,5.6查询不能查询出此行数据。

5.1,5.5,5.6对于空值的算法还是一致的,如下

if (field->is_null())
{
  nr1^= (nr1 << 1) | 1;
  continue;
}

都能正确算出数据(2, null)在第3个分区。因此，空值可以正确查询出来。

那么是什么导致非空值的hash算法走了不同路径呢？在5.1下，计算字段key hash固定字符集就是my_charset_bin，对应的hash 函数就是前面的my_hash_sort_simple。而在5.5，5.6下，计算字段key hash的字符集是随字段变化的，字段c2类型为int对应my_charset_numeric，与之对应的hash函数为my_hash_sort_simple。具体可以参考函数Field::hash

那么问题又来了，5.5后为什么算法会变化呢？原因在于官方关于字符集策略的调整，详见 WL#2649 。

兼容处理

前面讲到，由于hash 算法变化，用5.5，5.6启动5.1的实例，导致不能正确查询数据。那么5.1升级5.5,5.6就必须兼容这个问题.MySQL 5.5.31以后，提供了专门的语法 ALTER TABLE … PARTITION BY ALGORITHM=1 [LINEAR] KEY … 用于兼容此问题。对于上面的例子，用5.5或5.6启动5.1的实例后执行

MySQL> alter table t1 PARTITION BY KEY ALGORITHM = 1 (c2) partitions 5;
Query OK, 2 rows affected (0.02 sec)
Records: 2  Duplicates: 0  Warnings: 0

MySQL> select * from t1 where c2=1785089517;
+------+------------+
| c1   | c2         |
+------+------------+
|    1 | 1785089517 |
+------+------------+
1 row in set (0.00 sec)

数据可以正确查询出来了。

而实际上5.5,5.6的MySQL_upgrade升级程序已经提供了兼容方法。MySQL_upgrade 执行check table xxx for upgrade 会检查key分区表是否用了老的算法。如果使用了老的算法，会返回

MySQL> CHECK TABLE t1  FOR UPGRADEG
*************************** 1. row ***************************
   Table: test.t1
      Op: check
Msg_type: error
Msg_text: KEY () partitioning changed, please run:
ALTER TABLE `test`.`t1` PARTITION BY KEY /*!50611 ALGORITHM = 1 */ (c2)
PARTITIONS 5
*************************** 2. row ***************************
   Table: test.t1
      Op: check
Msg_type: status
Msg_text: Operation failed
2 rows in set (0.00 sec)

检查到错误信息后会自动执行以下语句进行兼容。

ALTER TABLE `test`.`t1` PARTITION BY KEY /*!50611 ALGORITHM = 1 */ (c2) PARTITIONS 5。

MySQL · 捉虫动态· MySQL client crash一例

背景

客户使用MySQLdump导出一张表，然后使用MySQL -e ‘source test.dmp’的过程中client进程crash，爆出内存的segment fault错误，导致无法导入数据。

问题定位

test.dmp文件大概50G左右，查看了一下文件的前几行内容，发现：

 A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database If you don’t want to restore GTIDs pass set-gtid-purged=OFF. To make a complete dump, pass...
 -- MySQL dump 10.13  Distrib 5.6.16, for Linux (x86_64)
 --
 -- Host: 127.0.0.1    Database: carpath
 -- ------------------------------------------------------
 -- Server version       5.6.16-log
 /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
 /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;

问题定位到第一行出现了不正常warning的信息，是由于客户使用MySQLdump命令的时候，重定向了stderr。即:

MySQLdump …>/test.dmp 2>&1

导致error或者warning信息都重定向到了test.dmp, 最终导致失败。

问题引申

问题虽然定位到了，但却有几个问题没有弄清楚：

问题1. 不正常的sql，执行失败，报错出来就可以了，为什么会导致crash？

MySQL.cc::add_line函数中，在读第一行的时候，读取到了don’t,发现有一个单引号，所以程序死命的去找匹配的另外一个单引号，导致不断的读取文件，分配内存，直到crash。
假设没有这个单引号，MySQL读到第六行，发现;号，就会执行sql，并正常的报错退出。

问题2. 那代码中对于大小的边界到底是多少？比如insert语句支持batch insert时，语句的长度多少，又比如遇到clob字段呢？

首先clob字段的长度限制。clob家族类型的column长度受限于max_allowed_packet的大小，MySQL 5.5中，对于max_allowd_packet的大小限制在(1024, 1024*1024*1024)之间。
MySQLdump导出insert语句的时候，如何分割insert语句？MySQLdump时候支持insert t1 value(),(),();这样的batch insert语句。 MySQLdump其实是根据opt_net_buffer_length来进行分割，当一个insert语句超过这个大小，就强制分割到下一个insert语句中，这样更多的是在做网络层的优化。又如果遇到大的clob字段怎么办？如果一行就超过了opt_net_buffer_length，那就强制每一行都分割。
MySQL client端读取dump文件的时候, 到底能分配多大的内存？MySQL.cc中定义了:#define MAX_BATCH_BUFFER_SIZE (1024L * 1024L * 1024L)。也就是MySQL在执行语句的时候，最多只能分配1G大小的缓存。

所以，正常情况下，max_allowed_packet现在的最大字段长度和MAX_BATCH_BUFFER_SIZE限制的最大insert语句，是匹配的。

RDS问题修复原则

从问题的定位上来看，这一例crash属于客户错误使用MySQLdump导致的问题，Aliyun RDS分支对内存导致的crash问题，都会定位并反馈给用户。但此例不做修复，而是引导用户正确的使用MySQLdump工具。

MySQL · 捉虫动态· 设置 gtid_purged 破坏AUTO_POSITION复制协议

bug描述

Oracle 最新发布的版本 5.6.22 中有这样一个关于GTID的bugfix，在主备场景下，如果我们在主库上 SET GLOBAL GTID_PURGED = “some_gtid_set”，并且 some_gtid_set 中包含了备库还没复制的事务，这个时候如果备库接上主库的话，预期结果是主库返回错误，IO线程挂掉的，但是实际上，在这种场景下主库并不报错，只是默默的把自己 binlog 中包含的gtid事务发给备库。这个bug的造成的结果是看起来复制正常，没有错误，但实际上备库已经丢事务了，主备很可能就不一致了。

背景知识

binlog GTID事件

binlog 中记录的和GTID相关的事件主要有2种，Previous_gtids_log_event 和 Gtid_log_event，前者表示之前的binlog中包含的gtid的集合，后者就是一个gtid，对应一个事务。一个 binlog 文件中只有一个 Previous_gtids_log_event，放在开头，有多个 Gtid_log_event，如下面所示

Previous_gtids_log_event   // 此 binlog 之前的所有binlog文件包含的gtid集合

Gtid_log_event // 单个gtid event
Transaction
Gtid_log_event
Transaction
.
.
.
Gtid_log_event
Transaction

备库发送GTID集合给主库

我们知道备库的复制线程是分IO线程和SQL线程2种的，IO线程通过GTID协议或者文件位置协议拉取主库的binlog，然后记录在自己的relay log中；SQL线程通过执行realy log中的事件，把其中的操作都自己做一遍，记入本地binlog。在GTID协议下，备库向主库发送拉取请求的时候，会告知主库自己已经有的所有的GTID的集合，Retrieved_Gtid_Set + Executed_Gtid_Set，前者对应 realy log 中所有的gtid集合，表示已经拉取过的，后者对应binlog中记录有的，表示已经执行过的；主库在收到这2个总集合后，会扫描自己的binlog，找到合适的binlog然后开始发送。

主库如何找到要发送给备库的第一个binlog

主库将备库发送过来的总合集记为 slave_gtid_executed，然后调用 find_first_log_not_in_gtid_set(slave_gtid_executed)，这个函数的目的是从最新到最老扫描binlog文件，找到第一个含有不存在 slave_gtid_executed 这个集合的gtid的binlog。在这个扫描过程中并不需要从头到尾读binlog中所有的gtid，只需要读出 Previous_gtids_log_event ，如果Previous_gtids_log_event 不是 slave_gtid_executed的子集，就继续向前找binlog，直到找到为止。

这个查找过程总会停止的，停止条件如下：

找到了这样的binlog，其Previous_gtids_log_event 是slave_gtid_executed子集

在往前读binlog的时候，发现没有binlog文件了（如被purge了），但是还没找到满足条件的Previous_gtids_log_event，这个时候主库报错

一直往前找，发现Previous_gtids_log_event 是空集

在条件2下，报错信息是这样的

Got fatal error 1236 from master when reading data from binary log: ‘The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

其实上面的条件3是条件1的特殊情况，这个bugfix针对的场景就是条件3这种，但并不是所有的符合条件3的场景都会触发这个bug，下面就分析下什么情况下才会触发bug。

bug 分析

假设有这样的场景，我们要用已经有MySQL实例的备份重新做一对主备实例，不管是用 xtrabackup 这种物理备份工具或者MySQLdump这种逻辑备份工具，都会有2步操作，

导入数据

SET GLOBAL GTID_PURGED =”xxxx”

步骤2是为了保证GTID的完备性，因为新实例已经导入了数据，就需要把生成这些数据的事务对应的GTID集合也设置进来。

正常的操作是主备都要做这2步的，如果我们只在主库上做了这2步，备库什么也不做，然后就直接用 GTID 协议把备库连上来，按照我们的预期这个时候是应该出错的，主备不一致，并且主库的binlog中没东西，应该报之前停止条件2报的错。但是令人大跌眼镜的是主库不报错，复制看起来是完全正常的。

为啥会这样呢，SET GLOBAL GTID_PURGED 操作会调用 MySQL_bin_log.rotate_and_purge切换到一个新的binlog，并把这个GTID_PURGED 集合记入新生成的binlog的Previous_gtids_log_event，假设原有的binlog为A，新生成的为B，主库刚启动，所以A就是主库的第一个binlog，它之前啥也没有，A的Previous_gtids_log_event就是空集，并且A中也不包含任何GTID事件，否则SET GLOBAL GTID_PURGED是做不了的。按照之前的扫描逻辑，扫到A是肯定会停下来的，并且不报错。

bug 修复

官方的修复就是在主库扫描查找binlog之前，判断一下 gtid_purged 集合不是不比slave_gtid_executed大，如果是就报错，错误信息和条件2一样 Got fatal error 1236 from master when reading data from binary log: ‘The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires。

MySQL · 捉虫动态· replicate filter 和 GTID 一起使用的问题

问题描述

当单个 MySQL 实例的数据增长到很多的时候，就会考虑通过库或者表级别的拆分，把当前实例的数据分散到多个实例上去，假设原实例为A，想把其中的5个库（db1/db2/db3/db4/db5）拆分到5个实例（B1/B2/B3/B4/B5）上去。

拆分过程一般会这样做，先把A的相应库的数据导出，然后导入到对应的B实例上，但是在这个导出导入过程中，A库的数据还是在持续更新的，所以还需在导入完后，在所有的B实例和A实例间建立复制关系，拉取缺失的数据，在业务不繁忙的时候将业务切换到各个B实例。

在复制搭建时，每个B实例只需要复制A实例上的一个库，所以只需要重放对应库的binlog即可，这个通过 replicate-do-db 来设置过滤条件。如果我们用备库上执行 show slave statusG 会看到Executed_Gtid_Set是断断续续的，间断非常多，导致这一列很长很长，看到的直接效果就是被刷屏了。

为啥会这样呢，因为设了replicate-do-db，就只会执行对应db对应的event，其它db的都不执行。主库的执行是不分db的，对各个db的操作互相间隔，记录在binlog中，所以备库做了过滤后，就出现这种断断的现象。

除了这个看着不舒服外，还会导致其它问题么？

假设我们拿B1实例的备份做了一个新实例，然后接到A上，如果主库A又定期purge了老的binlog，那么新实例的IO线程就会出错，因为需要的binlog在主库上找不到了；即使主库没有purge 老的binlog，新实例还要把主库的binlog都从头重新拉过来，然后执行的时候又都过滤掉，不如不拉取。

有没有好的办法解决这个问题呢？SQL线程在执行的时候，发现是该被过滤掉的event，在不执行的同时，记一个空事务就好了，把原事务对应的GTID位置占住，记入binlog，这样备库的Executed_Gtid_Set就是连续的了。

bug 修复

对这个问题，官方有一个相应的bugfix，参见 revno: 5860 ，有了这个patch后，备库B1的 SQL 线程在遇到和 db2-db5 相关的SQL语句时，在binlog中把对应的GTID记下，同时对应记一个空事务。

这个 patch 只是针对Query_log_event，即 statement 格式的 binlog event，那么row格式的呢？ row格式原来就已经是这种行为，通过check_table_map 函数来过滤库或者表，然后生成一个空事务。

另外这个patch还专门处理了下 CREATE/DROP TEMPORARY TABLE 这2种语句，我们知道row格式下，对临时表的操作是不会记入binlog的。如果主库的binlog格式是 statement，备库用的是 row，CREATE/DROP TEMPORARY TABLE 对应的事务传到备库后，就会消失掉，Executed_Gtid_Set集合看起来是不连续的，但是主库的binlog记的gtid是连续的，这个 patch 让这种情况下的CREATE/DROP TEMPORARY TABLE在备库同样记为一个空事务。

TokuDB·特性分析· Optimize Table

来自一个TokuDB用户的“投诉”:

https://mariadb.atlassian.net/browse/MDEV-6207

现象大概是:

用户有一个MyISAM的表test_table:

 CREATE TABLE IF NOT EXISTS `test_table` (
   `id` int(10) unsigned NOT NULL,
   `pub_key` varchar(80) NOT NULL,
   PRIMARY KEY (`id`),
   KEY `pub_key` (`pub_key`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

转成TokuDB引擎后表大小为92M左右:

 47M     _tester_testdb_sql_61e7_1812_main_ad88a6b_1_19_B_0.tokudb
 45M     _tester_testdb_sql_61e7_1812_key_pub_key_ad88a6b_1_19_B_1.tokudb

执行”OPTIMIZE TABLE test_table”:

 63M     _tester_testdb_sql_61e7_1812_main_ad88a6b_1_19_B_0.tokudb
 61M     _tester_testdb_sql_61e7_1812_key_pub_key_ad88a6b_1_19_B_1.tokudb

再次执行”OPTIMIZE TABLE test_table”:

 79M     _tester_testdb_sql_61e7_1812_main_ad88a6b_1_19_B_0.tokudb
 61M     _tester_testdb_sql_61e7_1812_key_pub_key_ad88a6b_1_19_B_1.tokudb

继续执行:

 79M     _tester_testdb_sql_61e7_1812_main_ad88a6b_1_19_B_0.tokudb
 61M     _tester_testdb_sql_61e7_1812_key_pub_key_ad88a6b_1_19_B_1.tokudb

基本稳定在这个大小。

主索引从47M–>63M–>79M，执行”OPTIMIZE TABLE”后为什么会越来越大？

这得从TokuDB的索引文件分配方式说起，当内存中的脏页需要写到磁盘时，TokuDB优先在文件末尾分配空间并写入，而不是“覆写”原块，原来的块暂时成了“碎片”。

这样问题就来了，索引文件岂不是越来越大？No, TokuDB会把这些“碎片”在checkpoint时加入到回收列表，以供后面的写操作使用，看似79M的文件其实还可以装不少数据呢！

嗯，这个现象解释通了，但还有2个问题:

在执行这个语句的时候，TokuDB到底在做什么呢？在做toku_ft_flush_some_child，把内节点的缓冲区(message buffer)数据刷到最底层的叶节点。

在TokuDB里，OPTIMIZE TABLE有用吗？作用非常小，不建议使用，TokuDB是一个”No Fragmentation”的引擎。

淘宝搜索算法现状

Tue, 21 Apr 2015 16:58:16 CST

　　 一、算法模型

　　当用户输入关键词进行搜索的时候，系统依据算法模型来给匹配到的每个商品进行实时的计算，并按照分数的大小对商品进行排序。

　　考虑淘宝搜索的时候，有些特征因子是很容易能想到的，比如：

　　 A、文本的相关性：关键词和商品的匹配，匹配的程度，是否重要词的匹配，匹配词之间的距离等，都可能影响相关性。比如搜索“小鸭子洗衣机”的时候，一个商品的中心词是洗衣机的要比卖洗衣机配件商品的相关性高，小鸭子连在一起的相关性要比“小”和“鸭子”分开时候的相关性高等。文本相关性最基本的计算方式可以参考 BM25 等。

　　 B、类目热点：淘宝数据的一个重要特质是每个商品都挂靠在类目属性体系下面，每个商品都做了一个很好的分类。在搜索过程中，同一搜索词的大量用户行为数据很容易聚焦到相应的热点类目，比如“手机”的搜索行为会集中到手机类目，而不是配件类目。

　　 C、图片质量：图片是电子商务网站非常重要的一个数据，图片是否精美吸引人，图片上是否有各种各样的“牛皮癣”，和商品匹配度等都很大程度上影响着用户的点击和购买决策。

　　 D、商品质量：每个商品都有不同的质量，商品的描述真实性，是否物美价廉，受人欢迎的程度等。

　　 E、作弊因子：类似于全网搜索有关键词堆砌，link spam，网页重复等等作弊的问题，电子商务搜索也面临同样的问题，比如商品关键词堆砌，重复铺货，重复开店，广告商品引流等等，也有商品特有的问题如价格作弊，交易作弊等，需要利用统计分析或者机器学习来做异常行为，异常规律的发现和识别并运用到排序中。

　　 F、公平因子：淘宝的商品很丰富，每个搜索词下都有足够多的商品在竞争，需要在相似质量的情况下让更多的商品和卖家有展示的机会，而不是像网页搜索一样是一个基本静态的排序，照成商品点击和展示的马太效应。

　　那么如何衡量不同算法之间的优劣呢？

　　 二、线下评估

　　在淘宝搜索衡量狭义相关性的时候，一般是使用 PI（Per Item）测试的方法：

　　 A、抽取具有代表性的查询关键词，组成一个规模适当的关键词集合

　　线下的评测方法从统计上有一定的指导意义，能从一定程度上区分模型的好坏，但要真正验证算法模型的好坏，还需要接受真实的流量来验证。

　　 三、线上测试

　　不同的 BTS 系统会关注不同的数据指标，在淘宝搜索，有一些重要的指标是很多算法模型测试的时候关注的：

访问 UV 成交转化率：来淘宝搜索的 UV，最终通过搜索结果成交的用户占比。
IPV-UV 转化率：来淘宝搜索的 UV，有多少比例的用户点击了搜索结果
CTR：搜索产生的点击占搜索产生的 PV 的比例
客单价：每个成交用户在淘宝搜索上产生成交的平均价格
基尼系数：基尼系数是一个经济学名词，考量社会财富的集中度；如果社会财富集中到很少一部分富人手中的时候，基尼系数就会增大，社会的稳定性和可持续发展性就会出现问题；淘宝搜索借用了这个概念来衡量搜索带给卖家的 PV 展示，和点击的集中度，在保证用户体验的前提下，给更多的优质或小小而美的卖家展示的机会。

　　大部分时候我们都有好几个模型和功能在线上测试，我们用 BTS 的方式来观察测试的情况，如果提升稳定就逐渐开放给所有用户，如果没有提升，我们也能从中获得经验帮助我们更好的理解用户。

　　作者介绍：青峰，淘宝搜索算法总监。

淘宝网架构分享总结 - 架构,分布式,淘宝,虚拟化,水平伸缩

Sun, 19 Apr 2015 00:25:44 CST

关键字:淘宝网架构分享总结 - 架构,分布式,淘宝,虚拟化,水平伸缩
一场由淘宝的架构师，曾宪杰先生主讲的淘宝网架构分享。

一、为什么stateless比较有利于实现水平伸缩

关于什么是stateless的扫盲，见这个贴： http://kyfxbl.iteye.com/blog/1831869

一般有一个共识，就是把应用做成无状态的，会比较容易实现水平伸缩。但是以前一直有一个想法，就算应用是有状态的，也可以做成水平伸缩：只需要在负载均衡那里做一个session绑定就可以了，根据某种标识，把请求固定地发送到特定的server上

但是相对于有状态，stateless是更好的，主要有3个原因：

1、负载均衡不需要做session绑定，也就可以用更简单的算法，比如随机、取模等，把请求分配到任意server上，因此相对于session绑定的做法，性能会比较好

2、也是性能的问题，在7层网络模型中，session位于第7层，负载均衡如果是基于session的算法来决定要怎么分发请求，性能的损耗也会比较大

3、如果某一台server down掉了，后续的请求就没法继续往这台server发了，影响可用性

二、为什么淘宝开发session框架

如果将请求所需的信息，都放在cookie里，确实就不需要session框架了，而且也比较容易实现stateless。但是cookie也有自己的问题，cookie的大小是有限制的，还会增大网络流量（对于淘宝这种规模的应用，绝对不是一个小数），并且数据放在客户端，多少有点不安全

所以session还是要用的，但是如果session都放在app server里，stateless就不容易实现了，而且为了HA，还涉及到session迁移的问题，会比较复杂。所以淘宝自己搞了一个session框架出来

具体的实现就不清楚，不过知道了这个思路，也不是很困难。我猜应该类似于把session集中放在session server里，其他的app server都来共享就可以了。然后将session server做成集群，避免单点故障。同时session迁移的事情，也就转化成了集群的迁移

三、关于TFS

在《淘宝技术这10年》这本书里，“淘宝大学”的校长神话了这个技术。那天据曾宪杰先生说，TFS只是比较擅长处理小而多的零散文件，单机部署时性能也不是很好，但是在集群部署时，性能和可用性，确实有一点优势

这块我没有怎么研究过，当天曾先生也没有深入讲，不是很了解，就不多说了

四、淘宝子应用之间的集成，为什么不使用ESB

淘宝在11年左右开始拆分应用，走“服务化”方向之后，应用拆分了很多个独立的子应用（大约有1000个左右）

这么多的应用要在一起完成业务，势必涉及到集成的问题。但是淘宝没有使用ESB，而是用了自研的服务框架和消息中间件

这主要是因为ESB更擅长处理异构系统的集成，而淘宝这将近1000个应用，基本都是JAVA应用，所以ESB的这个优势不明显；另外，增加机器水平伸缩，是淘宝的杀手锏，如果采用ESB架构的话，那在水平伸缩的时候，就连ESB那层也要一起伸缩，比较麻烦

五、特性开关和优雅降级

稍微提到了一点，即在应用中放一些开关，在流量告警的时候，关闭一些功能，以主动避让的方式，避免系统压力过大而不可用。我理解类似于丢卒保车，在万不得已的时候，牺牲一些次要的业务，保护主要的业务

具体的实现没有提到，目前好像我们也没碰到过这种场景，先简单记录一下

六、分布式的好处

我原本认为，在满足条件的情况下，分布式架构会提升性能（条件是CPU是性能的瓶颈，以及大的任务可以分割成可并行的多个子任务）

不过那天曾宪杰先生反对这个看法，他认为分布式只会把本地调用变成RPC，带来额外的传输损耗，所以不但不会提升性能，反而在大多数场景下，会降低性能

我觉得不尽然，有时候分布式应该还是能提升性能的，对于那种CPU密集型的计算来说。比如NASA不是有一个项目，是利用很多个人PC，来计算小行星数量还是什么的。这个好像又叫啥网格计算。不过，我们做的大多都是企业应用，或者互联网应用，因此基本上CPU不是瓶颈（瓶颈主要在IO）；由于业务逻辑的关系，也很难说就能拆分成可并行的子任务，所以场景不太满足。因此对于曾先生的这个看法，我还是相当认可的

那么，既然分布式对于性能有减无增，为什么还要用分布式呢，总结了下面3个原因：

1、组件复用。这个很好理解，就不用多说了

2、提升开发效率。淘宝把一个应用拆分成很多子应用以后，就可以实现“小团队维护小应用”，做到了“专人专事”，效率比较高。此外，小应用显而易见，也更容易维护

3、实现“差异化水平伸缩”。这个词是我自己瞎造的。考虑这种场景，数据库只能支持10个连接，但是需要20个系统才能支撑http并发。那么这时候应该部署几套应用来组成集群呢？10个肯定不行，并发撑不住；但是20个也不行，因为每个应用都直接连数据库，又超过了数据库连接的上限

如果实现了分布式，那么就可以这样：部署10个service server，来连接数据库，对上层提供服务；部署20个app server，来响应http请求，不直接连接数据库。挺巧妙的，架构上也挺有美感

当然，数据库的连接数上限肯定不只是10个，上面只是打个比方。从侧面也看出，淘宝的业务量大到了一个超乎我想象的程度——居然连数据库的连接都不够用了

同时，这么多子系统要调来调去，是很复杂的（1000个子系统，想想都觉得很复杂）。所以淘宝开发了服务框架和消息中间件，来解决这个问题。或者说，正是先行一步有了这些基础框架，服务化拆分的路才能走得比较顺畅

另一方面，分布式架构也是有坏处的。比如部署和调试都变得复杂了，淘宝有专门的运维工具和开发工具，来减少这种痛苦。提到了一个google的Dapper，和淘宝自研的eagle eye。有需要的时候可以研究下

七、数据库的水平伸缩

相对于app的水平伸缩，数据库伸缩是比较复杂的。因为RDBMS本质上是单机系统。虽然可以部署N台db server组成集群，但是主要是保证了HA，也支撑更多的连接数。但是如果单个数据库里的数据量太大的话，读写都会变得很慢，还是瓶颈

最后没有别的选择，只能拆表，比如把user拆分成user1和user2（拆分的维度可以很多，基本上是水平拆分）。这就带来2个问题，第一是编程变得复杂了，简单的ORM+jdbc就搞不定了；第二就需要开始处理数据迁移的问题

针对这2个问题，淘宝的答案是，用TDDL做数据库路由，对上层应用保持透明；开发专门的迁移工具，在拆表后做数据迁移（尽可能缩短业务中断的时间）

TDDL没有开源，类似的有一个叫cobar的框架

大体的思路应该是这样的。本来应用的DAL层，直接就建立在JDBC之上，JDBC去连具体的数据库

但是这样的话，应用就依赖底层的数据库。当需要查询一条数据的时候，应用需要知道应该去哪个表（或者哪个数据库）里查询；在数据库伸缩的时候，应用的代码也要跟着改才行。这样肯定是不大好的

所以，在DAL和JDBC之间，又增加了一层，也就是TDDL

现在，DAL不再是直接依赖JDBC，而是依赖TDDL。数据库路由的功能，都在TDDL里完成，底层数据库伸缩的时候，也是在TDDL里进行“配置”，应用的代码不需要变化。果然是应了那句话，“计算机的问题，大多可以通过增加一个抽象层来解决”

TDDL的实现不清楚，也没有开源。不过我猜测应该也是封装成一个DataSource，适配JDBC规范，这样其上的ORM框架，也就可以直接使用了。然后在TDDL内部，会去解析SQL，处理配置文件（数据库路由），并且依赖厂商JDBC的实现，去真正连接底层的数据库

总的来说，淘宝这个基于TDDL的方案，还是在解决RDBMS水平伸缩的问题。应该也正在引进NOSQL的方案，互为补充

八、关于虚拟化

淘宝内部也用到了虚拟机，也就是私有云。大致有几个好处：

1、硬件一虚多，提升硬件利用率，降成本

2、应用和具体硬件隔离，便于维护

3、硬件的内存太大时，JVM对内存的管理不是很好，不如把一台硬件虚拟化成多个虚拟机

淘宝非常重视对硬件和应用状况的监控，好像由于历史遗留原因，监控的工具很多是针对单个进程的。所以目前常见的做法，是一台虚拟机上只启一个JVM（单进程），和过去的监控工具相兼容（这里没有详细说，刚好那会我也有点累了，听得不是很仔细，不知道有没有理解错）

另外淘宝用的虚拟化工具是linux container，好像跟VMware那套解决方案也不太一样，不是完全的虚拟机，而是更轻量级的硬件资源的隔离，后面可以再研究一下

九、OSGi在淘宝内部的使用

现在基本不怎么用了，OSGi主要的价值，在实际中体现得不太明显

比如类隔离，用更简单的自定义ClassLoader也可以实现；单机多版本服务，用的场景也很少；热部署也不是很实用

但是，基于OSGi框架做开发，复杂度的上升又是显而易见的。因此，用很高的代价，只能换来较少的收益，在开发人员之间推动很困难，渐渐地就不怎么用了

我们之前的一个产品，也是类似的情况。公司内部一个平台，三年前的一个主要卖点就是OSGi架构，好处也就是OSGi官方宣传的那一套，而现在最新的版本也在“去OSGi化”，有一种走了弯路的感觉

我个人觉得，除了明显增加开发复杂度之外，OSGi还有一个问题，就是和java ee规范的兼容性，离完美还是相去甚远。就连最简单的一个问题，“OSGi框架与servlet框架嵌套”，现在虽然有方案，但是同样相当复杂。我觉得对于OSGi，目前还是保持适度的关注就可以了

十、去IOE化，后续的趋势

这一节本来不想写，是关于淘宝去IOE化，以及后续的技术规划。感觉没有什么新东西，但是大领导就喜欢听这些。还是先记一下，后面写胶片说不定有用

淘宝有一个动作是去IOE（IBM的小型机、Oracle数据库、EMC高端存储）。早期的淘宝，主要靠的是高端硬件，思路就是用钱解决问题。但是这样做的成本很高，淘宝的业务规模又扩张得太快，所以要用更经济的方案。用PC Server、MySQL数据库等，通过大量廉价的硬件，水平伸缩组成集群，来替代昂贵的硬件，思路就是用技术解决问题。跟google的思路一致

淘宝V4.0的几个技术趋势：页面组件化、私有云部署、多终端。没有什么新东西，实际上我们2012年也在考虑这几个规划，那天听到曾宪杰先生说淘宝也想做这么几件事，我觉得有点惊讶，怎么这么巧。实际上我们产品目前的规模（并发和数据量），连淘宝的零头都不到，因此也不是很急迫，应该是预研性质的

十一、总结

本文大致记录了那天的收获，有些内容很受启发；另外一些当前不太用得上，先记录下来留着以后再想想

总的来说，我对曾宪杰先生的水平很佩服，淘宝架构师确实是名不虚传

此外还有一些技术之外的感悟，主要有2点

一整天的交流下来，我能感受到淘宝一种很务实的精神，我感觉这是我司目前所缺少的。曾先生多次提到“先work，再优化”、“当时也没想那么多，只是先解决问题，不然就死了”、“专人专事，小团队负责小系统”，我觉得很朴实，但是很有道理

反观我司，现在动辄就100多号人做一个小产品，想用数量弥补质量的不足。实际上我觉得反而是降低了效率（这些产品我觉得10个人左右的小团队，完全可以做得更好），同时也造就了大量的领导岗位，催生了各种流程，进一步降低了效率

还很喜欢搞“架构”，花了很多的资源，最终却没有在产品中落地，带来什么业务价值，只是把产品做得更烂，同时制造了一些“专家”

我觉得淘宝也有这个趋势。公司慢慢大了，优越感就来了，夸夸其谈的风气慢慢也滋生了。只能说，并不是话多声音大的就是专家，各人有各人的活法。个人感觉，淘宝慢慢也会走向我司目前的状态，可能这是大公司的通病，也是人的通病。。

另外一个感想，就是觉得淘宝现在有这么一批技术高手，很大程度上是业务造就的。所谓时势造英雄，业务规模不断扩大，逼迫技术必须进步，解决业务问题，反过来也促进了业务的发展

而作为早期的淘宝技术人员，见招拆招，解决各种技术问题，慢慢也就成为了高手。所以，应该要承认淘宝技术的强大，但是也要客观看待，没必要盲目神话和崇拜。淘宝做的也就是一个规模巨大的商城，不是原子弹或人类基因图谱什么的

再次感谢曾宪杰先生，水平很棒，表达得也很好。下次有类似的机会，还会去参加

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

手机淘宝构架演化实践

Fri, 26 Dec 2014 10:59:18 CST

　　李敏主要负责淘宝无线客户端和无线网站基础服务、购物主链路的架构、研发方面的工作。从09年开始参与手机淘宝研发团队的组建和线上产品研发，先后负责过无线部门的社区、会员、营销、交易等多条产品线的技术工作，构建和发展了阿里无线技术体系中包括交易链路、百亿级别高性能API网关、WebApp平台等多个重要技术产品，经历和见证了阿里巴巴无线从开始之初到成为日活上亿级别电商应用技术变迁和积累。

　　本文即根据李敏的演讲整理而成。

　　 发展阶段

　　从2009年开始，DAU从100万增长到超过1亿，面临的问题、包括研发支撑所需要解决的事情各不相同。在用户量和业务复杂度的线性递增下，架构也进行了相应的演进。如下图所示，具体可以分为四个阶段：

第一阶段，手淘的前身WAP网站，业务初立、变化快，需要快速发布，采取HTML模板和单一应用，最大程度满足快速发布和修改的需要；甚至不需要改动后端的业务代码，在前面的模板上做一些修改就可以了。
第二阶段，DAU的快速增长，WAP/Android/iOS多个平台的业务起来了，需要在多个平台上进行快速的业务复制和业务管控，统一API网关出现。
第三阶段，DAU进一步增长，线上系统越来越多，业务的多样性需求更多的体现出来，基于HTML5的一整套解决方案上线，更多的HTML5和Native混合的业务形态，API网关进行进一步优化和扩展，更方便的接入方式。
第四阶段，当DAU达到100M的时候，全集团的业务都需要在手淘透出，API网关被部署到更多的IDC机房，如何更有体系化的进行有效的研发、接入更多业务、并进行更有效的业务监控，需要更加体系化的架构治理。

　　 API网关

　　做WAP的时候没有所谓的API网关，为什么要用API网关呢？

　　随着应用数量的增多，每个应用分别暴露的API出口很多，修改的话逻辑很复杂，这时候应该引入一个统一的网关。

　　但随着DAU的增长，API网关会成为一个单点。开发团队在中间做了很多技术和架构上的努力，主要有几个关键点。一是后端接入很多应用，其实API网关只是通路，理论上不存在调用的上限，只要内存够大，包括网卡的流量够的话都可以上来。二是有必要的机制做到宽阔的调用网关。还有一点，当后端业务要经过API网关时，其实现在业界很多都是典型的RPC的模式，RPC的模式有一个绕不开的问题，就是可能要设定一些东西，这时后端服务跟API会有一定程度上的耦合。现阶段要接入服务，后端服务器随时都会变化，不可能后端服务变化的时候都对API做相应的发布，这是不现实的。所以有一套自己的RPC机制，解除了这种强类型的约束。

　　此外，可以在网关上附加很多功能，比如安全、审计，还有一些日志、审查等。

　　到了现在这个阶段，要进行异地部署，很多IDC，这样的话引入API网关很可能会带来问题。包括今年的双11或者是双12，要在多个异地机房支撑手机淘宝的业务，会有很多API网关。

　　比如说像APP可以在中心网关上面询问，应该去哪个真正的API网关。然后中心API网关会告诉它结果，它再连接到所在地的API网关上，然后再向后端API发起调用，所有API的服务网关都受管控中心统一管控。比如说增加一些新的功能，上线一些新的API，包括一些引流、切换，这些指令都会在管理平台上向各个API网关发送。

　　 手机端

　　 1. Bundle

　　去年下半年，开发团队对整个手机淘宝的架构做了比较大的调整，如下图所示，左侧是运行时的架构分布，右侧是工程代码级别的分布。在运行的时候，其他的业务团队提供的都是一个个的业务Bundle，这是可部署的单元，包括UI、服务和标准中间件的调用代码，下面有一个总线程，负责管理和开发好统一的UI服务，包括消息服务的总线。再下面是运行容器，上面跑的的是所有的Bundle的东西，对应运行时的东西，右侧是真正在开发时候的结构。比如说聚划算，它要开发它的业务，就做一个单独的工程，然后去开发；它只用开发自己的，开发到差不多的时候，就将其代码打成一个Bundle提供过来，然后一起打包发出去。

　　 2. WebApp

　　下图是现在手机淘宝上关于HTML5的整体框架图。手机淘宝上的方案大致分为两部分，中间那一部分是手机淘宝自己开发的HTML5的运行容器，它负责在上面跑各种各样的WebApp，在线上有一个统一发布管理系统，它可能对性能进行检测，包括CDN是否符合规格，HTML本身有没有异常等情况，经过这些必要的检测，包括审查之后，它统一发到CDN上。容器本身其实也会接受运行时的信息，容器接收到这两边的指令之后，它自己会做一些更新配置，也可能会装载运行，从线上系统下发新的WebApp。此外，还可以运行WebApp或者是做URL的导航拦截，甚至做一些交互。

　　 3. PackageApp

　　这是今年新的建设，整个系统是基于前面整个体系来做的，称之为PackageApp。

　　这个跟前面最大的区别就是让用户感知不到前面同步下载的过程，大概的做法是：把HTML5以及WebApp在发版之前先做一些预知放到客户端里面，前面会做两件事情，首先按照原来的逻辑运行，其次就是在右侧的蓝图里面，它会去做一些UI的拦截，发现用户点击的icon进去之后，整个URL是符合用户规范的，它会启动检测机制去检查线上是不是有新的版本需要下载，如果有的话会启动异步更新模块，从CDN上拉取新的WebApp版本，否则会走到原来的地方，最后既不影响用户去使用WebApp，又能把自己最新的版本更新到所期望的版本，这由统一的管理平台去发布。

　　在方案设计之初，还思考了三个方面，首先它是标准的URL，在点击进去之后是导航的URL，对于前端工程师来说，他设计研发WebApp跟客户端或者是线上跟HTML5的网站是一致的。其次，手机淘宝自己的容器，制定了自己的规范，在底层的容器上面可以实现手淘定义的规范。第三，“不同网络、全量、差量更新”，这点很重要，在移动互联网场景下，到底要发起几条链接拉取资源，在WIFI下怎么拉取资源，其实都是不一样的。在不同网络下面，对策都不太一样。

　　下面是采用PackageApp后业务模块LoadTime对比图：

　　 支撑体系

　　除了前面介绍的内容，比较大的电商App，还需要一个很完备的支撑体系。如果没有的话，在线上运行的情况是不可感知的。手淘在不同的维度也做了很多支撑的工具。

　　 1. 研发支撑

　　在研发支撑上面，像传统的Reivew代码，特别是做客户端的同学几乎都会做统一的UI库，大家会设计模板，比较典型的，会有所谓的日常预发、线上染色等等。它的集群数量跟能够进来的用户是很有限的，通过这个环境来确认所开发的代码发布到线上可能会有什么问题。一套代码经过预发之后再发布到线上去，最后有一个染色环境，比如说用户打电话反馈遇到的问题，比如说下单下不了或者是搜索无结果，这时会有一个染色集群，把用户定位到染色集群上面，对用户专门进行一些分析，现在还没有做到直接在用户机器上做调试，但是用户到了染色集群上面，整个调用的链路会剥离出来，比较好分析用户到底发生了什么事情。

　　 2. 测试支撑

　　App的测试很重要，除了比较常规的单元功能测试，还有很重要的像稳定性跟性能，以及自动化这些都是很重要的。像手机淘宝差不多是一个月左右的时间可能会迭代一个版本。比如说新的功能开发会不会影响到老的功能，智能化测试很重要，可能分成两部分，一部分是线上所有的API，包括业务逻辑是不是正常。另一部分是新写的代码会不会有问题，因为前面架设了统一的API网关，所以会在网关这个层面做很多自动化的调用回归，构造很多正常用户的数据去测试线上API系统的返回值，包括一些异常是不是正常，来保证线上业务逻辑的正常。在客户端这一侧，则会做很多自动脚本的回归，保障整个客户端新做的代码跟原来相比没有什么问题。另外还引入了比较多的静态代码扫描，保证不会出现低级问题。

　　 3. 运维支撑

　　移动App的运维支撑跟线上不太一样。除了常见的性能跟稳定性分析，还有针对App的业务监控跟舆情监控。舆情监控这个应该是移动App所特有的环节，大家通过市场去分发，很多用户会发评论，iOS特别明显，有人说好，有人说不好，安卓更复杂，特别是国内有大大小小非常多的应用市场，不一而足。所以怎么对舆情做一个有效的监控，既能通过舆情监控，快速收集问题，也能做一些梳理分析，找到产品或者是性能方面的提升点。

　　 4. 发布支撑

　　发布支撑，其实也是在大的App上面才会出现的，针对一个人群的发布。传统的直接是发到市场上，大家都收到了。而手淘现在有很多内部灰度和外部灰度正式发布，可能有一些内测版本只发给阿里巴巴集团内部员工，这可以通过自己做的发布系统来支撑，有比较灵活的发布策略调整：可以圈定一批用户，也可以选定一个区域，甚至可以用后台数据做合理的设置给特定的版本推送特定升级的版本。

　　如果App发到用户手上，结果发生了致命的问题，怎么办呢？其实有两种方法修复线上的问题，第一个是直接替换，另外就是更小维度的补丁，现在在安卓上做的比较多。

　　李敏还分享了一个案例，在上半年有一次大促的时候发生了一个问题，零点就要促销了，版本可能是前天刚发布给用户的，那怎么办呢？如果是替换的话也可以做到，但是下载数据量非常大，刚发布不久对用户影响比较大，所以选择了用补丁修复，主要是类似于替换，用JAVA开发的应该知道，主要是用类替换的方式做的。在iOS上也有一些方案，不过还在尝试当中。

　　 客户端监控

　　可以在分钟级别确定用户调用某个操作的成功次数、失败次数和失败率，实现对业务可用性的监控。

　　 舆情平台

　　舆情平台是移动App所独有的。要获取信息，会从用户手机淘宝自己填的反馈，利用市场和微博，实时抓取，然后把内容聚合起来，进行热门词归类，筛选出一些热门的标签话题做一些智能分类，分类之后大致知道到底是支付、详情、退款出现了什么问题，确定问题的重点之后，可以直接联系用户，甚至去跟踪用户，根据这些问题去修复线上的紧急问题或者是改善产品，这就是在线上实际使用的舆情平台。通过热门词的分类排名，就可以知道某一个版本在某一个阶段最重要的问题是什么，还扩展了用户集中反馈。

　　比如举办一个抢红包的活动，这个活动出现了什么问题，大量的用户重复反馈这个问题，就可以把热门的话题聚集起来。另外还可以通过舆情平台确定某个技术的改造是否成功。

　　舆情平台早期主要用于收集一些信息，后来发现把舆情收集起来做一些大数据分析，可以得出很多自动化的结论，甚至可以验证研发的结果是好是坏。

　　演讲的视频会在制作完成后发布到我们的网站上，敬请期待。

揭秘淘宝买衣服潜规则，你们吃亏吃大了!

Sun, 21 Sep 2014 00:32:07 CST

本人，目前在一家淘宝店工作，淘宝也就是大部分亲们经常去消费购物的地方，凡是在淘宝买过衣服的亲，带某某品牌的，基本上都买到过高仿、A货甚至质量差的一塌糊涂的。相信凡是做过淘宝服装的同志们都会认同我所说的一切。

首先，现在做淘宝真的很累，我只是上班的，如果个人开店什么的，真的是苦不堪言，新闻报道某某皇冠店掌柜的猝死什么的，真的太正常了。

当然，忙到猝死，说明她的店生意很好，赚钱多，而很多店铺都是没有生意的，要想有生意的最简单的一个办法也是大部分人所使用的办法就是做仿品!!!!

因为搜仿品品牌的人多啊，带来的流量也就大啊。仿品价格也低啊，这样一来，就卖得动了啊。正品卖一件赚 1000 块钱，能卖 20 件。

仿品卖一件赚 100 块钱，但是都是上千件几百件的在卖啊。利润可想而知。所以累是正常的，猝死也是正常的。

总而言之，一入淘宝深似海。没有货源，没有运营的人，没有经验，都是扯淡，别说你不会做淘宝，其实就是看你有没有良心，敢不敢作假而已。

前几天，有个女老板，做淘宝，卖高仿奢侈品，赚了 2000 多万，进班房了。只能说枪打出头鸟。她做的太大了。严重侵犯知识产权了，人家正品还没有吃饱喝足，就被做仿品的吃饱了。是你的话，你会不会报警呢?

下面我来告诉大家，你们是怎么一步步的去买仿品的吧。首先，你去逛实体店了，嗯，穿的确实好看，漂亮，帅气，高端大气上档次。

然后看了一眼吊牌，顿时吓傻了吧，拿欧时力女装来说，一件羽绒服 2000 很正常吧，一点布料，一点绒子(先不谈是白鸭绒还是灰鸭绒)，再多个拉链，觉得不值，确实不值。

然后，聪明点的就把货号记住了(大部分衣服货号是单独的)，然后手机淘宝或者回家电脑搜一下，出来若干跟实体店一模一样的。

再聪明点的，直接躲着导购，拿手机淘宝扫一下二维码或者微信扫一下二维码(二维码都是单独的)。

笨点的，记住了衣服样子，回家拿电脑直接搜“欧时力羽绒服”，然后找半天，终于找到了。

好了，下面就是你被忽悠的时刻了。

一看到相同的衣服，你会迫不及待的看价格，哇塞，专柜 1998，这家店只要 258 呀，还有专柜小票，还三标齐全，简直比正品还要正品。赶紧抢啊。

这个时候，大部分人还是很理智的!不会是假的吧。要不我再找找，哇塞，又看到一家，卖 388，488，588，一直到 1998 的，每个价位都有。

而且几乎每家都有专柜小票和三标，有的还送购物袋。这个时候你又开始思考了，买哪家的好呢?就在这瞬间，你会想，看哪家销量高，哪家评论好就买哪家。恭喜你，你马上就要上钩了。

你一看，488 的这家不错呀，卖了 200 件了，不过评论真少，才几个评论。不过评价都是夸衣服不错的。还推荐姐妹们一起买。既然大家都买了，那我也买一件看看吧。这时候，你就去找客服了。

亲，在吗?

嗯嗯，在的亲。

你家的衣服是正品吗?跟专柜一样的吗?

是的呢亲。一模一样呢，正品的，三标齐全，支持专柜比较，原厂原单。

哦哦哦，那为什么价格差这么多啊?

亲，我们是原厂的尾单，计划外物资，都是原厂多余的存货，跟专柜里是一样的哈。保证您的质量哦。

哦哦哦，质量不行的话怎么办啊?

亲，质量问题，可以七天无理由退换的哈。

嗯嗯，那我拍一件哈。能不能给我包个邮啊?

亲，衣服实在没利润，包不起的。您在收到货，给我们 5 分 15 字好评，我们可以给你返 5 块钱现金到支付宝里的哦。

嗯嗯。那我拍了哈。

下面开始，说几处疑点。

1、专柜 2000 的衣服，你说低于 1500 在任何地方能买到吗?一件 2000 的衣服，进价一般是 5 折，经销商赚一折，起码也要 1200。你说，你花四五百甚至八九百，能买到吗?花了八九百，你就以为能买到真货了。其实，你只是在自我心理安慰罢了。

2、为什么八九百的还能是假的?我告诉你吧。淘宝里，有 80% 的人都是代购什么的，这些人中 90% 都是在说瞎话，一个普普通通的小老百姓，凭什么人家大公司大品牌让你去一件两件去拿货? (尤其是韩国东大门代购，全是瞎扯淡，谁会为了卖几十件衣服，跑去韩国坐飞机进一大批货?机票超重的价格吓死你)这些人偶尔会钓到一两条笨鱼的，等他们成功的忽悠你付完钱以后，就开始自己当消费者，到其他卖二三百的店里去买，好一点的，回来自己贴个假商标，再寄给你。差点的，直接下单，地址写你的地址。然后呢。你要是能接受，ok，所谓代购一下子赚了 600 块。不费吹灰之力。你要是不能接受，ok，请你退回，衣服减去运费，再请你把衣服退回到代购的那家。邮费还是你的。反正所谓代购又不赔钱。

3、为什么这些代购自己没有衣服发呢?亲，你图样图森破了。衣服不是一件一件做出来的。面料，鸭绒，里料，拉链，毛领，不是你想拼接就拼接好的。像欧时力这样容易起量的，要么不做一做就是 500 件的。不然哪个工厂会接几件衣服的小单子?

4、为什么卖了 200 件了，却只有几个评价呢?哈哈，只有笨蛋才会相信那几个评价。你可以认真的想一下，是不是给卖家评价的时候，除非特别嫌才会多说几个字，一般情况下，随便说几个字就完事了?而你现在看到的这些评价，清一色都是几十个字，把衣服夸的跟亲儿子似的，恨不得买一千件分给所有人。好吧，你现在也知道了。这些人有个专业的字来概括――托。也就是刷单的。这也就是为什么卖家在你买的时候告诉你衣服要一个星期发货的原因了。因为根本就没货，还在生产中呢。发毛给你啊?而真正的 1500 的，你随时拍下来随时都可以发货的。懂了吗亲?这样的情况太多了。你只要淘宝，一定会遇到。

5、为什么很多衣服的图片都跟有货一样?呵呵，这还不简单?随便挑个专卖店，衣服挂在那，去拍一下呗，又不麻烦。这是一种，第二种方法就是，网上不是有现货的真品吗?买一件回来，不是都支持七天无理由退换吗?ok。七天时间，找个模特穿下拍个照或者直接挂在衣架上拍都行。同时花 3 天时间让工厂赶紧打版，裁衣服，看看衣服的构成，直接做个样衣出来。都 ok 了，赶紧找个理由把价值 1500 的正品退掉。1500 的商家一般都不让退，除非是天猫都让退，好吧。我把你衣服故意弄坏，然后说是质量问题，淘宝网支持质量问题退货。

6、大部分高仿货都是自己花几百块钱做的上千个吊牌和三标。但是这是违法的。个人小搞搞混口饭吃是可以的。但是公司做高仿就不行。因为老板是要坐牢的。这怎么办呢?第一，直接不加标，说是原厂出货，都是剪标的，这就是三无产品，哈哈。第二，没标难看，直接用自己家公司的商标或者做个高仿标。换个字母或者少一撇等。反正衣服没有知识产权，我用的是自己家的标，也不违法。但是等买家拿到手一看，我靠，不是正品的标。这时候，你怒气冲冲的去找客服，客服会告诉你，亲我们的衣服是正品，但是品牌要保护专柜的利益，所以不让我们用原品牌的标，你能接受就接受，不能接受就退货，反正来回邮费，你自己花。这时候，你想，有道理。专柜 1998，我这才几百块钱，而且样子一模一样，行，不纠结了。ok，你成功上钩了。

7、为什么要 5 分好评返你5-10 块钱? 首先，淘宝现在是按照 DSR 评分来给店铺和衣服进行排名，这个评分是什么?就是你进去店铺的时候，有三个分数，一般都是 4.8 左右。大家以后进一家店铺的时候，不要看几个钻几个皇冠，没用的。你要看那三个评分，如果三个评分的颜色是绿色的，果断关掉这家店，三个全是红色的，可以看一看，如果发货速度是绿色的，那你就要知道，这家店做的是高仿。因为一直让大家等货啊，生产很慢的，所以大部分买家都给发货速度评分比较低。好啦。看完之后，知道，为什么要给你返 5 块钱了吧?不要以为是为了你的几个字的好评，是为了店铺能继续卖下一个高仿，懂了吗?亲。

8、那应该去哪里买正品呢? 其实一件女装，不带毛领的羽绒服，用国标 90% 白鸭绒的，成本都是 180-250 左右，带毛领的话，就看是什么毛领，一般是貉子毛领，大毛领的话，加 100 块钱左右。假毛领的话，15-30 块钱一条。还有就是兔毛领，一般 30 块钱左右。所以，你要是买了一件羽绒服七八百上千的话，我只能说呵呵。被宰了还帮着数钱。

男人的羽绒服更便宜了，最多成本加做工 300 块钱算是很不错了，但是卖给你的话，起码 800 以上，因为男人有时候比女人要面子，不还价。而且觉得 800 块钱太少了，起码卖 3000 才好，因为这样才能穿出去吹牛。有面子。呵呵。

9、个人觉得，买衣服去一些批发市场比较好，只要你懂一点点的成本概念，买衣服的时候，自己算一算价格就能估算出价格，然后砍价的时候也有底气了。不会算的，我可以教哦。很简单。不要迷恋什么牌子不牌子的，太虚伪。比如歌莉娅，艾莱依，维伊，波斯登，七匹狼，金羽杰，欧时力，圣迪奥，乐町，播，百家好，拉夏贝尔，cc dd ，鸭宝宝。除了波斯登质量可以价格偏高，鸭宝宝旧款物有所值以外，其他全是瞎扯淡。什么鸟品牌，质量根本就不行。大部分衣服里面充绒竟然是灰鸭绒。亲们懂什么叫灰鸭绒吗?可以百度下。点名批评欧时力。歌莉娅也是。总结下，劝大家不要相信这些所谓品牌，懂衣服的人都不会买的。

10、淘宝集市不能买，那天猫可以买吗?呵呵，只能说，70% 的天猫也不是东西。举例说明，大部分天猫店的品牌，你听说过吗?老品牌的质量都不行了。这些杂牌你也能信?进天猫开店就牛逼吗?呵呵。其二，比如歌莉娅天猫店，标价和实体店一样，难道真的和实体店一样?最简单的例子就是充绒，天猫店充的是灰鸭绒啊，你知道吗?灰鸭绒啊!3000 块的标价啊。灰鸭绒 50 块钱能买一麻袋呢!竟然有傻，逼买啊!钱难道真的跟废纸一样吗?歌莉娅和欧时力都是广州的两个国产品牌而已。说白了，就是自己吹牛逼把自己捧上去的两个杂牌而已。如果你洗一次就跑绒了，你去问客服的时候，他们会懒洋洋的告诉你。亲，我们卖的是网络款。本来就和实体店不一样。呵呵。

11、至于一些淘品牌，我更是无力吐槽了，去年双十一，网络著名品牌妖精 de 口袋退货率是 160%，为什么多出 60%?因为十月份的退了 60%。双十一买的亲们几乎全部退款。好一点的像茵曼，衣服稍微贵了一点，但是比韩都衣舍什么的好一点。韩都衣舍，只能用两个字形容――垃圾。质量是一塌糊涂。价格瞎标，江南布衣，裂帛还赶不上韩都的衣服。这些所谓的网络淘牌子，其实都是淘宝刚开始的时候入驻进来的，很多都是在批发市场拿货赚差价过日子的，卖的都是杂牌子。不过淘宝突然就火起来啦，阿里巴巴当然要扶持这些老革命家，所以它们能做起来有一部分这个原因。更多的我相信是因为坚持!

网站分析公会 ( 微信号： idiaa-org )

本文链接

王海亚：淘宝交易系统演进之路

Thu, 26 Jun 2014 22:07:24 CST

淘宝的交易系统承载了购物车、下单、订单管理等多项淘宝的重要业务，随着淘宝业务量的不断上升，交易系统也随之几经改造。InfoQ此次专访了阿里巴巴架构师王海亚，另外作为ArchSummit深圳2014大会《电商，各走各的路》专题的讲师，王海亚将会分享淘宝交易平台的架构演变及并行化实践。以下为专访全文：

InfoQ：淘宝的交易系统，主要承载了哪些业务？

王海亚：从用户视角来看，交易承担了购物车、下单、订单管理这些功能；从功能视角来看，交易系统包括做业务规则和服务整合的交易平台以及支撑交易功能的底层服务，服务包括商品、优惠、库存、订单、物流等，业务规则主要是确定在不同的购买场景如何使用底层服务的不同功能，比如什么样的购买要走付款减库存，什么样的购买要走预售模式的价格体系和支付体系，什么样的购买要限制使用积分等等。

InfoQ：请您简单介绍下交易系统的架构演进过程。

王海亚：个人把交易系统的演化分成三个阶段，第一个阶段是单应用阶段，那个阶段淘宝的业务比较简单，业务量也比较少，交易系统相对还是很简单的，当时的交易系统只有一个应用，囊括了商品、优惠、物流、订单等功能，一个小的开发团队就能够完成交易系统的开发维护工作。

随着承载的业务越来越多，交易系统变得越来越复杂，需要投入越来越多的开发来维护这个系统。人员规模上去之后，内部沟通的成本、代码管理的越来越高，大家都针对一个代码库做更新，很难保证非常好的功能模块设计，经过持续的代码累积，满足业务需求并行开发越来越难。后来提出了服务化改造，从原来的单一应用中逐步做功能剥离，拆分出多个系统，每个子系统负责不同的功能，由不同的团队维护。交易系统的架构进入第二个阶段，交易系统采用分布式架构，存在多个后台服务系统，多个前端应用。商品、优惠、库存等功能逐步沉淀成纯粹的后台服务系统，原来的交易系统作为前端应用存在。由于组织结构的原因，当时是存在几个交易前端应用，比如说当时的商城也就是后来的天猫，无线团队等等，因为前端内容的差异，都有自己独立的前端应用。

服务化改造之后，从某种程度上缓解了第一代架构的缺陷，但是新的架构在落地过程中还是存在一些问题，比较突出的有两个问题，一是由于功能是从原有单核应用中剥离出来时，缺乏一个明确的功能边界定义，对业务规则和功能的识别没有统一的标准，导致业务规则和功能存在紧耦合，同一个业务的业务规则一部分在前端应用中，一部分在后端服务系统中，业务规则变化又比较快，任何一次规则变化都要涉及到多个团队做配合实施，沟通协调的成本比较大；另外一个问题是由于多个前端应用，前端应用做的比较重，业务逻辑都要在多个前端应用中重复实现，除了开发的人力浪费之外，也引发了很多由于落地节奏不一致导致的业务问题，即使耗费大量精力做沟通协调也无法完全避免此类问题。

在新的系统架构中，对业务规则和功能做了明确的识别，通过集中式的业务规则控制以及功能定制化机制，实现业务规则和功能的完全解耦，多数情况下业务规则变更不会引发后台服务系统的变更，后台服务系统的功能增加也能做到对前端应用的透明。另外在前端应用中引入新的编程框架，通过框架做纯粹的服务整合就能组织出要给用户披露的信息。前端做轻之后，针对不同终端提供统一的业务服务，或者针对不同终端根据单页需要披露的内容来做不同服务的整合，成本都降低很多。

InfoQ：没有改造之前的交易系统，大概遇到了哪些问题？

王海亚：问题主要可以分成三类，第一类问题是业务快速落地很难，由于交易的业务规则变更很快，通过casebycase代码修改，系统中功能与功能之间的耦合越来越多，系统维护成本越来越高。另外业务规则散布在多个前端应用和后端服务系统中，经常由于各个系统的规则不一致或者上线节奏不一致导致业务故障。第二个问题是系统接入的成本很高，由于业务的需要，会引入越来越多新的服务系统提供对应的功能，这些服务都是在一个前端系统中做服务的整合，一个点的不稳定或者性能瓶颈，都会影响整个系统的稳定及用户体验，想通过小成本的尝试来做业务创新的验证成本非常高。第三类问题是前端应用比较重，业务逻辑主要存在于前端应用中，前端应用的页面逻辑和后台逻辑职责边界又不是特别清晰，导致前端应用的开发成本非常大，另外又存在多个前端应用，业务逻辑的一致性很难保证。

InfoQ：新的交易系统是如何解决老系统的问题的？

王海亚：总结来说，可以从7个点来讲。

第一，通过服务治理，把业务规则从原有功能中剥离，明确各个服务所提供功能的完备性及独立性，从系统边界上确保功能之间无耦合。

第二，通过集中式的业务规则管控，保证交易全链路的业务规则统一及业务规则灵活可配置。

第三，通过标准化的交易框架及组件化设计，保证服务在交易平台快速接入。

第四，通过异步并行及容错，提升系统响应速度，减少单点服务故障导致的整体不稳定。

第五，通过开关及预案机制，保证代码的兼容性发布，业务降级容错。

第六，通过流量管控，防止雪崩，保证在正常情况或者某个服务集群能力波动时，整个交易系统不被压垮。

第七，通过在前端应用中做前后端解耦，通过约定的数据模型，前端开发只负责页面展示和交互，实现前端、后端的并行开发，也使得不同终端的自适应可以以较低成本实现。

InfoQ：新的交易系统是如何应对交易洪峰的？

王海亚：由于交易的调用链路比较长，从Web服务器到执行链路中的各个服务系统，包括缓存、DB等存储系统，请求都是以队列的方式被处理。各个系统如果没有处理好容量控制，就会导致请求的堆积，对外呈现的就是响应时长增加。

在处理链路比较长的情况下，这种异常会被放大，链路后面的一个点发生堆积，前面的各个点也会逐步出现堆积。页面应用又是一个用户强交互类型的应用，如果用户发现慢就会刷屏，而后面的系统无法感知接下来要处理的请求是否是有效的请求，这种情况下可能会导致整个网站的瘫痪。我们目前是在前后端应用中都引入流量管控机制，主动拒绝超出自己处理能力之外的请求，保证每个应用都不会被压垮，有多少能力就能把多少能力提供出来。

另外在前端应用处理流控时，主动引导用户到低成本/静态化的页面上，增强用户体验，也能提高网站其它部分的曝光率。整个流量管控体系，除了应用框架的能力之外，还有一些配套的机制，比如自动化压测系统、容量计算公式、自动化扩容/下线等，整个一套体系，确保我们轻松应对交易洪峰。

ArchSummit全球架构师峰会即将于7月18-19日在深圳举行，此次会议重点解析九个当前最受关注的领域，包括：SNS、移动互联网、金融、大数据、智能硬件、游戏、云计算、自动化运维、电商等专题。目前正在火热报名中，感兴趣的读者可以访问网站主页了解更多信息。

作者：u012407273 发表于2014-6-26 14:07:24 原文链接

阅读：100 评论：0 查看评论

淘宝AOP缓存技术之taobao-pamirs-proxycache

Sun, 25 May 2014 20:48:09 CST

一简介

在项目中使用Spring的注解方式配置实在是不爽啊，写起费劲，维护起来也麻烦。
最近看了很多淘宝的开源项目，其中有一个项目使用AOP+XML方式配置缓存，灰常方便啊。
http://code.taobao.org/p/taobao-pamirs-proxycache/
官方给出的maven地址根本不行啊坑啊。
下面是官方给出的
    <dependency>
      <groupId>com.taobao.pamirs.proxycache</groupId>
      <artifactId>taobao-pamirs-proxycache</artifactId>
      <version>2.0.3</version>
    </dependency>

简单介绍一些proxycache
1、taobao-pamirs-proxycache 的目的是产生一种和业务代码完全隔离的缓存工具.开发只需要编写业务代码.缓存的使用完全通过配置文件进行.
2、缓存可以动态的增加和去除.
3、缓存功能和存储机制分离. 可以选择不同的数据存储方式来获得数据.
4、可以通过JMX控制台查看缓存状态,命中率,读取/写入平均耗时,修改缓存数据.
5、可以设定缓存自动更新,格式为标准 quartz 格式（请参照： http://dogstar.javaeye.com/blog/116130）
6、提供一种动态线程缓存,可以对一个流程内的数据自动缓存.

二编译安装

下载源代码，我并没有安装乌龟，直接使用eclipse检出的
http://code.taobao.org/svn/taobao-pamirs-proxycache/trunk svn地址
这里不得的不吐槽下taobao，为嘛不好好的用UTF-8非要用GBK。。好吧转吧，还好网上有批量装换的小工具。转换完了，直接把src文件夹替换吧。
进入检出的目录下把pom.xml中的
<parent>
<groupId>com.taobao</groupId>
<artifactId>parent</artifactId>
<version>1.0.2</version>
</parent>
给注释起来。
试着编译一下吧。
mvn clean install -Dmaven.test.skip=true
不成功，报错了，这是因为它依赖了一个tair-client项目，而我们中央仓库是没有的。
怎么办，又去找tair-clitn项目吧 svn地址http://code.taobao.org/svn/tair-client-java/trunk
我检的主分支2.4 直接检出成eclipse中的项目了。
先看一下编码，utf-8 不用转，yes！！
直接编译吧 mvn clean install -Dmaven.test.skip=true
OK 成功了，
下面将我们proxycace中的tair-client 改成刚刚编译和install了tair-client的版本。
在运行安装 mvn clean install -Dmaven.test.skip=true
没有错了，成功编译安装，

三加入项目中

http://code.taobao.org/p/taobao-pamirs-proxycache/wiki/index/
照着做就好了比较方便简单。

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

浅谈淘宝类目属性体系：商品搜索背后的逻辑架构

Sat, 07 Jun 2014 11:13:13 CST

[核心提示] 淘宝拥有百万家商户和超过10亿的商品数，它如何让用户精准地找到想要的商品呢？其背后有着强大的技术支撑。

淘宝目前在线商品数超过 10 亿，如何精准的帮助用户找到他想要的商品呢？经过多年的探索，淘宝通过建立一套完整的类目属性体系，终于较好的解决了这一问题，今天就跟大家一起来谈谈淘宝的类目属性体系。

一点点历史和架构

2003 年淘宝刚上线时，商品量很少，没有分类。后来，商品量上百，开始有了对商品进行单级分类，有点类似于现在的一级行业类目。

等到商品上万的时候，商品的单级分类已经不能满足需求，开始有了多级分类，就是一颗类目树了。从 06 年开始引入了属性，商家按照属性模板填写属性，用户可以按照属性筛选商品。

到了 08 年，开始将前后台类目分开，用户根据前台类目筛选商品，商家将商品挂到后台类目上，前后台类目树之间建立好映射。

今天的淘宝类目属性体系主要由后台类目树、前台类目树、挂载在后来叶子类目上的商品属性模板以及管理前后台类目之间映射关系的类目管理平台组成，整体架构如下：

从图中可以看出，淘宝类目属性体系是一个非常基础的数据服务，在商品发布页上商家选择后台类目上传商品信息，详情页上以面包屑的方式给用户显示商品所属的前台类目，在搜索结果页上让用户根据前台类目筛选商品。运营同学可以通过一个管理后台来管理前后台类目之间的映射关系以及后台类目的属性模板。

后台类目

后台类目面向商家，主要用于商品的分类和属性管理。商家上传商品时见到的就是后台类目，如下图：

后台类目有如下特点：

后台类目树中最重要的是叶子类目，也就是类目树上不能再往下分的类目,任何商品都必须挂载到后台叶子类目上。
叶子类目挂载属性模版，商家发布商品时选择好类目之后会根据属性模版，补充必填的商品属性信息，方可成功上传商品。
后台类目相对稳定，不能随便删除，叶子类目不能重复。

前台类目

前台分类面向用户，方便用户筛选查找商品，大部分时候用户见到的类目都是前台类目。下图就是淘宝搜索结果页上的淘宝前台类目树：

前台类目有如下特点：

用户购买时看到的类目是前台类目。
前台类目通过跟后台映射间接和商品关联。
前台类目由后台叶子类目+属性组成，一个前台类目可以包含多个后台类目，一个后台类目也可以映射给多个前台类目。
前台类目不直接挂载属性模版，前台类目对应的属性来自后台叶子类目的公共属性。
前台类目很灵活，可重叠，可删除。

为什么要将前后台类目分开呢？

介绍完淘宝的类目属性体系，或许你会问为啥要将前台类目和后台类目分开呢？直接用一套类目体系不就行了吗？这里我就给大家解释一下原因，到了 08 年，淘宝商品日益增多，类目层级也越来越深，买家越来越难找到想要的商品。淘宝的小二们就开始不断调整类目属性，把类目树变浅，让商品更容易被买家找到。只有一套类目体系的情况下，小二每次调整，卖家也必须跟着调整。如果只是改一次，卖家也能勉强接受，但这是周期性的。比如，在夏天服装这个类目下可能是连衣裙、衬衫等夏装，到了冬天就会变成打底裤、羽绒服等冬装了，而且卖家也都知道这些调整时合理的，但是一年到头这么调整，意味着他一年到头都在编辑类目，可能还得专门养个把人在那里，一天到晚改类目，无形中卖家的运营成本也就提高了。

08 年的时候，有个淘宝的产品经理从线下零售巨头沃尔玛得到启发，他发现沃尔玛仓库里面的类目分区和货架区的类目分区是分离的，仓库里面的类目分区比较稳定，很少变化，而货架区的类目分区会根据活动和季节经常调整。类似的，淘宝也可以把原来的一套类目体系分为后台分类和前台分类，后台分类面向商家，用来挂载商品和属性模板，比较稳定很少变化；前台分类面向用户，主要方便用户查找商品，很灵活，可以经常调整。后台类目和前台类目之间通过映射联系起来，一个后台类目可以映射到多个前台类目，一个前台类目也可以包含多个后台类目。

从技术的角度来看的话，前台类目就是在后台类目的基础上建立了一个虚拟类目。

类目属性体系在搜索上的应用

先来看看类目属性体系是怎么帮助提升搜索的精准度的，下图是说明了用户 query 到商品搜索结果的全过程：

用户输入 query：iPhone，淘宝类目属性体系预测到跟这个 query 最相关的前台类目是手机，然后前台类目通过映射找到后台类目手机，最终在这个类目下找到了“iPhone 5s 土豪金”这个商品。

有了类目属性体系，用户搜索 iPhone，淘宝就不会给出手机套这样的配件了，因为它只会到手机类目下去找商品。

有了类目属性体系，用户可以直接在搜索结果页按照类目和属性筛选商品，更加高效的找到想要的商品。而淘宝搜索可以通过记录用户搜索 query 之后的类目属性筛选行为，精准预测每一个 query 的类目和属性意图，当用户再次搜索的时候，可以根据 query 的类目属性意图，在 query 文本相关性的基础上计算出商品的类目和属性相关性，把包含 query，且跟用户的类目和属性意图最相关的商品优先展示给用户。这也是百度这样的通用搜索引擎所做不到的，因为它没有类目属性体系。

有了类目属性体系，还可以做好搜索算法的垂直化优化。也就是在每一个细分类目下，可以采用不同的商家权重和品牌权重，甚至可以有不同的排序公式。比如用户选择手机时，更多考虑各项参数和评测文章，这个时候相应的排序权重因子可以加强，而选择服装的时候，一张漂亮的主图就无比重要了，排序因子里面主图质量的权重就需要提升了。有了类目属性体系，还可以做基于类目和属性的个性化搜索。搜索引擎通过用户的类目属性筛选日志，可以挖掘出用户的一些特征，比如性别，意向价格区间，偏好品牌，偏好品类等，从而可以对这个用户做个性化的展示。

类目属性体系无处不在

除了电商，其实在各个需要帮助快速查找信息领域都可以见到类目属性体系的身影。比如：教育行业里面的课程分类，医疗行业的疾病和医院分类。当我们把用户查找的信息看做一个个实体的时候，对实体分类以帮助快速定位查找就是一个非常通用的方法。从这个角度来讲，Google 的 Knowledge Graph 可以看做是将电商网站里面的商品类目属性体系推广到了整个世界中的万事万物，它试图使用一套统一的类目属性网来囊括所有的实体，或许这就是通用搜索引擎的类目属性体系吧。

本文为作者葛灿辉（ @葛灿辉-搜索数据挖掘）投稿发布，转载请注明出处并附带本文链接

（关注更多人人都是产品经理观点，参与微信互动（微信搜索“人人都是产品经理”或“woshipm”）

剖析淘宝TDDL——Matrix层的分库分表配置与实现

Wed, 05 Nov 2014 15:08:46 CST

剖析淘宝 TDDL （ TAOBAO DISTRIBUTE DATA LAYER ）

注：本文部分内容引用 本人博客 http://gao-xianglong.iteye.com/blog/1973591

前言

在开始讲解淘宝的TDDL(Taobao Distribute Data Layer)技术之前，请允许笔者先吐槽一番。首先要开喷的是淘宝的社区支持做的无比的烂，TaoCode开源社区上面，几乎从来都是有人提问，无人响应。再者版本迭代速度也同样差强人意， 就目前而言 TDDL5.0 的版本已经全线开源（Group、Atom、Matrix）大家可以在Github上下载源码。

一、互联网当下的数据库拆分过程

二、 TDDL 的架构原型

三、下载 TDDL 的 Atom 层和 Group 层源代码

四、 Diamond 简介

五、 Diamond 的安装和使用

六、动态数据源层的 Master/Salve 读写分离 配置与实现

七、 Matrix 层的分库分表配置与实现（ 此章节由于特殊原因暂时隐藏）

一、互联网当下的数据库拆分过程

对于一个刚上线的互联网项目来说，由于前期活跃用户数量并不多，并发量也相对较小，所以此时企业一般都会选择将所有数据存放在 一个数据库中进行访问操作。但随着后续的市场推广力度不断加强，用户数量和并发量不断上升，这时如果仅靠一个数据库来支撑所有访问压力，几乎是在 自寻死路。所以一旦到了这个阶段，大部分Mysql DBA就会将数据库设置成 读写分离状态，也就是一个Master节点对应多个Salve节点。经过Master/Salve模式的设计后，完全可以应付单一数据库无法承受的负载压力，并将访问操作分摊至多个Salve节点上，实现真正意义上的读写分离。但大家有没有想过，单一的Master/Salve模式又能抗得了多久呢？如果用户数量和并发量出现量级上升，单一的Master/Salve模式照样抗不了多久，毕竟一个Master节点的负载还是相对比较高的。为了解决这个难题，Mysql DBA会在单一的Master/Salve模式的基础之上进行数据库的 垂直分区（分库）。所谓垂直分区指的是可以根据业务自身的不同，将原本冗余在一个数据库内的业务表拆散，将数据分别存储在不同的数据库中，同时仍然保持Master/Salve模式。经过垂直分区后的Master/Salve模式完全可以承受住难以想象的高并发访问操作，但是否可以永远 高枕无忧了？答案是否定的，一旦业务表中的数据量大了，从维护和性能角度来看，无论是任何的CRUD操作，对于数据库而言都是一件极其耗费资源的事情。即便设置了索引， 仍然无法掩盖因为数据量过大从而导致的数据库性能下降的事实，因此这个时候Mysql DBA或许就该对数据库进行 水平分区（分表，sharding），所谓水平分区指的是将一个业务表拆分成多个子表，比如user_table0、user_table1、user_table2。子表之间通过某种契约关联在一起，每一张子表均按段位进行数据存储，比如user_table0存储1-10000的数据，而user_table1存储10001-20000的数据，最后user_table3存储20001-30000的数据。经过水平分区设置后的业务表，必然能够将原本一张表维护的海量数据分配给N个子表进行存储和维护，这样的设计在国内一流的互联网企业比较常见，如图1-1所示：

图1-1 水平分区

上述笔者简单的讲解了数据库的分库分表原理。接下来请大家认真思考下。原本一个数据库能够完成的访问操作，现在如果按照分库分表模式设计后，将会显得非常麻烦，这种麻烦尤其体现在 访问操作上。因为持久层需要判断出对应的数据源，以及数据源上的水平分区，这种访问方式我们称之为访问“ 路由”。按照常理来说，持久层不应该负责数据访问层(DAL)的工作，它应该只关心one to one的操作形式，所以淘宝的TDDL框架诞生也就顺其自然了。

二、 TDDL 的架构原型

淘宝根据自身业务需求研发了TDDL（Taobao Distributed Data Layer）框架，主要用于解决 分库分表场景下的访问路由（持久层与数据访问层的配合）以及异构数据库之间的数据同步，它是一个基于集中式配置的JDBC DataSource实现，具有分库分表、Master/Salve、动态数据源配置等功能。

就目前而言，许多大厂也在出一些更加优秀和社区支持更广泛的DAL层产品，比如Hibernate Shards、Ibatis-Sharding等。如果你要问笔者还为什么还要对TDDL进行讲解，那么笔者只能很无奈的表示公司要这么干，因为很多时候技术选型并不是笔者说了算，而是客户说了算。当笔者费劲所有努力在google上寻找TDDL的相关使用说明和介绍时，心里一股莫名的火已经开始在蔓延，对于更新缓慢（差不多一年没更新过SVN），几乎没社区支持（提问从不响应）的产品来说，除了蜗居在企业内部，必定走不了多远，最后的结局注定是悲哀的。好了，既然抱怨了一番，无论如何还是要坚持讲解完。TDDL位于数据库和持久层之间，它直接与数据库建立交道，如图1-2所示：

图1-2 TDDL所处领域模型定位

传说淘宝很早以前就已经对数据进行过分库分表处理，应用层连接多个数据源，中间有一个叫做DBRoute的技术对数据库进行统一的路由访问。DBRoute对数据进行多库的操作、数据的整合，让应用层像操作一个数据源一样操作多个数据库。但是随着数据量的增长，对于库表的分法有了更高的要求，例如，你的商品数据到了百亿级别的时候，任何一个库都无法存放了，于是分成2个、4个、8个、16个、32个……直到1024个、2048个。好，分成这么多，数据能够存放了，那怎么查询它？这时候，数据查询的中间件就要能够承担这个重任了，它对上层来说，必须像查询一个数据库一样来查询数据，还要像查询一个数据库一样快（每条查询要求在几毫秒内完成），TDDL就承担了这样一个工作（其他DAL产品做得更好），如图1-3所示：

图1-3 TDDL分库分表查询策略

上述笔者描述了TDDL在分库分表环境下的查询策略，那么接下来笔者有必要从淘宝官方copy它们自己对TDDL优点的一些描述，真实性不敢保证，毕竟没完全开源，和社区零支持，大家看一看就算了，别认真。

淘宝人自定的TDDL优点：

1 、数据库主备和动态切换；
2 、带权重的读写分离；
3 、单线程读重试；
4 、集中式数据源信息管理和动态变更；
5 、剥离的稳定 jboss 数据源；
6 、支持 mysql 和 oracle 数据库；
7 、基于 jdbc 规范，很容易扩展支持实现 jdbc 规范的数据源；
8 、无 server,client-jar 形式存在，应用直连数据库；
9 、读写次数 , 并发度流程控制，动态变更；
10 、可分析的日志打印 , 日志流控，动态变更；

注意：

TDDL必须要依赖diamond配置中心（diamond是淘宝内部使用的一个管理持久配置的系统，目前淘宝内部绝大多数系统的配置）。

接下来，笔者将会带领各位一起分析TDDL的体系架构。TDDL其实主要可以划分为3层架构，分别是Matrix层、Group层和Atom层。Matrix层用于实现分库分表逻辑，底层持有多个Group实例。而Group层和Atom共同组成了动态数据源，Group层实现了数据库的Master/Salve模式的写分离逻辑，底层持有多个Atom实例。最后Atom层(TAtomDataSource)实现数据库ip,port,password,connectionProperties等信息的动态推送,以及持有原子的数据源分离的JBOSS数据源）。

图1-4 TDDL体系结构

章节的最后，我们还需要对TDDL的原理进行一次剖析。因为我们知道持久层只关心对数据源的CRUD操作，而多数据源的访问，并不应该由它来关心。也就是说TDDL透明给持久层的数据源接口应该是统一且“单一”的，至于数据库到底如何分库分表，持久层无需知道，也无需编写对应的SQL去实行应对策略。这个时候对TDDL一些疑问就出现了，TDDL需要对SQL进行二次解析和拼装吗？答案是不解析仅拼装。说白了TDDL只需要从持久层拿到发出的SQL

再按照一些分库分表条件，进行特定的SQL扩充以此满足访问路路由操作。

以下是淘宝团队对 TDDL 的官方原理解释：

1、TDDL除了拿到分库分表条件外，还需要拿到order by、group by、limit、join等信息，SUM、

MAX、MIN等聚合函数信息，DISTINCT信息。具有这些关键字的SQL将会在单库和多库情况下进行,语义是不同的。TDDL必须对使用这些关键字的SQL返回的结果做出合适的处理；

2、TDDL行复制需要重新拼写SQL,带上sync_version字段；

3、不通过sql解析,因为TDDL遵守JDBC规范,它不可能去扩充JDBC规范里面的接口,所以只能通过SQL中加额外的字符条件(也就是HINT方式)或者ThreadLocal方式进行传递,前者使SQL过长,后者难以维护,开发debug时不容易跟踪,而且需要判定是在一条SQL执行后失效还是1个连接关闭后才失效；

4、TDDL现在也同时支持Hint方式和ThreadLocal方式传递这些信息；

三、下载 TDDL 的 Atom 层和 Group 层源代码

前面我们谈及了TDDL的动态数据源主要由2部分构成，分别是Atom和Group。Group用于实现数据库的Master/Salve模式的写分离逻辑，而Atom层则是持有数据源。非常遗憾的TDDL中还有一层叫做Matrix，该层是整个TDDL最为核心的地方，淘宝也并没有对这一层实现开源，而Matrix层主要是建立在动态数据源之上的分库分表实现。换句话说，TDDL是基于模块化结构的，开发人员可以选用TDDL中的部分子集。

大家可以从淘宝的TaoCode上下载TDDL的源码带，然后进行构件的打包。TDDL的项目主要是基于Maven进行管理的，所以建议大家如果不了解Maven的使用，还是参考下笔者的博文《Use Maven3.x》。

大家下载好TDDL的源代码后，通过IDE工具导入进来后可以发现，开源的TDDL的工程结构有如下几部份组成：

tddl-all –

—tbdatasource

—tddl-atom-datasource

—tddl-common

—tddl-group-datasource

—tddl-interact

—tddl-sample

大家可以使用Maven的命令“mvn package“将TDDL的源代码打包成构件。如果你的电脑上并没有安装Maven的插件到不是没有办法实现构件打包，你可以使用eclipse的导出命令，将源代码导出成构件形式也可以。

四、 Diamond 简介

使用任何一种框架都需要配置一些配置源信息，毕竟每一种框架都有自己的规范，使用者务必遵守这些规范来实现自己的业务与基础框架的整合。自然TDDL也不例外，也是有配置信息需要显式的进行配置，在TDDL中，配置可以基于2种方式，一种是基于本地配置文件的形式，另外一种则是基于Diamond的形式进行配置，在实际开发过程中，由于考虑到配置信息的集中管理所带来的好处，大部分开发人员愿意选择将TDDL的配置信息托管给Diamond，所以本文还是以Diamond作为TDDL的配置源。

diamond是淘宝内部使用的一个管理持久配置的系统，它的特点是简单、可靠、易用，目前淘宝内部绝大多数系统的配置，由diamond来进行统一管理。diamond为应用系统提供了获取配置的服务，应用不仅可以在启动时从diamond获取相关的配置，而且可以在运行中对配置数据的变化进行感知并获取变化后的配置数据。

五、 Diamond 的安装和使用

Diamond和TDDL不同，它已经实现了完全意义上的开源。大家可以从淘宝的TaoCode

上下载Diamond的源代码，SVN下载地址为 http://code.taobao.org/svn/diamond/trunk。当大家成功下载好Diamond的源代码后，我们接下来就需要开始Diamond的环境搭建工作。

首先我们需要安装好Mysql数据库，以root用户登录，建立用户并赋予权限，建立数据库，然后建表，语句分别如下：

create database diamond;

grant all on diamond.* to zh@’%’ identified by ‘abc’;

use diamond

create table config_info (

‘id’ bigint(64) unsigned NOT NULL auto_increment,

‘data_id’ varchar(255) NOT NULL default ’ ’,

‘group_id’ varchar(128) NOT NULL default ’ ’,

‘content’ longtext NOT NULL,

‘md5′ varchar(32) NOT NULL default ’’,

‘gmt_create’ datetime NOT NULL default ’2010-05-05 00:00:00′,

‘gmt_modified’ datetime NOT NULL default ’2010-05-05 00:00:00′,

PRIMARY KEY (‘id’),

UNIQUE KEY ‘uk_config_datagroup’ (‘data_id’,'group_id’));

完成后，请将数据库的配置信息（IP，用户名，密码）添加到diamond-server工程的src/resources/jdbc.properties文件中的db.url，db.user，db.password属性上面，这里建立的库名，用户名和密码，必须和jdbc.properties中对应的属性相同。

tomcat是Damond的运行容器，在diamond-server源代码根目录下，执行mvn clean package -Dmaven.test.skip，成功后会在diamond-server/target目录下生成diamond-server.war。打包完成后，将diamond-server.war放在tomcat的webapps目录下。最后启动tomcat，即启动了Diamond。

http server用来存放diamond server等地址列表，可以选用任何http server，这里以tomcat为例。一般来讲，http server和diamond server是部署在不同机器上的，这里简单起见，将二者部署在同一个机器下的同一个tomcat的同一个应用中，注意，如果部署在不同的tomcat中，端口号一定是8080，不能修改（所以必须部署在不同的机器上）。

在tomcat的webapps中的diamond-server中建立文件diamond，文件内容是diamond-server的地址列表，一行一个地址，地址为IP，例如127.0.0.1，完成这些步骤后，就等于已经完成Diamond的安装。

六、动态数据源层的 Master/Salve 读写分离 配置与实现

其实使用TDDL并不复杂，只要你会使用JDBC，那么TDDL对于你来说无非就只需要将JDBC的操作连接替换为TDDL的操作连接，剩余操作一模一样。并且由于TDDL遵循了JDBC规范，所以你完全还可以使用Spring JDBC、Hibernate等第三方持久层框架进行ORM操作。

我们来看看如何TDDL中配置TDDL的读写分离，Atom+Group组成了TDDL的动态数据源，这2层主要负责数据库的读写分离。

TGroupDataSource 的配置

1、 配置读写分离权重：

KEY：com.taobao.tddl.jdbc.group_V2.4.1_“groupKey”(Matrix中为“dbKey”)

VALUE：dbKey:r10w0,dbKey2:r0w10

TAtomDataSource 的配置（由 3 部分组成， global 、 app 、 user ）

1、 基本数据源信息 (global) ：

KEY：com.taobao.tddl.atom.global.“dbKey”

VALUE：（

ip=数据库IP

port=数据库端口

dbName=数据库昵称

dbType=数据库类型

dbStatus=RW）

2、 数据库密码信息 (user) ：

KEY：com.taobao.tddl.atom.passwd.“dbName”.“dbType”.“dbUserName”

VALUE：数据库密码

3、 数据库连接信息（ app ，如果不配置时间单位，缺省为分钟）：

KEY：com.taobao.tddl.atom.app.“appName”.“dbKey”

VALUE：（

userName=数据库用户

minPoolSize=最小连接数

maxPoolSize=最大连接数

idleTimeout=连接的最大空闲时间

blockingTimeout=等待连接的最大时间

checkValidConnectionSQL=select 1

connectionProperties=rewriteBatchedStatements=true&characterEncoding=UTF8&connectTimeout=1000&autoReconnect=true&socketTimeout=12000）

应用层使用 TDDL 示例：

public class UseTDDL {

private static final String APPNAME = "tddl_test";

private static final String GROUP_KEY = "tddltest";

private static TGroupDataSource tGroupDataSource;

/* 初始化动态数据源 */

static {

tGroupDataSource = new TGroupDataSource();

tGroupDataSource.setAppName( APPNAME);

tGroupDataSource.setDbGroupKey( GROUP_KEY);

tGroupDataSource.init();

}

@Test

public void testQuery() {

final String LOAD_USER = "SELECT userName FROM tddl_table WHERE userName=?";

Connection conn = null;

PreparedStatement pstmt = null;

ResultSet rs = null;

try {

conn = tGroupDataSource.getConnection();

pstmt = conn.prepareStatement(LOAD_USER);

pstmt.setString(1, "tddl-test2");

rs = pstmt.executeQuery();

while (rs.next())

System. out.println("data: " + rs.getString(1));

} catch (Exception e) {

e.printStackTrace();

} finally {

try {

if ( null != rs)

rs.close();

if ( null != pstmt)

pstmt.close();

if ( null != conn)

conn.close();

} catch (Exception e) {

e.printStackTrace();

}

七、 Matrix 层的分库分表配置与实现

在上一章节中，笔者演示了如何在Diamond中配置数据库的读写分离，那么本章笔者则会演示如果配置TDDL的分库分表。

TDDL的Matrix层是建立在动态数据源之上的，所以分库分表的配置和读写分离的基本配置也是一样的，只不过我们需要新添加dbgroups和shardrule项。dbgroups项包含了我们所需要配置的所有AppName选项，而shardrule则是具体的分库分表规则。这里有一点需要提醒各位，在开源版本的TDDL中，配置 TGroupDataSource读写分离是使用dbKey，然而在Matrix中则是使用appName。

1、配置Group组：

KEY：com.taobao.tddl.v1_“appName”_dbgroups

VALUE：appName1，appName2

2、配置分库分表规则：

KEY：com.taobao.tddl.v1_”appName”_shardrule

VALUE：（

<?xml version="1.0" encoding="gb2312"?>

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

</bean>

<map>

</map>

</property>

</bean>

<bean id="tddl_table" init-method="init"

class="com.taobao.tddl.common.config.beans.TableRule">

<!--分表规则,需要注意的是，因为taobao目前dba的要求是所有库内的表名必须完全不同，因此这里多加了一个映射的关系

简单来说，分表规则只会算表的key.

俩库4表: db1(tab1+tab2) db2(tab3+tab4)

db1 == key: 0 value tab1

key: 1 value tab2

db2 == key: 0 value tab3

key: 1 value tab4

-->

</bean>

</beans>

）

TDDL的分库分表配置形式完全是采用Spring的配置形式，这一点大家应该是非常熟悉的。那么接下来我们一步一步的分析TDDL的分库分表规则。

在元素<map/>中我们可以定义我们所需要的分表，也就是说，当有多个表需要实现分表逻辑的时候，我们可以在集合中进行定义。当然我们还需要外部引用<bean/>标签中定义的具体的表逻辑的分库分表规则。

在分库分表规则中，我们需要定义数据库组index号，也就是说我们需要定义我们有多少的appNames，接下来我们就可以定义分库和分表规则了。TDDL的分库分表规则完全是采用取余方式，比如<property name="dbRuleArray" value="(#id#.longValue() % 4).intdiv(2)"/>，value属性中包含有具体的分库规则，其中“#id#”作为我们的分库分表条件，此值在数据库中对应的类型必须是整类，然后进行取余后再进行intdiv。或许有些朋友看不太明白这个是什么意思，我们用简单的一点的话来说就是，“#id#.longValue() % 4).intdiv(2)”的含义是我们需要分2个库和4个表，那么我们怎么知道我们的数据到底落盘到哪一个库呢？打个比方，如果我们的id等于10，首先10%4等于2，然后2/2等于1，TDDL分库规则下标从0开始，那么我们的数据就是落盘到第2个库。

当大家明白TDDL的分库规则后，我们接下来再来分析分表规则<property name="tbRuleArray" value="#id#.longValue() % 4 % 2"/>。和分库规则类似的是，我们都采用取余算法首先进行运算，只不过分表尾运算也是使用取余，而不是除算。打个比方，如果我们的id等于10，首先10%4等于2，然后2%2等于0，那么我们的数据就是落盘到第2个库的第1张表。

应用层使用TDDL示例：

public class UseTDDL {

private static final String APPNAME = "tddl_test";

private static final TDataSource dataSource;

/* 初始化动态数据源 */

static {

dataSource = new TDataSource();

dataSource.setAppName( APPNAME);

dataSource.setUseLocalConfig( false);

dataSource.setDynamicRule( false);

dataSource.init();

}

@Test

public void query() {

final String LOAD_USER = "SELECT userName FROM tddl_table WHERE id = ?";

Connection conn = null;

PreparedStatement pstmt = null;

ResultSet rs = null;

try {

conn = dataSource.getConnection();

pstmt = conn.prepareStatement(LOAD_USER);

pstmt.setLong(1, 3);

rs = pstmt.executeQuery();

while (rs.next())

System. out.println("data: " + rs.getString(1));

} catch (Exception e) {

e.printStackTrace();

} finally {

try {

if ( null != rs)

rs.close();

if ( null != pstmt)

pstmt.close();

if ( null != conn)

conn.close();

} catch (Exception e) {

e.printStackTrace();

}

@Test

public void insert() {

final String LOAD_USER = "insert into tddl_table values(?, ?)";

Connection conn = null;

PreparedStatement pstmt = null;

try {

conn = dataSource.getConnection();

pstmt = conn.prepareStatement(LOAD_USER);

pstmt.setLong(1, 10);

pstmt.setString(2, "JohnGao");

pstmt.execute();

System. out.println("insert success...");

} catch (Exception e) {

e.printStackTrace();

} finally {

try {

if ( null != pstmt)

pstmt.close();

if ( null != conn)

conn.close();

} catch (Exception e) {

e.printStackTrace();

}

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

淘宝十年技术路 - 内向爆裂

Mon, 13 Oct 2014 20:39:00 CST

　　最近有幸，在学校的图书馆借到了子柳先生的《淘宝技术这十年》，拜读一番，感慨万分。将书中内容加上自己的想法与诸君分享，毕竟未经人事看法粗浅，希望能得到园子里前辈们的指点~

一、淘宝的核心技术（国内乃至国际的Top，这还是2011年的数据）

拥有全国最大的分布式Hadoop集群（云梯，2000左右节点，24000核CPU，48000GB内存，40PB存储容量）
全国分布80+CDN节点，能够自动找寻最近的节点提供服务，支持流量超过800Gbps，足以拖垮一个城市的流量
不逊于百度的搜索引擎，对数十亿商品进行搜索，全球最大的电商平台
顶尖的负载均衡系统，顶尖的分布式系统，顶尖的互联网思想，功能多样运行极其稳定
丰富的生态产业以及先进的数据挖掘技术
......很多很多

二、淘宝网的诞生

　　马总在2003年4月7日秘密叫来阿里巴巴的十位员工，来到杭州一个隐秘的毛坯房，要求他们在一个月左右的时间内做出一个C2C网站。

　　结果当然还是直接买的快，一个基于LAMP架构的网站，原名是PHPAuction，老美开发的一个拍卖网站。当然必须要做修改才能用。（作为一个曾经用老美开发的前端页面开发自己博客的同学，确实感觉用别人写的比较方便偷懒-_-，不过我确信虚竹、三丰、多隆等前辈是有足够实力开发自己网站的——还是马总催的紧）

　　当时财大气粗的eBay正在中国耀武扬威，加上SARS肆虐，可能大家对网购产生了新的认识。而淘宝刻意保持低调，甚至连阿里的员工都不知道这是他们自己公司的产品。

　　淘宝的员工积极回答着用户的问题，早起贪黑，锻炼身体的方法就是倒立。

　　淘宝的功能也在不断的完善着，发布、管理、搜索、详情、购买等等，服务器也变成了三台。因为数据量大了，淘宝的搜索很慢（使用LIKE匹配...），多隆前辈把阿里巴巴的搜索引擎iSearch搬了过来。

　　当时MySQL的默认存储引擎MyISAM会导致读写锁等待时间过长等等大量问题，所以意外还是很多的。

　　 2003年底，淘宝注册用户23万，PV 31万/day，半年成交额3371万。

三、淘宝的更新

　　很显然MySQL无法撑得起如此大的访问量，数据库瓶颈出现了。幸好阿里的DBA队伍足够强大，他们使用Oracle替代了MySQL。

　　Oracle那时就已经有了强大的并发性访问设计——连接池，从连接池取连接的耗费比单独建立连接少很多。但是PHP当时并没有官方提供支持语言连接池特性，于是多隆前辈用Google（不会是Baidu）搜到了一个开源的SQL Relay，于是数据库软件方面的瓶颈暂时解决了。

　　但是硬件容量不够了，阿里买了NAS（后来因为延迟严重原因买了EMC的SAN低端存储），加上Oracle高性能RAC，硬件容量也暂时没问题了。

　　开源的东西固然好，但是大胆使用也是一次尝试的过程，SQL Relay会频繁的导致死锁问题，导致工程师不得不定期进行重启服务，从书中的描述可以看出，淘宝的工程师们真的非常辛苦。

　　淘宝网不会止步于仅仅为卖家和买家提供一个交易的网站而已，还需要建立一个完善的第三方体系，来保证卖家和买家之间的交易是安全的，于是支付宝诞生了。比较麻烦的是，当时虽有很多银行开放了网银接口，但是甚至不能保证付钱后就会扣款成功，还是需要工程师们辛苦的一板一眼去对账......

　　淘宝为了便于用户的交流，开发了一个IM软件——旺旺，不仅给买卖双方使用，阿里内部也使用旺旺交流。

四、第一个里程碑

　　因为SQL Relay的问题实在过于严重，2004年于是淘宝终于做出了跨时代的决策——使用Java重写网站（鼓掌~~~）。

　　没错，淘宝请了Sun的高级工程师来帮忙做Java架构。那么他们是如何做到修改编程语言而不改变网站使用呢——模块化替换，今天写好了A模块，另开一个新域名，将连接指向该模块，同时别的模块不变，等到全部模块完成的时候，原域名放弃。

　　使用的框架：淘宝的架构师在Jakarta Turbine的基础上开发了自己的MVC框架——WebX。而Sun公司坚持使用EJB作为控制层（估计当时只有他们才能玩贯EJB），加上使用iBatis作为持久层，一个可扩展且高效的Java EE应用诞生了。BYW，支付宝也是Sun的工程师用同样的架构设计的。

　　送走Sun的大牛们之后，阿里的数据存储又遇到了瓶颈，于是忍痛买了一台IBM小型机（我猜至少是百万级别的.......），也就有了IOE（IBM + Oracle + EMC）这样的传说。

　　 2004年底，淘宝注册用户400万，PV 4000万/day，全网成交额10个亿。

五、再接再厉

　　Oracle也有处理上限，当数量的级别是“亿”的时候，就不是一个Oracle服务器支撑的起的了。DBA们把数据分到了两个数据库中，通过ID的第一位决定查询哪一个数据。比如，‘0’至‘7’放在A数据库，‘8’至‘f’放在B数据库，通用信息放在C数据库。但是如何既查询'3'开头又查询'e'开头的数据呢？一个数据库路由框架DBRoute由架构师行癫编写，统一处理合并问题而对上层透明。

　　Spring诞生了，早闻Spring框架在Web应用不可或缺，而在淘宝网，Spring也达到了Rod Johnson设计它的目的——替代EJB。

　　 2005年底，淘宝注册用户1390万，PV 8931万/day，商品数目1663万个。

　　说实话我真的好佩服，这么大的访问量都能如此坚挺，但是，考虑到未来的发展，这样的设施架构只是勉强可以应付现在的要求。于是，CDN技术派上用场了，一开始使用商用的ChinaCache，后来使用章文嵩博士搭建低耗能CDN网络，淘宝网的性能越来越好了。

　　 2006年底，淘宝注册用户3000万，PV 15000万/day，商品数目5000万，全网成交额169亿元。

六、创造技术

　　为了考虑交易的公平性，淘宝增加了交易快照功能，将当前交易网页以图片的形式保存下来，淘宝的交易量如此之大，带来了一个问题——碎片图片过多，2010年，淘宝网的后端上保存着286亿张图片。

　　淘宝在2007年之前，使用NetApp的商用存储系统，但是仍然不够应付迅速增长的趋势。同年Google公布了GFS的设计思想，参照它的思想，淘宝也开发了自己的文件系统——TFS。至于这个文件系统的具体原理书上给的并不详细（应该是我看不懂-_-），不过可以大概可以了解是专门为大量的图片设计的，从每个用户1张图片到TFS上线后5张再到1GB的图片空间，这些都得益于TFS集群的文件存储系统以及大量的图片服务器。淘宝使用实时生成缩率图，全局负载均衡以及一级和二级缓存来保证图片的访问优化与高效访问。

　　淘宝的服务器软件使用Tengine，一个被优化过的nginx模块。

　　淘宝也做过失败的产品，不是因为技术原因而是市场原因。首先是“团购”，失败在于人心叵测。再次是“我的淘宝”，使用了风靡全球的AJAX的技术，但是做的过于AJAX了，可能是太不容易上手了（马总亲口说的），还有“招财进宝”（被竞争对手认为是破坏了“免费”的承诺而大肆宣扬）。

　　记录商品的访问量，使用传统的数据库I/O实在过于影响效率，所以淘宝使用了缓冲的技术，先是使用ESI（Edge Side Includes）,解决了片段缓冲问题。因为有些大店铺访问量过大，频繁的I/O实在得不偿失，于是多隆前辈写出了TBstore，可以缓存大量的数据，核心思想是使用Hash算法快速寻找。其核心是基于Berkeley DB，一种类内存数据库，导致的问题是内存数据量大了还是会刷到磁盘中，因此性能并不是那么的好。

　　后来，淘宝分离出了UIC（User Information Center），供所有模块调用。多隆前辈再次为其编写出了TDBM，完全是基于内存的数据缓存（参考了memcached）。再然后，淘宝将TBstore和TDBM合并，写出了Tair，一个基于Key-Value的分布式缓存数据系统。然后升级了自己的iSearch系统。

　　 2007年底，淘宝注册用户5000万，PV 25000万/day，商品数目1个亿，全网成交额433亿元。

七、更多的技术

　　一个电子商务平台不可缺少的细节——商品类目的处理。因为商品的类目实在过于庞大，因此如何根据类目划分商品成为了难题。机智的一灯前辈说，这些属性可以当做标签，直接“贴”在商品上（应该是这样的吧）。

　　2008年，淘宝将支付宝单独分离出来。其中交易的底层业务叫交易中心TC（Trade Center），涉及订单之类的原子操作。交易的上层业务叫做交易管理TM（Trade Manager），不涉及对物流的操作。

　　于是，应运而生的，第二个堪称里程碑的项目——系统拆分诞生了。这个正是我们在阿里圆桌会议上HR所说一位元老级员工做的——“给一架高速飞行的飞机换发动机”这么惊险的重构任务。这些组件分割难度非常之大，以至于那张复杂的逻辑图我实在看不懂......总之，淘宝中间件诞生了。

　　HSF（高性能服务框架）：核心，外号好舒服。请参见作者的博文http://www.blogjava.net/BlueDavy/archive/2008/01/24/177533.html

　　Notify（消息中间件）：淘宝自主开发的消息队列产品。支撑了10亿+的消息通知。

　　TDDL（分布式数据访问层）：优化了DBRoute，在JDBC和DB之间隔了一层，负责数据库的优化工作。

　　Tbsession：因为Session保存在服务器中，但是用户可能会被动的频繁的切换服务器，淘宝的设计思路是将Session信息保存在Cookie中，最后使用Tair来保存。

　　阿里的开放平台也相当有历史，有兴趣的可以参观参观 http://open.taobao.com/index.htm

八、总结

　　当你处于业界中流时，你可以向老大学习，等当你成为业界老大之后，你就需要不断超越自己，用自己的力量来改变整个行业，乃至整个世界。无论是华为，还是阿里，当成为业内的Top时，责任反而更加重大。

　　一直觉得自己想着随大流，但是却又心有不甘。如今有机会能进入全中国最好的互联网网站，一直为自己这些年的付出感到荣幸，同时不断勉励自己，你需要变得更强才能融入这个集体。

　　任重而道远，纵望阿里淘宝这些年的发展之路，那些默默无闻却勇于探索钻研的人是最可爱的，遇到问题永远不服输，总会有办法去解决的。正如阿里圆桌会议HR所说的“在座的各位都是爱折腾的人”，我承认自己受之有愧，自己的身体一直不能保证毫无顾忌的拼斗，自己虽然每天坚持都去跑步，底子还是不行，想要成为一名武林中人，更漫长的路需要我坚持的走下去，意志力，我可以有。

　　坚持学习，钻研学习，实践学习。希望自己能坚持这三点信条。

　　相当佩服马总的思想理念和为人处事，也相当佩服那么多实力不凡而又忠心耿耿的部下，他们对得起他们的身价。

　　 子柳兄的《淘宝技术这十年》到此总结完毕，我相信淘宝的光辉路程的还有很长，我的学问之路，也必将一直走下去。

本文链接：淘宝十年技术路，转载请注明。

淘宝主搜索离线集群完成hadoop2.0升级

Wed, 12 Mar 2014 09:49:06 CST

搜索离线dump集群(hadoop&hbase)2013进行了几次重大升级:

2013-04

第一阶段，主要是升级hdfs为2.0版本，mapreduce仍旧是1.0;同时hbase也进行了一次重大升级（0.94.5版本）,hive升级到0.9.0;

2013-09,2013-12

第二阶段,主要升级mapreduce到2.0版本即(YARN),hive升级到0.10.0,在13年年底的时候对hbase进行了一次小版本升级;

至此，dump离线集群完全进入2.0时代:

通过升级hdfs 2.0优化shortcircuit read,使用domain socket通信等等提升了效率，加快了任务运行速度,同时支持成熟的NAMENODE HA，Federation，解决了让大家担心的集群NN单点问题，集群容量和扩展性得到大大提升。

通过升级yarn对集群资源进行更有效的管理，摒弃了slots的物理划分，采用内存资源控制使集群资源被更有效的利用，从而提高整个集群的吞吐，同时支持丰富的计算框架，为后续DUMP应用架构优化调整提供了广阔的舞台。

当然集群的升级过程也遇到了很多问题和困难

第一阶段升级过程中遇到的主要问题:

1)hdfs升级为2.0后,需要同时升级下hive版本(hive-0.9.0-cdh4.1),之前使用老版本hive jar编译的任务需要使用新版本jar包重新编译

2)mr1任务要运行在hdfs 2.0上部分任务会运行失败，主要是2.0中将原来的class换成了interface,需要重新编译即可，少量代码需要添加下throws IOException，依赖的hadoop-core jar包也被拆分成了几个(common,hdfs,mr1等)

3)hdfs shell命令差异，主要是针对mkdir或者touchz等中间如果有不存在的路径不会自动创建

4)从云梯distcp数据由于hdfs版本不兼容，必须使用hftp的方式,且因hftp不支持密码访问，后来patch解决

5)升级hdfs 2.0后集群整体读I/O升高明显，从而导致特别是I/O需求高的build任务延时

原因是2.0对dfs.client.read.shortcircuit的调整，在检查是否有权限(dfs.block.local-path-access.user中配置的用户名)进行shortcircuit读取时如果没有权限会将本地的datanode作为deadnode处理，然后数据通过远程读取

又因为hbase中dfs.client.read.shortcircuit.buffer.size设置的值不合适导致多读了很多无谓的数据，导致整个集群I/O升高

解决方案:

设置dfs.client.read.shortcircuit.buffer.size=16K与hbase的block的大小相匹配

详细的分析过程见:

http://www.atatech.org/article/detail/2733/193

http://www.atatech.org/article/detail/7207/193

第二阶段升级遇到的主要问题:

1)升级到yarn后，Capacity Schedule进行了更新，job提交只需要指定叶子queue名字即可，指定全路径会报错

2)没有了map/reduce slots的概念，集群只需配置可用的内存大小，主要的参数:

集群:

yarn.nodemanager.resource.memory-mb：                            一个nodemanager上可分配给container使用的物理内存大小
yarn.scheduler.minimum-allocation-mb：                                  resource manage分配内存的最小粒度，暂设成1024，job提交需要内存必须为此参数的整数倍
yarn.scheduler.capacity.<queue>.maximum-am-resource-percent：   am所占资源比例，可按queue设，暂设成0.3
yarn.scheduler.capacity.<queue>.user-limit-factor：            单个用户提交job限制，可按queue设，单用户如要抢占最大资源，需要设大

应用:

mapreduce.map.memory.mb,mapreduce.reduce.memory.mb：          map，reduce的内存数，默认是1024,2048，如需设大，必须是1024的整数倍,可以简单理解为之前的slots数配置
mapreduce.map.java.opts,mapreduce.reduce.java.opts：           java child进程的jvm heap大小，比上面的值小些
mapreduce.job.reduce.slowstart.completedmaps：                      对于map数较多需要跑多轮，可以设大此值，延迟reduce启动避免占用资源

3)yarn中不在兼容commons-cli-2.0-SNAPSHOT.jar，之前通过将该jar文件copy到hadoop classpath中使用的应用需要部署到各自应用的相关目录下，并在提交任务的时候引用

4)一些使用0.19等老版本的hadoop-streaming.jar需要更换为新版本

5)container内存超配被kill掉,考虑到job内存的自然增长及一些使用共享内存的任务，所以设置yarn.nodemanager.vmem-pmem-ratio=false关闭物理内存检查

6)客户端向AM获取job status报错:IOException

原因是AM内存设置太小，频繁GC导致,通过调大yarn.app.mapreduce.am.resource.mb解决

7)c2c_merge任务在yarn上运行缓慢

经过排查分析是因使用的mmap文件在pagecache中频繁换进换出导致,根本原因还是18与32内核的差异，因为集群升级过程中也对内核进行了升级，通过修改应用代码

去除madvise设置的MADV_SEQUENTIA后问题解决，参考:

http://baike.corp.taobao.com/index.php/Kbuild在32内核上性能退化问题

8)IPV4和IPV6差异引起的长短机器名问题及job data local比例低的问题

在yarn resource manager下显示部分机器是长机器名，部分机器是短机器名

hbase集群下显示全是长机器名,原因是yarn与hbase获取机器名调用的方法不一样，得到的结果也不一样，导致resourcemanager在分配container时进行优先的host匹配是匹配不上，最后变成任意匹配导致

获取机器名差异的根本原因经过分析是java处理ipv6有bug和yarn脚本bug共同导致

http://bugs.sun.com/view_bug.do?bug_id=7166687

http://www.atatech.org/article/detail/10731/193

解决方案1是修改yarn脚本，并提交issue到社区: https://issues.apache.org/jira/browse/YARN-1226

解决方案2就是给集群配置上机架感知，且让一个机器一个rack的虚拟机架配置，通过rack匹配绕开任意匹配，在 http://www.atatech.org/article/detail/10731/193 中有详细分析

9)由于我们当时在方案1还未得出结论前临时采用方案2快速解决线上data local低的问题后发现有部分任务提交失败报错: Max block location exceeded for split

原因是:配置了一个节点一个机架后CombineFileInputFormat获取split的block localtion时会根据block分布在哪些rack上获取locations信息，由于机架数等同于机器数，获取到的localtions数会超过集群的默认配置:

mapreduce.job.max.split.locations = 10，而yarn上修改了代码会在超出这个配置值时抛出异常，所以任务提交失败

解决方案1:增大mapreduce.job.max.split.locations和集群节点数一致

解决方案2:patch修改JobSplitWriter中超过配置值抛异常为打印警告日志，与升级前一致

详情见: http://www.atatech.org/article/detail/11707/193

10)gcih不能正常工作

GCIH: http://baike.corp.taobao.com/index.php/GCIH

不能正常工作的原因有两个:

l 集群升级到yarn后，nm管理job临时目录和distribute file的方式与tt不同，导致GCIH会生成多个mmap文件gcih.dat

l 在修复上述问题的过程中，发现散列到不同磁盘上task，jvm classpath加载顺序不一致，导致GCIH不能正常工作

解决方案，升级GCIH

将gcih.dat生成到gcih.jar软连对应的源目录下，这样一个job只会有一个

调整gcih.jar的加载顺序，放到preload里

11)集群资源使用100%,job一直hang住

当集群root跑满100%而下面的子queue未满时（因为希望集群的资源共享竞争，queue的最大可用资源会进行适当的超配)

不会触发抢占reduce资源的过程

解决方案:

l 不同queue的大任务尽量避开运行

l 后续patch修改在root满时触发抢占

详细分析过程见:

http://www.atatech.org/article/detail/10924/193

12)load任务写hbase偶尔会卡住

原因是当集群中有节点挂掉或者网络等出现异常可能会导致hbaseclient在select时无线等待，而锁无法释放

解决方案：

在hbase client的代码里设置超时时间

具体原因分析见:

http://www.atatech.org/article/detail/9061/193

13)集群有节点出现问题，上面的任务一直失败，后续别的任务起来后还会将container分配到这个节点

原因是yarn和之前mr1黑名单机制发生了改变

mr1是全局的黑名单，一旦被加入黑名单后续任务不会再分配

yarn的黑名单是在AM上的，也就是任务级别的，被AM加入黑名单后可以保证当前任务不会被分配上去，但是其他任务的AM中是没有这个信息的，所以还是会分配任务上去

解决方案:等待NM将节点健康信息汇报给RM,RM将节点从集群摘除

如果一直无法汇报，可以通过yarn支持的外围用户脚本来做健康检查和汇报(需要在yarn配置中配置该脚本)

详细分析见:

http://www.atatech.org/article/detail/11266/193

hive相关:

1)out join被拆成多个job

问题发现：loader在做多表join的过程时原来的一个job被hive拆成了8个job，耗时由原来的3分钟变成30分钟

通过patch解决,参考:

http://mail-archives.apache.org/mod_mbox/hive-user/201305.mbox/+r2mdv_tsofa@mail.gmail.com>

https://issues.apache.org/jira/browse/HIVE-4611

2)设置mapreduce.map.tasks不生效

分析是Hive的InputFormat的问题

如InputFormat设置为org.apache.hadoop.hive.ql.io.CombineHiveInputFormat，需要设置mapreduce.input.fileinputformat.split.maxsize来控制map的个数

如InputFormat设置为org.apache.hadoop.hive.ql.io.HiveInputFormat，则此参数生效

解决，将hive配置中默认的InputFormat配置成org.apache.hadoop.hive.ql.io.HiveInputFormat

3)写redis的hive job拆成了两个job

hive默认设置中，当map输出文件太小，会新起一个job合并小文件

解决方案:set hive.merge.mapfiles=false;

仍然存在待解决的问题:

1)有部分job会导致单disk io到100%,拖慢这个任务

2)机器出现异常问题，task全部都在localizing，job一直pending,只能kill掉重新提交

3)job或者task被kill掉后，日志也被删除，history中看不到该job的信息，排查问题困难

集群HADOOP 2.0的升级，在更好的支持现有业务:主搜，商城，店铺内，PORA个性化，尼米兹平台，中文站(offer,company,minisearch),国际站(ae,sc,p4p,aep4p,scp4p)的基础上为后续离线dump平台：ADUMP的建设夯实了基础。

一个统一存储，模块插件化设计，减少各业务线之间数据冗余，避免重复开发，同时支持快速响应各条业务线新需求的全新平台ADUMP将在3月底左右上线，紧跟集群升级的节奏，离线DUMP也将马上进入2.0时代，敬请期待!

微信再造淘宝？别开玩笑了

Sat, 28 Dec 2013 16:51:09 CST

大伙都说隔壁村的张寡妇做的豆腐特别好吃，人也漂亮，会勤俭持家，虽然之前别人给她介绍过几个也没成，但是黄脸婆们都担心她把自家的汉纸给勾引了，自己也学着做豆腐，不过榨干了水，换个法叫做豆干。外面的流言蜚语人家张寡妇也不在意，现在不只在自家档口卖了，还挑着扁担到村里吆喝，这让那些在家里拼命做豆干的黄脸婆们很是着急。

这便是微信电商给我留下的印象，关于微信电商的新闻从微信5.0里面的微信支付一出来之后就铺天盖地而来，成为舆论的焦点，6亿用户群与各种应用场景的匹配仿佛让微信成为一个让众人垂涎的豆腐一样，人人都想咬一口，并且与电商一对接，那更是有可能扭转淘宝一家独大的局面，可是张寡妇却从没表态过要再婚。

微信电商试水是真，微信商城乃谣言

25号除了圣诞节让人欢呼之外，国内一些媒体上流传的一份“微信开店招商细则”让许多商家尖叫，这个消息一出也顺便让那些做微信商城开发的第三方火了一把，“你们这些凯子还不快点来！”一些做电商的朋友均来询问此事是否有搞头，而腾讯第二天公开表态此事乃谣传让他们待嫁的心凉了一把，腾讯目前对外没有做过这样的招募，并且朋友圈内营销泛滥，如有发现销售假冒伪劣商品等不合法行为欢迎举报。

经过双十一、双十二的浸染，易迅通过微信电商的试水初见端倪，双十一精选商城收获8万单，到11月底是20万单，双十二，微信“精选商品”订单量占到当时易迅全站订单总量的10%以上。当当、一号店等平台入驻微信的事件让许多人对微信电商后续的发展深信不疑，加上通过微信朋友圈营销盈利的案例多不胜数，在淘宝将微信入口完全切断之后，虽然让我们的朋友圈少了淘宝链接的出现，但是仍然不能杜绝那些前赴后继想通过微信宣传个人店铺的店主，淘宝是目前国内个人开店比较容易且各方面条件比较成熟的一个平台，超过700万淘宝卖家（不含天猫）存在，那么可想而知这个需求有多大。

另外随着淘宝规则的苛刻以及最近C店形势的不明朗，加之媒体对微信电商风风火火的报道，更是他们欲对微信尝鲜的主要因素，只是腾讯到目前为止仍没公开表态过对微信电商的相关政策。

泼下冷水，微信支付接口个人无法申请

微信支付从出来到现在，其便捷性加之许多应用场景的整合让许多人很是垂涎，而成功申请到微信支付接口的公众号少之又少，目前申请到微信支付接口的公众号类型，除了陈坤跟罗胖胖之外，大多数为服务号且微信认证过的知名品牌，微信认证的门槛写在那里，个人公众号可通过微博进行认证，而微信认证不接受个人申请。包括25号谣传的招商文件的支付接口前提写明为服务号+微信认证。

另外，微信支付功能属于将用户账款直接打入对方账号，中间没有经过任何平台进行担保，并不像淘宝一样有支付宝平台作为担保，出现了相关的商品质量问题，可通过支付宝平台进行追缴账款。而微信支付的功能特性注定其不能像个人开放微信支付功能接口，首先是为了方便管理，其次一旦出现了纠纷，毁坏的不仅是微信这个软件的形象。

店发展并非主流，微信再造淘宝不实际

C店是淘宝的基础，也是阿里对外宣传拥有中国电商大部分市场的支撑，C店在现在的电商市场中担任的是一个提供商品多样化，个性化的角色扮演者，超过10亿件商品的汇总，让买家可以在淘宝中许多新奇百怪的商品，满足买家的个性化需求，可随着群众生活水平及消费水平的提高，特别是在一、二线城市品牌意识的强化，购买品牌产品（如电子数码化妆品，以及服装的正装等类别），一般会选择B店，可索取发票，更有保证。至于不分品牌的物品（如家居用品、饰物，以及日常穿着的休闲服装等类别），一般会选择C店，产品多样化，价格低。而C店现在对于阿里而言却是一个需要整治的问题，（对于淘宝C店的分析可看拙文“淘宝C店的茫茫未知路”）。

淘宝C店商品虽多且便宜，但由于平台门槛低，规范化不够，充斥着大量的假冒伪劣的商品在其中，淘宝的商品质量，保障等问题历来受到京东、易迅等B2C平台的诟病，这也是淘宝需要转型，出现天猫商城的一个重要因素，使商品质量提高且有保障这个成为电商平台必须贯彻的基本要求。

日前已有淘宝最大的A货女店主被警方捉走，女店主的售假行为，就是淘宝网首先发现，并将线索提供给警方。这可以理解为淘宝整治C店的一个杀鸡儆猴，对后续想进行假冒或者仿牌的店主做一个警示作用，从这里也可以看出其整治的决心。

对于拍拍这个腾讯的亲生儿，从05年出来到现在依然不能放上台面，腾讯虽有庞大的QQ用户这个根基加上对其他品牌的微（抄）创（袭）新取得了不错的效益，而拍拍出来亦使用这一手法摸了一下阿里的屁股，后果看官是看在眼里的。拍拍整个版面的设计及操作基本是淘宝的翻版，太相信自己社交用户的力量让拍拍载了跟头，直到收易迅这个干儿子之后腾讯电商才略有起色。包括阿里对C店发展到现在的整治腾讯同样看在眼里，如今想让微信这个工具让拍C满血复活，迅速占领市场份额或许有些不切实际。有人提过“假如拍拍接入了微信支付的接口，买家可以在微信上使用微信支付购买拍拍的商品，财付通作为中间平台进行担保，这样对于那些想通过微信进行营销的C店店主是一个天大的好消息。”不过消费者会因为支付工具而去购买你的商品吗？张寡妇也是因为她的豆腐好吃人家才会去买。另外，现在易迅电商的发展才是腾讯的重头戏，例如易迅触屏版全面支持微信支付功能，不用注册，直接购买。

有社交的地方就会有商业，有商业的地方就会有淘宝，指的是淘宝商品在互联网中的宣传过于广泛。一个社交工具的本质始终是用来社交，过多过杂的商业化信息会玷污社交工具本身的功能，新浪微博就是一个很好的例子。C店后续的发展应该是正规化经营，一个方向是发展壮大之后逐渐往B店靠拢，形成个人品牌店，依靠仿制品的发展只是权宜之计。另外的一个方向是自电商，自电商由自媒体概念衍生而出，通过某个渠道通过优质内容吸引用户关注度，达人经验分享及商品展示等信息，可以理解为粉丝经济的一种但却又不局限于此，详细对与自电商的概念会通过另外一篇文章来阐述。

以上所提到的自电商概念由张旭良老师提出，本人不才盗用而来。

欢迎关注我的微信号：Benli，与我分享更多观点。

本文由作者benli投稿，转载请注明来自人人都是产品经理。

本文链接《微信再造淘宝？别开玩笑了》
官方微信：woshipm，干货天天推荐，欢迎订阅

天猫运营和淘宝运营有哪些重要的区别？

Sun, 17 Nov 2013 06:52:00 CST

它们之间的区别很大
一，规则区别，天猫运营需要比淘宝运营懂得更多官方规则，比如发票，发货时间，七天无理由售后，这些在淘宝不是必须的，但在天猫是必须的。
二，推广区别，除了天天特价，试用中心，双12等少数活动，平台上的活动基本是面对天猫的，或者同等条件下，天猫店比淘宝店更容易获得活动，所以天猫运营需要更懂得各个活动规则
三，分销区别，很多天猫店本身是品牌商，为了扩大销售，有分销方面的需求，分销平台基本只面对天猫店，所以天猫运营需要更懂得分销方面的管控。
四，主体区别，天猫店只能是公司，淘宝店可以是个人，每年年底需要给天猫开发票，淘宝不需要，所以天猫运营需要懂得工商税务方面的知识
五，费用区别，天猫店的每一笔销售都要给天猫提成，所以在做任何推广时都要把这个计入成本，淘宝不需要。
六，商品区别，天猫店经营的商品需要自有品牌或者授权，淘宝不需要，所以天猫运营需要懂得更多品牌方面的规则。
总结：天猫店运营必须是一门生意，淘宝店运营可以是一个爱好，我觉得这是最大的区别。

===11.14更新分割线===
评论里有人说如果能说说淘宝能做什么，那更好，我理解是不是想问做淘宝对比天猫的优势，我没怎么做过淘宝集市店，试着说一说，不喜勿喷

淘宝集市店的优势：
一，品牌没有太大限制，开集市店不需品牌授权，除非是碰到一些被发过律师函的品牌，其他的你都可以发售，外贸，尾单，原单，A货，高仿，副厂。。。这些字眼只在淘宝存在，相信常逛淘宝的人都很熟悉。
二，相应的，类目没有过多限制，天猫店进驻需要类目与商标类别相符，商标没有的类别不能发布商品，集市店好象没有这方面的限制。
三，销售费用低，（这里是指销售费用，不是推广费用）不需要象天猫店一样给淘宝提成，也不需要给顾客开发票；
四，服务要求低，例如集市店不强制要求挂旺旺，甚至有的店是没有旺旺在线的，天猫有旺旺在线率考核；
五，域名优势，记得以前淘宝商城刚启用tmall域名的时候，很多顾客会说TMALL是骗子，他们只认taobao域名。
六，消费习惯，大量的黄钻级以上买家在淘宝形成了消费习惯，在他们的观念中，相同的产品，淘宝会比商城便宜，在商城逛后，他们会问你有没淘宝店，去那边买有没便宜，最近更悲惨的事情是已发展到问你有没1688店。
总结：淘宝集市店的优势在于打法灵活多样，象一些战术是特有，天猫店没办法学，例如游击战（一个店只推一个产品，卖完关店），麻雀战（店群，大量开店积少成多） 规则利用得好，集市店比天猫店成长更快。

— 完 —
本文作者：陈迪

【知乎日报——重磅更新】新增热门内容排行榜，精彩点评外置，你行，你上啊。
新版下载：
http://daily.zhihu.com/download

此问题还有 25 个回答，查看全部。
延伸阅读：
淘宝商城更名为天猫网，你怎么看？
淘宝商城更名为「天猫」，这个名字是怎么来的？

IT瘾淘宝推荐

电商版“龙虾”来了！阿里悟空发布，用AI帮商家7✖️24小时经营淘宝天猫店

大规模视频内容理解：淘宝视频内容标签的结构化分析和管理

▐ 为什么要做标签？

▐ 我们需要什么样的标签？

▐ 标签挖掘

▐ 标签结构化

原子标签分类体系

短语标签分维度结构化

▐ 标签管理目前核心进展

▐ 视频内容打标算法流程设计

▐ 核心技术点

▐ 视频多模态内容表征

▐ 跨模态检索

▐ 跨模态相关性判别

▐ 视频标签挂靠结果

▐ 下游推荐算法链路

▐ 标签的前台透出

▐ 用户 的数 据反馈

PRD：淘宝有好货需求文档

一、背景和目的

1. 需求背景

2. 需求目的

3. 数据指标

二、需求概述

1. 核心功能

2. 业务流程

3. 涉及开发方

三、需求详述

1. 好物榜

2. 搜索

3. 排行榜

4. 入选榜单

5. 近期购买

6. 直播中

7. 评论展示

边缘计算听说过吗？淘宝提升了69%的首屏性能

前情

业务特点

总结问题

大胆思考

研发时预渲染

按需渲染结果静态化

收益

性能提升明显，低端机首屏 1S 内

业务指标提升明显

服务器压力降低 80%

边缘计算 ER

优势-共享

优势-计算能力

场景调研

场景标准化

标准化接入

稳定降级

缓存管理

存储

缓存失效

接入过程

附录

名词介绍：

几种常用服务类型简介：

最后

[转]排名算法（二）--淘宝搜索排序算法分析

手机淘宝推荐中的排序学习-博客-云栖社区-阿里云

除了淘宝，还能去哪买好看的装饰画

艺术＋书店

103store

逵园艺术馆

三多轩

浩天古旧书店

华强北成老外淘金地？揭秘淘宝上的iPhone黑色产业

聊聊淘宝天猫个性化推荐技术演进史

[原]淘宝Buy+负责人胡晓航：从技术和产品维度看Buy+ VR购物

胡晓航简介

Buy+的数据

Buy+的技术和产品

一、为什么是全景视频+手机淘宝+Cardboard

二、场景建模

三、商品建模

四、交互方式

▐ 用户的数据反馈

MySQL·　5.7优化·Metadata Lock子系统的优化

MariaDB·　性能优化·filesort with small LIMIT optimization