用钱能解决的问题都不是问题，我们花钱可以购买更好的机器和更好的服务。但当你变成业内最强之后，你的问题就会独特到没有人碰到过，这就意味着你必须自己动手解决问题。幸运的是，淘宝网的发展很快，不幸的是，淘宝网遇到了前所未有的问题。于是，淘宝网被迫开始走向了技术创新的道路。而技术的创新和业务的创新到底又是谁推动了谁？

淘宝文件系统——TFS

淘宝KV缓存系统——Tair

回顾一下上面几个版本，1.0版的PHP系统运行了将近一年的时间（2003年5月—2004年1月），服务器由一台发展到多台；后来数据库撑不住了，将MySQL换成了Oracle，引入了搜索引擎（2004年1月—2004年5月，叫1.1版本）；然后不到半年的时间又把开发语言换成了Java（2004年2月—2005年3月，叫2.0版本），数据服务逐步采用了IOE；随着数据量和访问量的增长，我们进行数据分库、加入缓存、使用CDN（2004年10月—2007年1月，叫2.1版本）。这几个版本中间有些时间上的重合，因为很多架构的演化并没有明显的时间点，它是逐步进化而来的。

在描述2.1版本的时候，我写的标题是《坚若磐石》，这个“坚若磐石”是因为这个版本终于稳定下来了，在这个版本的系统上，淘宝网运行了两年多的时间。这期间有很多优秀的人才加入，也开发了很多优秀的产品，例如，商品的类目属性、支付宝认证系统、招财进宝项目、淘宝旅行、淘宝彩票、淘宝论坛等，甚至在团购网站风起云涌之前，淘宝网在2006年就推出了“团购”的功能。

在这些产品和功能的最底层，其实还是商品管理和交易管理这两大功能。这两大功能在2.1版本中都有很大的变化。商品管理起初是要求卖家选择7天到期还是14天到期，到期之后自动下架，必须重新发布才能上架，上架之后就变成了新的商品信息（ID变过了）。另外，如果商品在这期间成交了，之后再有新货，必须发布一个新的商品信息。这么做有几个原因，一是参照拍卖商品的时间设置，要在某日期前结束挂牌；二是搜索引擎不知道同样的商品哪个排在前面，那就把挂牌时间长的排前面（这样就必须在某个时间把老的商品下架，否则它会一直排在前面）；第三是成交信息和商品ID关联，这个商品如果多次编辑还是同一个ID的话，成交记录中的商品信息会不断改变；还有一个不为人知的原因是我们的存储有限，不能让所有的商品老存放在主库中。这种处理方式简单粗暴，但还算是公平。不过这样会导致很多需求都无法满足，例如，卖出一件商品之后就无法更改价格，否则前面已经成交的那个价格都变了，而且同样的商品，上一次销售后的很多好评都无法在下一个商品上体现出来；再如，我买过的商品结束后只看到交易的信息，不知道卖家是否还会卖。基于这些需求，我们在2006年下半年把商品和交易拆开，一个商家的一种商品有一个唯一的ID，上下架都是同一个商品。那么如果卖家修改价格和库存等信息，已成交的信息怎么处理？那就在买家每交易一次的时候，都记录下商品的快照信息，有多少次交易就有多少个快照。这样买卖双方比较爽了，但这给系统带来了什么？存储的成本大幅度上升了！ cz+5iy3JHJZF4GV3NNnsA6Bo07QipEw1ZrzwhNmBsy/WeCnQu5CaPPCVjcqiUXtH