淘宝的缓存技术
淘宝在很早就开始使用缓存技术了，在2004年的时候，我们使用一个叫做ESI(Edge Side Includes)的缓存（Cache）。在决定采用ESI之前，多隆试用了Java的很多Cache，但都比较重，后来用了Oracle Web Cache，也经常挂掉，Oracle Web Cache也支持ESI，多隆由此发现了ESI这个好东东。ESI是一种数据缓冲/缓存服务器，它提供将Web网页的部分（这里指页面的片段）进行缓冲/缓冲的技术及服务。以往的数据缓冲服务器和信息传送服务器以“页”为制作单位，复制到数据缓冲服务器中，这用于处理静态页面很有效，但在面对 动态内容的时候，就很难得到高效率。在ESI中是部分的缓冲网页，使用基于XML的标记语言，指定逍遥缓冲的页面部分。由此，页面内分为动态地变更部分和静态的不变部分，只将静态的部分有效地发送到服务器中。淘宝网的数据虽然是动态产生的，但页面中的静态片段也有很多，例如页面的投、尾，商品详情页面的卖家信息等们这些都是从ESI缓存中读取的。
回顾一下上面几个版本，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，上下架都是同一个商品。那么如果卖家修改价格和库存等信息，已成交的信息怎么处理？那就在买家每交易一次的时候，都记录下商品的快照信息，有多少次交易就有多少个快照。这样买卖双方比较爽了，但这给系统带来了什么？存储的成本大幅度上升了！
淘宝文件系统——TFS
存储的成本高到什么程度呢？数据库方面用了IOE，一套下来就是千万级别的，那几套下来就是——好多钱啊。另外，淘宝网还有很多文件需要存储，最主要的就是图片、商品描述、交易快照，一个商品要包含几张图片和一长串的描述信息，而每一张图片都要生成几张规格不同的缩略图。在2010年，淘宝网的后端系统上保存着286亿个图片文件。图片在交易系统中非常重要，大家常说“一张好图胜千言”、“无图无真相”，淘宝网的商品照片，尤其是热门商品图片的访问流量是非常大的。在淘宝网整体流量中，图片的访问流量要占到90%以上，而且这些图片平均大小为17.45KB，小于8KB的图片占整体图片数量的61%，占整体系统容量的11%。这么多的图片数据、这么大的访问流量，给淘宝网的系统带来了巨大的挑战。对于大多数系统来说，最头疼的就是大规模的小文件存储与读取，因为磁头需要频繁寻道和换道，因此，在读取上容易带来较长的延时。在大量高并发访问量的情况下，简直就是系统的噩梦。我们该怎么办？
同样的套路，在某个规模以下采用现有的商业解决方案，达到某种规模之后，商业的解决方案无法满足，只有自己创造解决方案了。对于淘宝的图片存储来说，转折点在2007年。这之前，一直采用商用存储系统，应用NetApp公司的文件存储系统随着淘宝网的图片文件数量以每年3倍的速度增长，淘宝网后端NetApp公司的存储系统也从低端到高端不断迁移，直至2006年，即使是NetApp公司最高端的产品也不能满足淘宝网存储的要求。从2006年开始，我们决定自己开发一套针对海量小文件存储的文件系统，用于解决自身图片存储的难题。这标志着淘宝网从使用技术到了创造技术的阶段。
2007年之前的图片存储架构如下图所示。
在一次架构师大会上，章文嵩博士总结了几点商用存储系统的局限和不足。
第一，商用存储系统没有对小文件存储和读取的环境进行有针对性的优化；第二，文件数量大，网络存储设备无法支撑；第三，整个系统所连接的服务器越来越多，网络连接数已经达到网络存储设备的极限；第四，商用存储系统扩容成本高，10TB的存储容量需要几百万元，而且存在单点故障，容灾和安全性无法得到很好的保证。
谈到在商用系统和自主研发之间的经济效益方面的对比，章文嵩博士列举了以下几点经验。
第一，商用软件很难满足大规模系统的应用需求，无论是存储、CDN还是负载均衡，在厂商实验室端，都很难实现如此大的数据规模测试。
第二，在研发过程中，将开源和自主开发相结合，会有更好的可控性，若系统出了问题，完全可以从底层解决问题，系统扩展性也更高。
第三， 在一定规模效应的基础上，研发的投入都是值得的。下图演示的是一个自主研发和购买商用系统的投入产出比，实际上，图中交叉点的左边，购买商用系统都是更加实际和经济性更好的选择，只有在规模超过交叉点的情况下，自主研发才能收到较好的经济效果。实际上，规模化达到如此程度的公司并不多，不过淘宝网已经远远超过了交叉点。
第四，自主研发的系统可在软件和硬件的多个层次之间不断优化。
#p#
历史总是惊人的巧合，在我们准备研发文件存储系统的时候，Google走在了前面，2007年，他们公布了GFS（Google FileSystem）的设计论文，这给我们带来了很多借鉴的思路。随后我们开发出了适合淘宝使用的图片存储系统（TaoBao File System，TFS）。3年之后，我们发现历史的巧合比我们想象的还要神奇，几乎跟我们同时，中国的另外一家互联网公司也开发了他们的文件存储系统，甚至取的名字都一样——TFS，太神奇了！（猜猜是哪家）
2007年6月，TFS正式上线运营。在生产环境中应用的集群规模达到了200台PC Server（146GB×6 SAS 15KB Raid5），文件数量达到上亿级别；系统部署存储容量为140TB；实际使用存储容量为50TB；单台支持随机IOPS 200+，流量为3MB/s。
说到TFS的系统架构，首先要描述清楚业务需求，淘宝对图片存储的需求大概可以描述如下：文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾，能备份。显然，应对这种需求时要用分布式存储系统；由于文件大小比较统一，可以采用专有文件系统；由于并发量高，读写随机性强，需要更少的I/O操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。
参照GFS并做了大量的优化之后，TFS 1.0版的架构图如下。
从上面的架构图可看出：集群由一对Name Server和多台DataServer构成，Name Server的两台服务器互为双机，这就是集群文件系统中管理节点的概念。
在这个系统中：
- 每个Data Server运行在一台普通的Linux主机上；
- 以Block文件的形式存放数据文件（一个Block的大小一般为Block存储多份是为了保证数据安全；
- 利用ext3文件系统存放数据文件；
- 磁盘raid5做数据冗余；
- 文件名内置元数据信息，用户自己保存TFS文件名与实际文件的对照关系，这使得元数据量特别小。
淘宝TFS文件系统在核心设计上最大的取巧在于，传统的集群系统中元数据只有1份，通常由管理节点来管理，因而很容易成为瓶颈。而对于淘宝网的用户来说，图片文件究竟用什么名字来保存他们并不关心，因此，TFS在设计规划上考虑在图片的保存文件名上暗藏了 一些元数据信息，例如，图片的大小、时间、访问频次等信息，包括所在的逻辑块号。而在实际的元数据上，保存的信息很少，因此，元数据结构非常简单。仅仅只需要一个FileID就能够准确定位文件在什么地方。由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的目录树结构，因为目录树开销最大。拿掉后，整个集群的高可扩展性可极大地提高。实际上，这一设计理念和目前业界的“对象存储”较类似。
在TFS上线之前，淘宝网每个商品只允许上传一张图片，大小限定在120KB之内，在商品详情中的图片必须使用外站的服淘宝技术这十年务。那时候发布一件商品确实非常麻烦，笔者曾经想卖一台二手电脑，我先把照片上传到Google相册，在发布到淘宝网之后发现Google相册被墙（即被屏撇，无法访问），我的图片别人看不到，当时很郁闷。在TFS上线后，商品展示图片开放到5张，商品描述里面的图片也可以使用淘宝的图片服务，到现在为止，淘宝网给每个用户提供了1GB的图片空间。技术和业务就是这么互相借力推动着的，业务满足不了的时候，技术必须创新，技术创新之后，业务有了更大的发展空间。
TFS发布之后，又经历了多个版本的修改，到1.3版的时候已经比较成熟了。2009年6月，TFS 1.3版本上线，集群规模大大扩展，部署到淘宝的图片生产系统上，整个系统已经从原有200台PC服务器扩增至440台PC服务器（300B×12 SAS 15KB RPM）+30台PC服务器（600B×12 SAS 15KB RPM )。支持文件数量也扩容至百亿级别；系统部署存储容量为1800TB；当前实际存储容量为995TB；单台DataServer支持随机IOPS900+，流量为15MB+；目前NameServer运行的物理内存是217MB（服务器使用千兆网卡）。
TFS 1.3版本逻辑结构图如下图所示。
在TFS 1.3版本中，工程师们重点改善了心跳和同步的性能，最新版本的心跳和同步在几秒钟之内就可完成切换，同时进行了一些新的优化，包括元数据存储在内存中、清理磁盘空间等。
性能上也做了优化，包括如下内容。
- 采用ext4文件系统，并且预分配文件，减少ext3等文件系统淘宝技术这十年数据碎片带来的性能损耗；
- 单进程管理单块磁盘的方式，摒除RAID5机制；
- 带有HA机制的中央控制节点，在安全稳定和性能复杂度之间取得平衡；
- 缩减元数据大小，将更多的元数据加载入内存，提升访问速度；
- 跨机架和IDC的负载均衡及冗余安全策略；
- 完全平滑扩容。
对于整个图片服务来说，仅有TFS还是不够的，整个图片服务机器的拓扑结构如下图所示。
整个图片存储系统就像一个庞大的服务器，有处理单元、缓存单元和存储单元。前面已经介绍过后台的TFS集群文件存储系统，在TFS前端，还部署着200多台图片文件服务器，Apache实现，用于生成缩略图的运算。
值得一提的是，根据淘宝网的缩略图生成规则，缩略图都是实时生成的。这样做的好处有两点：一是为了避免后端图片服务器上存储的图片数量过多，大大节约后台存储空间的需求，我们计算过，采用实时生成缩略图的模式比提前全部生成好缩略图的模式节约90%的存储空间。也就是说，存储空间只需要后一种模式的10%。二是，缩略图可根据需要实时生成，这样更加灵活。
图片文件服务器的前端则是一级缓存和二级缓存，前面还有全局负载均衡的设置，用于解决图片的访问热点问题。图片的访问热点一定存在，重要的是，让图片尽量在缓存中命中。目前淘宝网在各个运营商的中心点设有二级缓存，整体系统中心店设有一级缓存，加上全局负载均衡，传递到后端TFS的流量就已经非常均衡和分散了，对前端的响应性能也大大提高。据淘宝的缓存策略，大部分图片都尽量在缓存中命中，如果缓存中无法命中，则会在本地服务器上查找是否存有原图，并根据原图生成缩略图，如果都没有命中，则会考虑去后台TFS集群文件存储系统上调取。因此，最终反馈到TFS集群文件存储系统上的流量已经被大大优化了。
淘宝网将图片处理与缓存编写成基于Nginx的模块，我们认为，Nginx是目前性能最高的HTTP服务器，代码清晰，模块化非常好。淘宝网使用GraphicsMagick进行图片处理，采用了面向小对象的缓存文件系统，前端有LVS+Haproxy将原图和其所有的缩略图请求都调度到同一台Image Server（图片服务器）。
在文件定位上，内存用Hash算法做索引，最多一次读盘。另外会有很多相同的图片重复上传上来，去除重复文件也是采用Hash算法来做的。写盘方式则采用Append方式写，并采用了淘汰策略FIFO，主要考虑降低硬盘的写操作，没有必要进一步提高Cache命中率，因为ImageServer和TFS位于同一个数据中心，读盘效率还是非常高的。目前淘宝网的TFS已经开源（见code.taobao.org），业界的同仁可以一起使用和完善这个系统。
