淘宝技术这十年

《淘宝技术这十年》是电子工业出版社2013年5月出版的图书，由子柳编著。本书从工程师的角度讲述淘宝这个超大规模互联网系统的成长历程，及其所有主动和被动的技术变革的前因后果。书中有幕后故事、产品经验、架构演进、技术启蒙，也有大牛成长、业内八卦、失败案例、励志故事。全书文风流畅，有技术人员特有的幽默感；内容积极正面，有现场感，全部是作者亲身经历。

子柳：本名赵超，2004年加入淘宝网，取花名子柳。历任开发工程师、项目经理、产品经理、测试经 理，2009年随着淘宝系统的大规模重构和人才的迅速扩张，创办了“淘宝技术大学”，培养内外部工 程师众多，人称“校长”。2011年将培训中的内容写成文章发表，遂一发不可收拾，总结了淘宝十年 的技术之路，乃成本书。

你发现快要过年了，于是想给你的女朋友买一件毛衣，你打开了www.taobao.com，这时你的浏览器首先查询DNS服务器，将www.taobao.com转换成IP地址。不过你首先会发现，在不同的地区或者不同的网络（电信、联通、移动）下，转换后的IP地址很可能是不一样的，这首先涉及负载均衡的第一步，通过DNS解析域名时，将你的访问分配到不同的入口，同时尽可能保证你所访问的入口是所有入口中可能较快的一个（这和后文的CDN不一样）。
你通过这个入口成功地访问了www.taobao.com实际的入口IP地址，这时产生了一个PV（Page View，页面访问量。每日每个网站的总PV量是形容一个网站规模的重要指标。淘宝网全网在平日（非促销期间）的PV大概是16～25亿个之间）。同时作为一个独立的用户，你这次访问淘宝网的所有页面均算作一个UV（Unique Visitor，用户访问）。最近臭名昭著的12306.cn的日PV量最高峰在10亿个左右，而UV量却远小于淘宝网十余倍，这其中的原因相信大家都知道。
因为同一时刻访问www.taobao.com的人数过于巨大，所以，即便是生成淘宝首页页面的服务器，也不可能仅有一台，仅用于生成www.taobao.com首页的服务器就可能有成百上千台，那么你的一次访问时生成页面给你看的任务便会被分配给其中一台服务器完成。这个过程要保证公正、公平、平均（即这成百上千台服务器每台负担的用户数要差不多），这一很复杂的过程由几个系统配合完成，其中最关键的便是LVS（Linux Virtual Server，世界上最流行的负载均衡系统之一，是由目前在淘宝网供职的章文嵩博士开发的）。
经过一系列复杂的逻辑运算和数据处理，这次用于给你看的淘宝网首页的HTML内容便成功生成了。对Web前端稍微有点常识的人都应该知道，浏览器下一步会加载页面中用到的CSS、JS （JavaScript）、图片等样式、脚本和资源文件。但是可能相对较少的人才会知道，你的浏览器在同一个域名下并发加载的资源数量是有限的，例如IE 6和IE 7是两个，IE 8是6个，chrome各版本不大一样，一般是4～6个。我刚刚看了一下，我访问淘宝网首页需要加载126个资源，那么如此小的并发连接数自然会加载很久。所以前端开发人员往往会将上述这些资源文件分布在多个域名下，变相地绕过浏览器的这个限制，同时也为下文的CDN工作做准备。
据不可靠消息称，在2011年“双十一”当天高峰，淘宝的访问流量最巅峰达到871GB/s，这个数字意味着需要178万个4MB/s的家庭宽带才能负担得起，也完全有能力拖垮一个中小城市的全部互联网带宽。显然，这些访问流量不可能集中在一起，并且大家都知道，不同地区、不同网络（电信、联通等）之间互访会非常缓慢，但是你却很少发现淘宝网访问缓慢，这便是CDN （Content Delivery Network，即内容分发网络的作用）。淘宝在全国各地建立了数十个甚至上百个CDN节点，利用一些手段保证你访问的（这里主要指JS、CSS、图片等）站点是离你最近的CDN节点，这样便保证了大流量的分散以及在各地访问的加速。
这便出现了一个问题，那就是假若一个卖家发布了一个新的宝贝，上传了几张新的宝贝图片，那么淘宝网如何保证全国各地的CDN节点中都会同步存在这几张图片供用户使用呢？这就涉及大量的内容分发与同步的相关技术。另外，淘宝上拥有海量的宝贝图片等静态文件，这些文件的总容量也达到了数PB （1PB=1024TB=1048576GB），为了快速存取这些文件，淘宝开发了分布式文件系统TFS（TaoBao File System）来处理这类问题。
好了，这时你终于加载完成淘宝首页然后习惯性地在首页搜索框中输入“毛衣”二字并按回车键，这时你又产生了一个PV，然后，淘宝网的主搜索系统便开始为你服务，它首先对你输入的内容基于一个分词库进行分词操作。众所周知，英文是以词为单位的，词和词之间靠空格隔开，而中文是以字为单位，句子中所有的字连起来才能描述一个意思。例如，英文句子“I am a student”用中文表示，则为“我是一个学生”。计算机可以很简单地通过空格知道student是一个单词，但是不太容易明白“学”、“生”两个字合起来才表示一个词。把中文的汉字序列切分成有意义的词，就是中文分词，有些人也称为切词。“我是一个学生”分词的结果是“我是一个学生”。
进行分词操作之后，还需要根据你输入的搜索词进行购物意图分析。用户进行搜索时常常有如下几类意图。
● 浏览型：没有明确的购物对象和意图，边看边买，用户比较随意和感性。Query1例如：“2010年10大香水排行”、“2010年流行毛衣”、“zippo有多少种类？”；
● 查询型：有一定的购物意图，体现在对属性的要求上。Query例如：“适合老人用的手机”、“500元手表”；
● 对比型：已经缩小了购物意图，具体到某几个产品。Query例如：“诺基亚E71 E63”、“akg k450 px200”；
● 确定型：已经做了基本决定，重点考察某个对象。Query例
如：“诺基亚N97”、“IBM T60”。
通过对你的购物意图的分析，主搜索会呈现出完全不同的结果。
之后的数个步骤后，主搜索系统便根据上述以及更多复杂的条件列出了搜索结果，这一切是由一千多台搜索服务器完成的。然后你开始逐一点击浏览搜索出的宝贝，查看宝贝详情页面。经常网购的亲们会发现，当你买过一个宝贝之后，即便是商家多次修改了宝贝详情页，你仍然能够通过“已买到的宝贝”查看当时的快照。这是为了防止商家对在商品详情中承诺过的东西赖账不认。显然，对于每年数十亿甚至上百亿笔交易的商品详情快照进行保存和快速调用不是一件简单的事情。这其中又涉及数套系统的共同协作，其中较为重要的是Tair（淘宝自行研发的分布式KV存储方案）。
接下来，无论你是否真的进行了交易，你的这些访问行为都会如实地被系统记录下来，用于后续的业务逻辑和数据分析。这些记录中的访问日志记录便是最重要的记录之一，但是从前面我们得知，这些访问是分布在各个地区多个不同的服务器上的，并且由于用户众多，这些日志记录都非常庞大，达到TB级别也非常正常。那么，为了快速、及时、同步地传输这些日志数据，淘宝研发了TimeTunnel，用于进行实时的数据传输，然后交给后端系统进行计算报表等操作。
你的浏览数据、交易数据以及其他很多数据记录均会被保留下来，使得淘宝存储的历史数据轻而易举地便达到了数十甚至更多个PB。如此巨大的数据量存储在阿里巴巴集团的数据仓库中，并且其中有些数据使用了压缩比高达1∶120的极限存储技术。之后这些数据会通过一个叫做云梯的基于Hadoop的由3000多台服务器组成的超大规模数据系统，以及一个基于阿里巴巴集团自主研发的ODPS系统的数据系统，不断地进行分析和挖掘。
淘宝从这些数据中能够知道小到你是谁，你喜欢什么，你的孩子几岁了，你是否在谈恋爱，喜欢玩魔兽世界的人喜欢什么样的饮料等，大到各行各业的零售情况、各类商品的兴衰消亡等海量的信息。
说了这么多，其实也只是叙述了淘宝上正在运行的成千上万个系统中的寥寥几个。即便是你仅仅访问一次淘宝的首页，所涉及的技术和系统规模都是你完全无法想象的，是淘宝2000多名顶级的工程师们的心血结晶，其中甚至包括长江学者、国家科学技术最高奖得主等众多牛人。同样，百度、腾讯等的业务系统也绝不比淘宝简单。你需要知道的是，你每天使用的互联网产品看似简单易用，背后却凝聚着难以想象的智慧与劳动。

Oracle的性能和并发访问能力之所以如此强大，有一个关键性的设计——连接池，连接池中放的是长连接，是进程级别的，在创建进程的时候，它就要独占一部分内存空间。也就是说，这些连接数在固定内存的Oracle Server上是有限的，任何一个请求只需要从连接池中取得一个连接即可，用完后释放，这不需要频繁地创建和断开连接，而连接的创建和断开的开销是非常大的。

一家小超市，一个收银员，同时还兼着干点其他的事情，例如，打扫卫生、摆货。
来买东西的人多起来了，排队很长，顾客受不了，于是增加了一个收银台，雇了一个收银员。
忙的时候收银员根本没时间去打扫卫生，超市内有点脏，于是雇了一个专门打扫卫生的。
随着顾客不断增加，超市也经过好几次装修，由以前的一层变成了两层，这个时候所做的事情就是不断增加收银台、收银员和打扫卫生的人。
在超市运转的过程中，老板发现一个现象，有些收银台排很长的队，有些收银台排的人不多，了解后知道是因为收银台太多了，顾客根本看不到现在各个收银台的状况。对于这个现象，一种简单的方法就是继续加收银台。但一方面，超市没地方可加收银台了，另一方面，作为老板，当然不需要雇太多的人，于是开始研究怎样让顾客了解到收银台的状况，简单地加了一个摄像头和一个大屏幕，在大屏幕上显示目前收银台的状况，这样基本解决了这个问题。
排队长度差不多后，又出现了一个现象，就是有些收银台速度明显比其他的慢，原因是排在这些收银台的顾客买的东西特别多，于是又想了一招，就是设立专门的10件以下的通道，这样买东西比较少的顾客就不用排太长的队了，这一招施展后，顾客的满意度明显提升，销售额也好了不少，后来就继续用这招应对团购状况、VIP状况。
在解决了上面的一些烦心事后，老板关注到了一个存在已久的现象，就是白天收银台很闲，晚上则很忙，于是从节省成本上考虑，决定实行部分员工只在晚上上班的机制，白天则关闭一些收银台，顾客仍然可以通过大屏幕看到哪些收银台是关闭的，避免走到没人的收银台去，实行这招后，成本大大降低了。

● 集群：所有的收银员提供的都是收银功能，无论顾客到哪一个收银员面前，都可完成付款，可以认为所有的收银员就构成了一个集群，都希望能做到顾客增加的时候只需增加收银员就行。在现实生活中有场地的限制，而在互联网应用中，能否集群化还受限于应用在水平伸缩上的支撑程度，而集群的规模通常会受限于调度、数据库、机房等。
● 分工：收银员和打扫卫生的人分开，这种分工容易解决，而这种分工在互联网中是一项重要而复杂的技术，没有现实生活中这么简单，涉及的主要有按功能和数据库的不同拆分系统等，如何拆分以及拆分后如何交互是需要面临的两个挑战。因此，会有高性能通信框架、SOA平台、消息中间件、分布式数据层等基础产品的诞生。
● 负载均衡：让每个收银台排队差不多长，设立小件通道、团购通道、VIP通道等，这些可以认为都是集群带来的负载均衡的问题，从技术层面上说，实现起来自然比生活中复杂很多。
● 根据QoS分配资源：部分员工仅在晚上上班的机制在现实生活中不难做到，而对互联网应用而言，就是一件复杂而且极具挑战的事。
参照生活中的例子来说，在面对用户增长的情况下，想出这些招应该不难，不过要掌握以上四点涉及的技术就相当复杂了，而且互联网中涉及的其他很多技术还没在这个例子中展现出来，例如缓存、CDN等优化手段；运转状况监测、功能降级、资源劣化、流控等可用性手段，自建机房、硬件组装等成本控制手段。因此，构建一个互联网网站确实是不容易的，技术含量十足，当然，经营一家超市也不简单。