大型互联网应用系统技术方案

遇到挑战一

淘宝网的商品照 片，尤其是热门商品图片的访问流量是非常大的。在淘宝网整体 流量中，图片的访问流量要占到 90%以上，而且这些图片平均大 小为 17.45KB，小于 8KB 的图片占整体图片数量的 61%，占整体系 统容量的 11%。这么多的图片数据、这么大的访问流量，给淘宝 网的系统带来了巨大的挑战。对于大多数系统来说，最头疼的就 是大规模的小文件存储与读取，因为磁头需要频繁寻道和换道， 因此，在读取上容易带来较长的延时。在大量高并发访问量的情 况下，简直就是系统的噩梦。

解决方案：

TFS 系统，在生产环境中应用的集群规 模达到了 200 台 PC Server（146GB×6 SAS 15KB Raid5），文件数 量达到上亿级别；系统部署存储容量为 140TB；实际使用存储容 量为 50TB；单台支持随机 IOPS 200+，流量为 3MB/s。

在这个系统中：  每个 Data Server 运行在一台普通的 Linux 主机上； 以 Block 文件的形式存放数据文件（一个 Block 的大小一般为 64MB）；  Block 存储多份是为了保证数据安全；5353 第二部分：淘宝技术发展 2 y 利用 ext3 文件系统存放数据文件；  磁盘 raid5 做数据冗余；文件名内置元数据信息，用户自己保存 TFS 文件名与实际文 件的对照关系，这使得元数据量特别小。

遇到挑战二

以往的数据缓冲服务器和信息传送服务以 “页”为单位制作，复制到数据缓冲服务器中，这用于处理静态 页面很有效，但在面对动态内容的时候，就很难得到高效率。一个大卖家的商品和店铺，一天的浏览量可 能是几百万个，一个小卖家的可能只有几个，那么这个大卖家的 用户信息要是每次都从数据库中读取，显然不划算，要是把这个 信息放在内存中，每次都从内存里取，性能要好很多。

解决方案

推出了淘宝自创的 Key-Value 缓存系统——Tair

Tair 作为一个分布式系统，由一个中 心控制节点和一系列的服务节点组成，我们称中心控制节点为 Config Server，服务节点是 Data Server。Config Server 负责管理所 有的 Data Server，维护 Data Server 的状态信息。Data Server 对外 提供各种数据服务，并以心跳的形式将自身的状况汇报给 Config Server。Config Server 是控制点，而且是单点，目前采用一主一备 的形式来保证其可靠性。所有的 Data Server 地位都是等价的。

遇到挑战三

业务分拆之后，系统之间还是必须 要打交道的，越往底层的系统，调用它的客户越多，这就要求底 层的系统必须具有超大规模的容量和非常高的可用性。另外，拆 分之后的系统如何通信？

解决方案

这里需要两种中间件系统，一种是实时 调用的中间件（淘宝的 HSF，高性能服务框架），一种是异步消 息通知的中间件（淘宝的 Notify）。另外，一个需要解决的问题 是用户在 A 系统登录后，到 B 系统的时候，用户的登录信息怎么保 存？这又涉及一个 Session 框架。

中间件系统架构

这就是 HSF 的设计思想，服务的提供者启动时通过 HSF 框架 向 ConfigServer（类似超市的电视机）注册服务信息（接口、版 本、超时时间、序列化方式等），这样 ConfigServer 上面就定义 了所有可供调用的服务（同一个服务也可能有不同的版本）；服 8686 淘宝技术这十年务调用者启动的时候向 ConfigServer 注册对哪些服务感兴趣（接 口、版本），当服务提供者的信息变化时，ConfigServer 向相应 的感兴趣的服务调用者推送新的服务信息列表；调用者在调用时 则根据服务信息的列表直接访问相应的服务提供者，而无须经过 ConfigServer。我们注意到 ConfigServer 并不会把服务提供者的 IP 地 址推送给服务的调用者，HSF 框架会根据负载状况来选择具体的 服务器，返回结果给调用者，这不仅统一了服务调用的方式，也 实现了“软负载均衡”。平时 ConfigServer 通过和服务提供者的心 跳来感应服务提供者的存活状态。

Notify

分布式的消息中间件系 统，支持消息的订阅、发送和消费。

遇到挑战四

如果按照业务的发展规模和速度，那 么使用高端存储和小型机的 Oracle 存储的成本将难以控制，于是 降低成本就成了必然。

解决方案

TDDL 数据拆分系统

 对外统一一切数据访问；支持缓存、文件存储系统； 能够在 Oracle 和 MySQL 之间自由切换；支持搜索引擎