Tair

　　TFS 的开发，让淘宝的图片功能得到了充分的发挥。同 TFS 一样，很多技术都是在产品的推动下得到发展的。在讲下面的技术之前，有必要说说那些年，我们一起做过的几个产品。

　　先说个比较悲剧的——【团购】，这个团购可不是现在满大街挂的那种 groupon 类型的模式，在 groupon 出生之前，在 2006 年，淘宝的产品经理一灯就提出了“团购”这种产品。一灯最初的设想是让买家在社区发起团购，“团长”找到足够的人之后，去跟卖家砍价，这类似于现在蘑菇街的“自由团”。但由于种种原因，在开发的时候产品的功能做了裁剪，跟最初的设想比起来偏离了一点，变成了让卖家设置团购价，在买家达到指定的数量之后，以团购价成交。这个功能看起来是结合了淘宝一口价和荷兰拍的另一种交易模式，但不幸没有支撑下去，这种交易方式最大的弱点就是让买家看到了卖家的底牌，即便达不到团购的数量，他们也往团购的价格上砍。当时为了引流量，淘宝网开辟了团购专区，实诚的卖家在达不到团购数量的时候，被砍价砍亏了，狡猾的卖家干脆提高原价，利用这个专区做促销。在接下来的两年里这个产品沦落成了促销工具(话说现在满大街的团购，其实也就是促销)。这个产品，让研发人员对“产品”这个概念有了深刻的认识。

　　再说一个更加悲剧的——【我的淘宝】，我的淘宝是给会员管理自己的商品、交易、收货地址、评价、投诉的地方，这个地方由于登录之后才能看到，所以风格跟外面完全不一样，很长时间都没有优化过，样子丑，用户操作也不方便，如果一个人有很多商品，上下架需要一个一个的操作，非常麻烦(想想那些卖书的)。这时候一个重要人物登场了，承志(现在的蘑菇街 CEO，他让我把他描写的帅一点)，他给我们演示了最牛叉的前端交互技术，就是 Gmail 上那种 Ajax 的交互方式，可以拖动、可以用右键、可以组合键选择、操作完毕还不刷新页面，管理商品如有神助，帅呆了。我是这个项目的项目经理，一灯是产品经理，我们再拉上万剑和一伙工程师就开搞了。热火朝天的干了三个月，快要完成的时候，老马不知道怎么回事突然出现在我身后，看我操作了一遍新版我的淘宝之后，问我这是不是客户端软件，我说是网页，他抓狂了，说这跟客户端软件一样，链接底下连线都木有，上下架用文件夹表示，我都不知道怎么操作了，卖家肯定也不会玩。

　　老马果然是神一样的人物，他说的应验了，淘宝历史上第一个群体性事件爆发了，试用完新版本的我的淘宝之后，很多卖家愤怒了，说不会玩。一灯就和承志一起商量怎么把页面改得像个网页一点，改了半个月，愤怒依然没有平息。我很无奈地看着这两个人在那里坚持，然后跟老板们商量怎么办。后来我们用了一个很挫的方法给自己一个台阶，到论坛上让大家投票要不要使用新版我的淘宝，投票结果是一半以上的反对。于是这么十来个人做了 3 个月的系统被杀掉了。这让我非常沮丧，但最痛苦的还不是这个，我们下线之后，另外一拨卖家不满了，说这么好的功能怎么没有了?啊~~~你们怎么不早点站出来，亲?这个产品带给我们的是新技术(Ajax、YUI 前端框架)的尝试，还有就是新技术对用户操作习惯的改变，一定要慎之又慎。另外还有一点没有总结好的教训，就是应对群体事件的时候，我们手足无措，在后来【招财进宝】和淘宝商城出现群体性事件的时候，我发现悲剧在重演。

　　说到【招财进宝】，这个是最悲剧的产品。到 2006 年五一的时候，一个划时代的项目启动了(我苦逼的连续失去了两个五一节，前面一个是 2005 年做支付宝系统)。财神说要用最好的项目阵容，我被选中了，这一下子让我觉得我能划分到最好的员工之类，在【我的淘宝】这个产品中严重受伤的心又痊愈了。这是一个商品 P4P 的系统，就是按成交付费。我们认为已经有很多卖家有钱了，但淘宝上这么多的商品，他们很难被找到，卖家愿意花钱让商品排在前面。我们允许卖家购买广告位，把他的商品按一定算法给个排名(类似于百度的竞价排名，但不仅仅看他出了多少钱，还有信用、成交量、被收藏数量等等，这个算法搞的巨复杂)。这是一个多么牛叉的盈利模式啊!

　　这个系统进行的很顺利，但发布的时候，更大的群体性事件出来了，买家们质疑：你们不是承诺 3 年不收费么?收广告费不是收费么?后来我们的竞争对手又推波助澜，公关公司和圈子里各路大侠上蹿下跳，甚至同行搞了个“一键搬家”的功能来收纳我们的会员。一时之间，舆论哗然，各种矛头都指了过来。为了收场，我们又一次在论坛里面让用户投票决定产品是否下线，同【我的淘宝】一样，以悲剧收场。也如同【我的淘宝】一样，下线后，一拨尝到甜头的卖家说，这么好的功能怎么没有了?(直到后来 yahoo 中国合并过来之后，开发了淘宝直通车，才以类似的产品形态满足了这部分需求)

　　虽然招财进宝失败了，但这个项目中对技术的探索更加深入，这里面用到了用户行为追踪、Ajax 等。其中有一个技术的细节非常经典，淘宝商品详情页面每天的流量在 10 亿以上，里面的内容都是放在缓存里的，做招财进宝的时候，我们要给卖家显示他的商品被浏览的次数(见下图)，这个数字必须实时更新，而用缓存的话一般都是异步更新的。于是商品表里面增加了这样一个字段，每增加一个 PV 这个字段就要更新一次。发布上去一个小时数据库就挂掉了，撑不住这么高的 update。数据库撑不住怎么办?一般的缓存策略是不支持实时更新的，这时候多隆大神想了个办法，在 apache 上面写了一个模块，这个数字根本不经过下层的 web 容器(只经过 apache)就写入一个集中式的缓存区了，这个缓存区的数据再异步更新到数据库。这就是我前面提到的，我们整个商品详情的页面都在缓存中了，把缓存用到了极致。

　　(这个图真不是广告，亲)

　　那么接下来，我们就说说缓存的技术吧。

　　淘宝在很早就开始使用缓存的技术了，在 2004 年的时候，我们使用一个叫做 ESI(Edge SideIncludes)的缓存。在决定采用 ESI 之前，多隆试用了很多 java 的 cache，但都比较重，后来用了 oracle webcache，也经常挂掉，oracle webcache 也支持 ESI，多隆由此发现了 ESI 这个好东东。ESI 是一种数据缓冲/缓存服务器，它提供将 Web 网页的部分(这里指页面的片段)进行缓冲/缓存的技术及服务。由 Oracle 公司和 AkamaiTechnologies 公司制定规格，Akamai 公司提供对应的信息传送的服务。以往的数据缓冲服务器和信息传送服务以“页”为单位制作，复制到数据缓冲服务器中，处理静态页面很有效。但在面对动态内容的时候，就很难得到高效率。在 ESI 中是部分的缓冲网页，使用基于 XML 的标记语言，指定想要缓冲的页面部分。由此，页面内分为动态地变更的部分和静态的不变更的部分，只将静态的部分有效地发送到服务器中。淘宝网的数据虽然大部分都是动态产生的，但页面中的静态片段也有很多，例如页面的头、尾，商品详情页面的卖家信息等(如下图右侧)，这些最早都是从 ESI 缓存中读取的。

　　ESI 解决了页面端静态片段的缓存，聪明的读者可能马上就想到了，在后端的那些数据能不能使用缓存?显然也是可以的，而且是必须的。例如一个大卖家的商品和店铺，一天的浏览量可能是几百万，一个小卖家的可能只有几个，那这个大卖家的用户信息要是每次都去数据库里面取，显然不划算，要是把这个信息放在内存里面，每次都从内存里取，性能要好很多。这种应用场景，就是 memcached 这种 Key-Velue 缓存的用武之地。只可惜在淘宝急需要 memcached 的时候，它还没有崭露头角(它 2003.6 出现的，但近几年才火爆起来，当时没发现它)。我们的架构师多隆大神再一次出手了，他写了一个缓存系统，叫 TBstore，这是一个分布式的基于 BerkeleyDB 的 cache 系统，推出之后在 Alibaba 集团内部使用非常广泛，特别是对于淘宝，tbstore 上应用了 ESI(就是上面说过的那个 ESI)、checkcode(验证码)、description(前文说过的商品详情)、story(心情故事，商品信息里面的一个大字段，长度仅次于商品详情)、用户信息等等内容。

　　TBstore 的分布式算法实现：根据保存的 key，对 key 进行 hash 算法，取得 hash 值，再对 hash 值与总 Cache 服务器数据取模。然后根据取模后的值，找到服务器列表中下标为此值 Cache 服务器。由 javaclient api 封装实现，应用无需关心;这点和 memecached 的实现方案完全一致。

　　TBstore 有一个优点，这也是它的弱点，它的存储是基于 Berkeley DB 的，而 BerkeleyDB 在数据量超过内存的时候，就要往磁盘上写数据了，所以说它是可以做持久化存储的。但是一旦往磁盘写数据，作为缓存的性能就大幅度下降。

　　这时又有一个项目，推动了淘宝在缓存方面的技术提升。在 2007 年，我们把淘宝的用户信息独立出来，形成一个中心系统 UIC(userinformationcenter)，因为淘宝所有的功能都要依赖于用户信息，所以这个模块必须单独拿出来，不然以后系统无法扩展了。把 UIC 拿出来以后，应用系统访问 UIC，UIC 访问数据库取得用户信息，粗粗算一下，每天要取几十亿的用户信息，直接查询数据库的话，显然数据库要崩溃的，这里必须要用缓存。于是多隆为 UIC 专门写了一个缓存系统，取名叫做 tdbm。tdbm 抛弃了 BerkeleyDB 的持久功能，数据全部存放在内存中。到 2009 年，多隆又参考了 memcached 的内存结构，改进了 tdbm 的集群分布方式，在内存利用率和吞吐量方面又做了大幅提升，推出了 tdbm2.0 系统。

　　由于 tdbm 和 TBstore 的数据接口和用途都很相似，开发团队把二者合并，推出了淘宝自创的 KV 缓存系统——tair。tair 包括缓存和持久化两种存储功能。tair 作为一个分布式系统，是由一个中心控制节点和一系列的服务节点组成。我们称中心控制节点为 config server，服务节点是 dataserver。config server 负责管理所有的 data server，维护 data server 的状态信息。dataserver 对外提供各种数据服务，并以心跳的形式将自身状况汇报给 config server。 configserver 是控制点，而且是单点，目前采用一主一备的形式来保证其可靠性。所有的 data server 地位都是等价的。tair 的架构图如下所示：

　　目前，tair 支撑了淘宝几乎所有系统的缓存信息。Tair 已开源，地址 code.taobao.org。

　　在创造了 TFS 和 tair 之后，整个系统的架构可以如下所示：

　　在这个时候搜索引擎 iSearch 也进行了一次升级，之前的搜索引擎是把数据分到多台机器上，但是每份数据只有一份，现在是每份数据变成多份，整个系统从一个单行的部署变成了矩阵。能够支撑更大的访问量，并且做到很高的可用性。

        原文：http://blog.sina.com.cn/s/blog_633219970101062y.html

　　 淘宝网技术发展回顾(一)：“光棍节”的狂欢

　　 淘宝网技术发展回顾(二)：个人网站时期

　　 淘宝网技术发展回顾(三)：Oracle/支付宝/旺旺

　　 淘宝网技术发展回顾(四)：Java时代 脱胎换骨

　　 淘宝网技术发展回顾(五) Java时代：坚若磐石