域名解析与入口负载均衡

你发现快要过年了，于是想给女朋友买一件毛衣，便打开了 www.taobao.com。这时，你的浏览器首先会查询 DNS 服务器，将域名转换成 IP 地址。

你会发现，在不同地区或不同网络（电信、联通、移动）下，解析后的 IP 地址很可能是不一样的。这涉及到负载均衡的第一步：通过 DNS 解析域名时，将你的访问分配到不同的入口，同时尽可能保证你所访问的入口是所有入口中较快的一个（这与后文的 CDN 机制不同）。

访问量指标：PV 与 UV

通过这个入口，你成功访问了 www.taobao.com 的实际入口 IP 地址。这时你产生了一个 PV（Page View，页面访问）。每日每个网站的总 PV 量是形容网站规模的重要指标。淘宝网全网在平日（非促销期间）的 PV 大概在 16-25 亿之间。

同时，作为一个独立的用户，你这次访问淘宝网的所有页面，均算作一个 UV（Unique Visitor，独立用户访问）。相比之下，曾经备受关注的 12306.cn 日 PV 量最高峰在 10 亿左右，而 UV 量却远小于淘宝网十余倍，这其中的原因相信大家都能理解。

服务器集群与 LVS

因为同一时刻访问 www.taobao.com 的人数过于巨大，即便是生成淘宝首页页面的服务器，也不可能仅有一台。仅用于生成首页的服务器就可能有成百上千台，你的一次访问任务会被分配给其中一台服务器完成。

这个过程要保证公正、公平、平均（即这成百上千台服务器每台负担的用户数要差不多）。这一复杂的过程由几个系统配合完成，其中最关键的便是 LVS（Linux Virtual Server）。它是世界上最流行的负载均衡系统之一，由目前在淘宝网供职的章文嵩博士开发。

前端资源加载与 CDN 加速

经过一系列复杂的逻辑运算和数据处理，用于展示给你的淘宝网首页 HTML 内容便生成成功了。对 Web 前端稍有常识的同学都应该知道，下一步浏览器会去加载页面中用到的 CSS、JS、图片、脚本和资源文件。

但可能相对较少的同学知道，浏览器在同一个域名下并发加载的资源数量是有限制的。例如：

  • IE6-7：2 个
  • IE8：6 个
  • Chrome：各版本不大一样，一般是 4-6 个

访问淘宝首页可能需要加载 126 个资源，如此小的并发连接数自然会导致加载很久。所以前端开发人员往往会将这些资源文件分布在好多个域名下，变相绕过浏览器的限制，同时也为下文的 CDN 工作做准备。

据不可靠消息，在双十一当天高峰，淘宝的访问流量最巅峰达到 871GB/S。这个数字意味着需要 178 万个 4Mb 带宽的家庭宽带才能负担得起，也完全有能力拖垮一个中小城市的全部互联网带宽。显然，这些访问流量不可能集中在一起。

大家都知道，不同地区、不同网络（电信、联通等）之间互访会非常缓慢，但你却很少发现淘宝网访问缓慢。这便是 CDN（Content Delivery Network，内容分发网络）的作用。淘宝在全国各地建立了数十上百个 CDN 节点，利用一些手段保证你访问的资源（主要指 JS、CSS、图片等）来自离你最近的 CDN 节点，从而保证大流量分散在各地访问的加速节点上。

分布式文件系统 TFS

这便出现了一个问题：假若一个卖家发布了一个新的宝贝，上传了几张新的宝贝图片，淘宝网如何保证全国各地的 CDN 节点中都会同步存在这几张图片供用户使用呢？

这里边就涉及到了大量的内容分发与同步的相关技术。淘宝开发了分布式文件系统 TFS（Taobao File System）来处理这类问题。

搜索技术与用户意图分析

好了，这时你终于加载完了淘宝首页。你习惯性地在家搜框中输入了“毛衣”二字并敲回车，这时你又产生了一个 PV。然后，淘宝网的主搜索系统便开始为你服务了。

它首先对你输入的内容基于一个分词库进行分词操作。众所周知，英文是以词为单位的，词和词之间靠空格隔开；而中文是以字为单位，句子中所有的字连起来才能描述一个意思。例如，英文句子 I am a student，用中文则为：“我是一个学生”。计算机可以很简单通过空格知道 student 是一个单词，但是不能很容易明白“学”、“生”两个字合起来才表示一个词。把中文的汉字序列切分成有意义的词，就是中文分词，有些人也称为切词。例如“我是一个学生”，分词的结果是：我 是 一个 学生。

进行分词之后，还需要根据你输入的搜索词进行购物意图分析。用户进行搜索时常常有如下几类意图：

  1. 浏览型：没有明确的购物对象和意图，边看边买，用户比较随意和感性。

    • Query 例如："2010 年 10 大香水排行”、"2010 年流行毛衣”、"zippo 有多少种类？”

  2. 查询型：有一定的购物意图，体现在对属性的要求上。

    • Query 例如：“适合老人用的手机”、"500 元 手表”

  3. 对比型：已经缩小了购物意图，具体到了某几个产品。

    • Query 例如：“诺基亚 E71 E63"、"akg k450 px200"

  4. 确定型：已经做了基本决定，重点考察某个对象。

    • Query 例如：“诺基亚 N97"、"IBM T60"

通过对你的购物意图的分析，主搜索会呈现出完全不同的结果来。之后的数个步骤后，主搜索系统便根据上述以及更多复杂的条件列出了搜索结果，这一切是由一千多台搜索服务器完成的。

交易快照与分布式存储 Tair

然后你开始逐一点击浏览搜索出的宝贝，查看宝贝详情页面。经常网购的用户会发现，当你买过了一个宝贝之后，即便是商家多次修改了宝贝详情页，你仍然能够通过“已买到的宝贝”查看当时的快照。

这是为了防止商家对在商品详情中承诺过的东西赖账不认。显然，对于每年数十上百亿比交易的商品详情快照进行保存和快速调用不是一个简单的事情。这其中又涉及到数套系统的共同协作，其中较为重要的是 Tair，淘宝自行研发的分布式 KV 存储方案。

日志收集与数据仓库

然后无论你是否真正进行了交易，你的这些访问行为便忠实地被系统记录下来，用于后续的业务逻辑和数据分析。这些记录中访问日志记录便是最重要的记录之一。

前边我们得知，这些访问是分布在各个地区很多不同的服务器上的，并且由于用户众多，这些日志记录都非常庞大，达到 TB 级别非常正常。那么为了快速及时传输同步这些日志数据，淘宝研发了 TimeTunnel，用于进行实时的数据传输，交给后端系统进行计算报表等操作。

你的浏览数据、交易数据以及其它很多很多的数据记录均会被保留下来。使得淘宝存储的历史数据轻而易举地便达到了十数甚至更多个 PB（1PB=1024TB=1048576GB）。如此巨大的数据量经过淘宝系统 1:120 的极限压缩存储在淘宝的数据仓库中，并且通过一个叫做 云梯 的、由 2000 多台服务器组成的超大规模数据系统不断的进行分析和挖掘。

从这些数据中淘宝能够知道小到你是谁、你喜欢什么、你的孩子几岁了、你是否在谈恋爱、喜欢玩魔兽世界的人喜欢什么样的饮料等，大到各行各业的零售情况、各类商品的兴衰消亡等等海量的信息。

结语

说了这么多，其实也只是叙述了淘宝上正在运行的成千上万个系统中的寥寥几个。即便是你仅仅访问一次淘宝的首页，所涉及到的技术和系统规模都是你完全无法想象的。这是淘宝 2000 多名顶级工程师们的心血结晶，其中甚至包括长江学者、国家科学技术最高奖得主等众多大牛。

同样，百度、腾讯等的业务系统也绝不比淘宝简单。你需要知道的是，你每天使用的互联网产品，看似简单易用，背后却凝聚着难以想象的智慧与劳动。

说明：文中部分数据（如 PV 量、带宽峰值、浏览器并发限制等）及案例（如 12306 对比）引用自文章撰写时的历史资料，主要反映当时的技术架构与规模，具体数值可能随技术发展有所变化，仅供参考。