「淘宝網の技術、この十年を。」

「いたずら少しの時間、淘宝網は、大規模な」
マインドマッピング

ヒーロー

起因
資本アンチテーゼでのeBayイーベイ、アリは新しいプロジェクトの上昇を利用したいと思い
短時間で作ることができる必要となるサイトを取引する個人対個人の商品を（C2C）
2003年4月7 - 5月10日、月淘宝網の技術チーム購入プログラムを取ります

需求分析
自己|購入
： - ：|： -
時間のコストが高いので、使用しないでください|比較的低い維持費を必要とし、拡大と二次開発を促進し、軽量、シンプル

LAMP Linux+Apache+MySQL+PHP
長所：コンパイルする必要はありません、すぐに公開し、PHP言語は強力ですが、アクセスのすべてのページからレンダリングデータを行うことができ、およびオープンソース技術の利用は無料です

公式ウェブサイトを提供する淘宝網局システム：PHPAuction

购入后修改
自分のサイトのプロフィールとページテンプレート、ヘッダーとフッターを変更、背景管理機能を増やす;
データベース分割：分割をメインライブラリ+にしても、ライブラリ、および独立した読み取りおよび書き込みから

数据库拆分优点
ストレージ容量を増加し、バックアップの増加データセキュリティ、読み書き分離効率を向上させます

に判明淘宝網「の個人的なウェブサイト」

システムアーキテクチャ初版

システムの最初のバージョンは、商品は、公開、管理、検索、製品情報、購入の申し出、苦情を評価し、私の淘宝網と他の機能が含ま
系统改进
ユーザーの需要、トラフィックの増加、増加のリソースデータベース：背景
サーバー：1が3になりメール+データベース+ランランWebAppのの
データベース検索：インクリメンタルサーチのような→

问题短板
パフォーマンス不足のトラフィックと高騰データ量、著名なデータベース：
データはスレーブマスターに同期されている場合1、スレーブ書き込みはスレーブ操作が待つ必要が読んで、この時点で発生します。
頻繁に同期して得られた2-一方スレーブ主キーの競合は、クエリが失敗したように停止しました。

Daguaiのアップグレード

ショートボードの前述の問題が発生した場合には、アリは、技術的な解決策を提案している必要があります。

オラクルへのMySQL
ここで絵の説明を入力します。

Oracle
优点：容量大、稳定、安全、性能高
人才条件：阿里有顶尖团队

更换数据库

访问方式 + SQL语法 + 连接池设计（关键）

存在的问题

连接池
连接池中放的是长连接，是进程级别的，在创建进程的时候，要独占一分部分内存空间，这部分连接数在固定内存的Oracle server上是有限的，任何一个请求只需要从连接池中取得一个连接即可，用完后释放，不需要频发地创建和断开连接，要知道连接的创建与断开开销是非常大的。
PHP语言
对数据库的访问很直接，每一个请求都需要一个连接。如果是长连接，应用故武器增多时，连接数就多了，就会把数据库拖挂；而如果是短连接，频繁得连接再断开数据库性能会非常差

解决方案

开源的连接池代理服务 SQL Relay

遗留问题

SQL Relay死锁只能靠重启服务解决

存储扩容

NAS 数据库存储设备（Network Appliance）+ Oracle RAC（Real Application Clusters，实时应用集群）实现负载均衡
NAS的NFS文件系统协议传输延迟很严重↓
改用了Dell和EMC合作的SAN低端存储
数据量的增大→存储结点的不断拆分↓RAC出现问题
购买小型机

支付手段创新-支付宝

安全交易、第三方托管、开发与银行网关对接功能

交流方式创新-淘宝旺旺

脱胎换骨边换边跑

“好的架构图充满美感”。第二幅架构图显得头重脚轻，不是个稳定的版本，打怪的时候还是留下了祸根，SQL relay的问题无法解决，数据库必须使用oracle。

换开发语言 PHP → JAVA

JAVA
成熟的网站开发语言比较良好的企业开发框架开发经验人才多后续维护成本比较低有很多现成的连接池
Sun公司
创建java语言的开发公司，eBay的网站也经历过从C++到java的类似开发语言换骨，也是由Sun公司完成的。淘宝也请了Sun公司为淘宝主刀

要求

迁移过程中不停止服务，原系统的bugfix和功能改进不受影响。

方案

给业务分模块，一个一个模块地渐进式替换。如用户模块，老的member.taobao.com继续维护，不添加新功能，新的功能先在新的模块上开发，跟老的共用一个数据库，开发完毕之后放到不同的应用集群上，另开个域名 member1.taobao.com，同时替换老的功能，替换一个，把老的模块上的功能关闭一个，逐渐的把用户引导到 member1.taobao.com，等所有功能都替换完毕之后，关闭 member.taobao.com。

小问题
二级域名member1.taobao.com应该是个过度状态，但却很难把member1切换回member，因为有些地方连接已经写死了

开发模式

Java MVC struts1.x
在多人协作方面有很多致命弱点，没有轻量框架作为基础，很难扩展
WebX
阿里巴巴周悦虹在 JAkarta Turbine 的基础上做了很多扩展打造了一个阿里巴巴自己用的MVC框架 WebX。该框架易于扩展方便组件化开发，页面模板支持 JSP 和 Velocity ，持久层支持ibatis 和 hibernate 等，控制层可以用EJB和Spring

性能容量成本的进化

数据库扩展
Oracle “分库分表”：把用户的信息按照ID来存放到两个数据库汇总DB1DB2，把商品信息和卖家信息放在两个对应的数据库里面，把商品类目等通用信息放在第三个库里面(DBcommon)。这么做的目的除了增加了数据库的容量之外，还有一个就是做容灾，万一一个数据库挂了，整个网站上还有一半的数据能操作。　　
数据的合并、排序、分页
DBRoute，统一数据的合并、排序、分页，该框架一直延续在Oracle时段。
Spring
EJB → Spring 系统精简了代码
缓存 CDN（内容分发网络）
缓存初型：Berkeley DB缓存系统，该缓存系统性能比较弱，存放不太变动的只读信息。
CDN 起初采用China Cache 后改用自己开发的CDN

脱胎换骨架构图

去IOE （IBM小型机 Oracle EMC存储）

创新技术

“用钱能解决的问题都不是问题” 业务推动创新创新推动业务

淘宝文件系统TFS

商用存储系统的局限
1 没有对小文件存储和读取环境进行针对性优化
2 文件数量大网络存储设备无法支撑
3 系统所连接服务器越来越多
4 商用存储系统扩容成本高，存在单点故障，容灾和安全性无法得到保障

商用系统和自主研发之间的经济效益对比
1 商用软件很难满足大规模系统的应用需求，无论存储还是CDN还是负载均衡，因为在厂商实验室端，很难实现如此大的数据规模测试。
2 研发过程中，将开源和自主开发相结合，会有更好的可控性，系统出问题了，完全可以从底层解决问题，系统扩展性也更高。
3 在一定规模效应基础上，研发的投入都是值得的。上图是一个自主研发和购买商用系统的投入产出比对比，实际上，在上图的交叉点左边，购买商用系统都是更加实际和经济性更好的选择，只有在规模超过交叉点的情况下，自主研发才能收到较好的经济效果。实际上，规模化达到如此程度的公司其实并不多，不过淘宝网已经远远超过了交叉点。

TFS存储需求
　文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾能备份。应对这种需求，显然要用分布式存储系统；由于文件大小比较统一，可以采用专有文件系统；并发量高，读写随机性强，需要更少的 IO 操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。
　参照GFS 产生的TFSv1.0：
　大专栏 “淘宝技术这十年”mark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="TFS 1.0"/>
　
4 自主研发的系统可在软件和硬件多个层次不断的优化。

在这个架构中：
　　• 每个 Data Server 运行在一台普通的 Linux 主机上
　　• 以 block 文件的形式存放数据文件(一般64M一个block )
　　• block 存多份保证数据安全
　　• 利用 ext3 文件系统存放数据文件
　　• 磁盘 raid5 做数据冗余
　　• 文件名内置元数据信息，用户自己保存TFS文件名与实际文件的对照关系 – 使得元数据量特别小。

淘宝 TFS 文件系统在核心设计上最大的取巧的地方就在，传统的集群系统里面元数据只有1份，通常由管理节点来管理，因而很容易成为瓶颈。而对于淘宝网的用户来说，图片文件究竟用什么名字来保存实际上用户并不关心，因此TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息，例如图片的大小、时间、访问频次等等信息，包括所在的逻辑块号。而在元数据上，实际上保存的信息很少，因此元数据结构非常简单。仅仅只需要一个fileID，能够准确定位文件在什么地方。
由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的目录树结构，因为目录树开销最大。拿掉后，整个集群的高可扩展性极大提高。实际上，这一设计理念和目前业界的“对象存储”较为类似，淘宝网 TFS 文件系统已经更新到 1.3 版本，

TFS1.3重点改善
心跳和同步性能、元数据存储在内存中，清理磁盘空间等
性能优化：

采用ext4文件系统 并且预分配文件 减少ext3等文件系统数据碎片带来的性能损耗；
单进程管理单块磁盘的方式，摒除RAID5机制
带有HA机制的重要控制节点，在安全稳定和性能复制度之间取得平衡
缩减元数据大小，将更多的元数据加载如内存，提升访问速度
跨级计啊和IDC负载均衡及冗余安全策略
完全平滑扩容

图片文件服务器
部署在TFS前端，用Apache实现，缩略图实时生成
1 避免后端图片服务器上存储的图片数量过多，大大节约了后台存储空间的需求
2 缩略图可实时生成，更加灵活
3 采用一级缓存和二级缓存，前面还有全局负载均衡的设置

淘宝网缓存策略：淘宝网在各个运营商中心点设有二级缓存，整体系统中心店设有一级缓存，加上全局负载均衡，传递到后端的TFS流量就已经非常均衡和分散了，对前端的响应性能也大大提升。淘宝大部分图片都尽量在缓存中命中，如果无法命中，则在本地服务器上查找手否存有原图，并根据原图生产缩略图，如果都没有命中，则考虑去后台TFS集群文件存储系统上调取。

st=>start: Start
op1=>operation: 缓存中查找
cond1=>condition: Yes or No?
op2=>operation: 本地服务器上查找
cond2=>condition: Yes or No?
sub3=>subroutine: 后台TFS集群文件查找
e=>end

st->op1->cond1
cond1(yes)->e
cond1(no)->op2(right)->cond2
cond2(yes)->e
cond2(no)->sub3->e

淘宝KV缓存系统Tair

TBStore 分布式算法实现
根据保存的Key关键字，对key进行Hash算法，取得Hash值，再对Hsah值与总Cache服务器数据取，找到服务器列表中下表为此值的Cache服务器。由Java Client API封装实现
TBstore优缺点
它是基于Berkeley DB缓存系统的，而Berkeley DB在数据量超过内存的时候，就要往磁盘上写数据了，所以，它是可以做持久化存储的。但是一旦往磁盘写入数据，作为缓存的性能就大幅度下降

UIC （User Information Center）缓存系统 TDBM
数据全部放在内存中，改进了TDBM的集群分布方式，在内存利用率和吞吐量方面又做了大幅度提升

TDBM TBStore 的数据接口和用途都十分相似，二者合并推出即
Key-Value缓存系统（Tair，Taobao Pair，Pair即Key-Value数据对）
1 Tair包括缓存和持久化两种存储功能。
2 分布式系统：由一个中心控制节点Config Server和一系列服务节点Data server组成。
3 Config Server负责管理所有的Data Server，维护其状态信息。Data server对外提供各种数据服务，并以心跳形式将吱声的状况汇报给Config Server。
4 Config server是控制点，而且是单点，目前采用一主一备来保证其可靠性。所有Data Server 地位等价。

阿里自研大规模分布式缓存服务 Tair 模块详解

浴火重生

淘宝网的技术发展史（三）——分布式时代

服务化

catserver和hesper 类目属性服务化
高内聚低耦合业务的拆分和耦合

中间件

High-Speed Service Framework实时调用的中间件（淘宝的HSF，高性能服务框架）
分布式服务框架HSF
分析分布式服务框架
 基于OSGi实现分布式服务框架历程
分布式消息中间件系统 一种是异步消息通知的中间件（淘宝的Notify）

分布式数据访问层TDDLTaobao data distribution layer

1
2
3

数据访问路由-将针对数据的读写请求发送到最合适的地方；
数据的多项非对称复制-一次写入，多点读取;
数据存储的自由扩展-不再受限于单台机器的容量瓶颈与速度瓶颈，平滑迁移

安定した「鉄道模型」
クラスタ：クラスタは、スケーラブルなアプリケーションのレベルでのサポートのレベルに制限することができ、クラスタサイズは通常、スケジューリング、データベース、エンジンルームや他に限定される
分業：関与の機能とデータベースによって異なるスプリットがあります。スプリットとどの面に2つの課題の相互作用の後に分割するかのサブシステムなど、。
に従ってリソースのQoSの割り当てをロード・バランシング

セッションフレームワーク

セッション記述が表示される場合がありグラフィカルなHTTPの研究ノート
：セッション共有の問題を解決する
1ハードウェアの負荷は、特定のサーバーへのユーザー要求を分散する
2セッションレプリケーションは、クラスタ内のすべてのサーバーへのユーザーのセッションをコピーすることです

欠点は
高コスト、パフォーマンスの低下、トラフィックが増加し、増加した帯域幅は、マシンの数を増加させたときに、ネットワーク上の負担が指数関数的に増加します

Tbsession
1セッションクライアントのメモリ、セッション情報をクライアントブラウザ上のクッキーに保存されている
2、サーバ・ストレージを実現するクッキーの使用を減らす、ユーザー情報のセキュリティを強化する、放浪のペアクッキーの数とサイズ制限回避
までの3セッション構成統合管理を、集中管理サービスの利用およびクライアント側のセッションクッキーと効果的な規制にするためにクッキーを使用して
4つのサポート動的更新を、セッション構成を動的に更新します

オープンプラットフォーム

HadoopのMemcachedの??

サービスルーティング（外部内部の情報を得ることができます）

httpAgent面白いを書きます

サービス・インタフェースの標準化（均一に各種情報へアクセス標準）

テキストオブジェクト（JSON XML）

許可（内部情報の外部への正当なアクセス）

OAuthプロトコル

[参考リンク] 「淘宝網の技術、この十年、」研究ノート