淘宝数据库架构演进过程
合集下载
淘宝发展历程
12
拍拍网正式运营 TOM公司于eBay成立合资公司
开创B2C新模式——“淘宝商城”
竞争对手的转变 业务的转变
四、2006年（转变）
13
“二手闲置”区
游戏点卡、充值卡、 机票等零售点
“促销”区
品牌店
个性小店
“全球购”
五、2007年（丰富）
14
背景
经融风暴席卷全球 政府及社会各界苦寻扩大内需之途径
对手强大
2、易趣继续收费政策、邮件式沟通
3、eBay易趣占据90%以上的市场份额
4、eBay易趣拥有良好的品牌优势和用户 基础
二、2003年
7
淘宝
1、考虑到非典对中国电子商务的影响 ——紧抓机遇 2、吸取经验，选择C2C模式
二、2003年
8
2004年前 还没有淘宝网的位置 在电子商务网 站CISI的排名
星辰急便公司合资应启对动京东淘商宝城大的物竞流争计；划——
物流宝；
作为大型B2C平台
急需创建独立品牌
1、11月正式启动淘宝商城独立域名，将淘宝商城
独立出来。
2、11月11日光棍节投入超过1亿的宣传推广巨资，
联合上千家传统和淘品牌商家，共同推出了光棍节
“五折促销”的活动。
活动促销，增加实际营
业额，并增强淘宝活力
10
调查数据显示，每天有 近900万人上淘宝网“逛街”。
商业工具向生活 工具转变
淘宝不仅仅是作为一个电子商务模式， 它将最终构成生活的基本要素。
四、2006年（转变）
11
淘宝网成为亚洲最大购物网站 中国网民突破1亿
中国消费增长率显著提高
竞争地位的转变
潜在用户规模的转 变
淘宝开放平台架构组件体系初探
/cn/news/2009/09/top-arch-components淘宝开放平台架构组件体系初探淘宝开放平台（TaoBao Open Platform，简称TOP）的整个架构体系是组件化体系架构，可以是很少的几个基础组件构成的Skeleton，也可以是融入了商业想象的Amazing Architecture。
这里就通过对于这些组件的罗列，描述出在TOP 这个大体系中，各个组件所处的地位及作用。
TOP的“兵器谱”是在现阶段商业需求及平台非业务性需求指导下形成的，未来TOP将继续发展，“兵器谱”也会不断演进。
下图是整个TOP当前的一个组件结构图：图中，红色虚线就是TOP的Skeleton。
TOP当前从业务模块功能角度来划分，可以分成三个层次：基础平台组件层，基础业务组件层，普通业务组件层。
基础平台组件层，倾向于平台级别功能满足及对平台稳定性，可用性的支持。
基础业务组件层，是介于平台服务于普通业务服务之间的组件，部分利用了平台基础组件层的组件，来抽象出一层公用业务服务组件，为业务组件提供通用的基础支持。
安全组件安全组件主要从四个角色去考虑整体的安全策略及具体的实施方案，这四个角色是：用户，应用，平台，服务。
平台本身的安全主要是基于在大并发和大流量的情况下，保证平台自身稳定性和可用性，同时也要兼顾在平台开放的服务不相互干扰和影响。
因此采取服务分流隔离机制，通过虚拟配置及软负载方式将服务请求动态分流和隔离，保证了服务之间相互的独立性，同时也充分利用TOP的能力。
频率控制及流量控制除了保护TOP自身不受到攻击，也为后端服务提供者作了天然的一个保护屏障，保证服务请求压力可以在TOP上可控，防止流量直接压倒服务提供者。
用户隐私安全在淘宝尤为重要，用户信息的安全性也在淘宝开放的过程中被放到了首位。
在开放平台设计中，除了采用普通开放平台的认证模式以外（OAuth类似流程），还在服务调用过程中通过区分应用角色来限制对于用户信息的获取和使用。
淘宝技术架构介绍, 了解淘宝,了解淘宝的架构需求
car
pipeline 页面布局
Screen Layout Control
多模板引擎
Jsp Velocity FreeMarker
V2.0 淘宝项目管理工具 AntX
类似maven 脚本编程语言 AutoConfig 依赖管理，冲突检测
V2.1 的需求
提高性能 增加开发效率 降低成本
V2.1 2004.10 – 2007.01
TBStore
Read/Write
Oracle Oracle Oracle Oracle
dump
Search
Read/Write
Node Node
1
2 ……
Node n
V2.1逻辑结构
表示层
Service
业务请求转发
Framework
S
UC
UC 业务流程处理 UC
UC
P
R
AO
AO
AO
AO
I
业务逻辑层
Node 1
Node 2
Node n
V2.1 TaobaoCDN
squid apache+php lighttpd 静态页面（包括php页面）、图片、描述 最初只有杭州和上海两个站点 现在发展到北京、广州、西安、天津、武
汉、济南等近10个站点 现在每天高峰期30G流量/秒
V2.1 session框架
Put/Get Data
Node 1
Node 2
Node n
V2.2 搜索引擎
垂直/水平 分割
AAPPPP
AAPPPP
Merge
Node1
Node2 ……
Node n
Col1
Node 1
pipeline 页面布局
Screen Layout Control
多模板引擎
Jsp Velocity FreeMarker
V2.0 淘宝项目管理工具 AntX
类似maven 脚本编程语言 AutoConfig 依赖管理，冲突检测
V2.1 的需求
提高性能 增加开发效率 降低成本
V2.1 2004.10 – 2007.01
TBStore
Read/Write
Oracle Oracle Oracle Oracle
dump
Search
Read/Write
Node Node
1
2 ……
Node n
V2.1逻辑结构
表示层
Service
业务请求转发
Framework
S
UC
UC 业务流程处理 UC
UC
P
R
AO
AO
AO
AO
I
业务逻辑层
Node 1
Node 2
Node n
V2.1 TaobaoCDN
squid apache+php lighttpd 静态页面（包括php页面）、图片、描述 最初只有杭州和上海两个站点 现在发展到北京、广州、西安、天津、武
汉、济南等近10个站点 现在每天高峰期30G流量/秒
V2.1 session框架
Put/Get Data
Node 1
Node 2
Node n
V2.2 搜索引擎
垂直/水平 分割
AAPPPP
AAPPPP
Merge
Node1
Node2 ……
Node n
Col1
Node 1
淘宝功能架构图ppt课件
SPU搜索
…搜索
1
介绍上图中提到的各个系统缩写意思
1.UIC: 用户中心(User Interface Center),提供所有用户信息相关的读写服务，如基本信息，扩展信息，社区信息，买卖家信用等级等等。 淘宝现在有两类卖家B 和C，这是通过在用户身上打不同的标签实现的，我们这次的无名良品卖家也是通过在用户身上打特殊的标签来区别于淘宝 已有的B 和C 类卖家。淘宝的TOP 平台已经开放了大部分的UIC 接口。 2.IC：商品中心(Item Center),提供所有商品信息的读写服务，比如新发商品，修改商品，删除商品，前后台读取商品相关信息等等，IC 是 淘宝比较核心的服务模块，有专门的产品线负责这块内容，IC 相关接口在TOP 中占的比重也比较大。 3.SC：店铺中心(Shop Center),类似中文站的旺铺，不过淘宝的SC 不提供页面级应用，提供的都是些远程的服务化的接口,提供店铺相关信 息的读写操作。 如：开通店铺，店铺首页，及detail 页面店铺相关信息获取，如店内类目，主营，店铺名称，店铺级别：如普通，旺铺，拓展版， 旗舰版等等。装修相关的业务是SC 中占比重较大的一块，现在慢慢的独立为一个新的服务化中心DC(design center),很多的前台应用已经通过直 接使用DC 提供的服务化接口直接去装修相关的信息。 4.TC：交易中心(Trade Center),提供从创建交易到确认收货的正 向交易流程服务，也提供从申请退款到退款完成的反向交易流程服务. 5.PC：促销中心(Promotion Center),提供促销产品的订购，续费，查询，使用相关的服务化接口，如：订购和使用旺铺，满就送，限时秒 杀，相册，店铺统计工具等等。 6.Forest：淘宝类目体系：提供淘宝前后台类目的读写操作，以及前后台类目的关联操作。 7.Tair：淘宝的分布式缓存方案，和中文站的Memcached 很像。其实也是对memcached 的二次封装加入了淘宝的一些个性化需求。 8.TFS：淘宝分布式文件存储方案(TB File System)，专门用户处理静态资源存储的方案，淘宝所有的静态资源，如图片，HTML 页面，文本 文件，页面大段的文本内容如：产品描述，都是通过TFS 存储的。 9.TDBM：淘宝DB 管理中心(TB DB Manager), 淘宝数据库管理中心，提供统一的数据读写操作。 10.RC：评价中心(Rate center),提供评价相关信息的读写服务，如评价详情，DSR 评分等信息的写度服务。 11.HSF：淘宝的远程服务调用框架和平台的Dubbo 功能类似，不过部署方式上有较大差异，所有的服务接口都通过对应的注册中心（config center）获取。
淘宝top平台架构 介绍
TOP架构设计实例分享
•服务分流与隔离
•原因：服务简单负载均衡造成服务互相影响。（根本原因 是服务的质量直接影响TOP处理能力和资源分配） •处理模式进化：
二级域名
软负载
软负载&虚 拟服务组
13
TOP架构设计实例分享
•服务分流与隔离
二级域名
• 隔离效果明显 • 配制僵化 • 性能基本无损失
软负载
– 作用
• 数据操作可控，保护终端用户隐私（结合cookie和标签，控制ISV业务数据操 作尺度，提高数据安全性） • 提供标准业务流程标签，简化开发者对于业务流程理解过程。 • 标签化接口方式，完成数据获取和页面渲染，后台业务升级对ISV透明化。 • 标签获取客户端信息，将监控扩展到整个业务请求过程。 • 制定行业化标签库，形成统一开发标准
APP
TOP
Service Provider
APP
业务数据交换通道
Service Provider
8
TOP架构Leabharlann 计实例分享• 异步交互服务 & 通知服务
• 保持会话，支持异步响应。（短信服务） • 异步延时服务。（大数据量信息返回）
• 订阅关系维护，支持通知服务。（系统间数据同步）
TOP架构设计实例分享
•
•
TOP商业驱动模式介绍
End User
插件分成
AppStore订购
开发者按业务分类
淘宝插件
店铺插件 淘宝SNS插件
免费TOP外部插件
社区插件 外部SNS插件
收费应用
客户端 独立WEB应用 新平台应用
自用型应用
独立网店 社区站点 导购网站
插件分成
动态广告
淘宝的发展历程课件
淘宝应对挑战的策略
拓展新业务领域
发展跨境电商、社交电商等新 业务，满足消费者多元化需求
，提高平台竞争力。
加强品质管控
建立严格的商家入驻和商品审 核机制，打击售假、刷单等行 为，维护公平竞争环境。
提升用户体验
优化购物流程、加强售后服务 、丰富互动体验等，提高用户 满意度和忠诚度。
推进技术创新
运用大数据、人工智能等技术 提升平台运营效率和商家服务
会创造了大量就业机会。
03
淘宝的多元化发展
淘宝的多元化战略
品类扩展
不断引入新的商品品类， 满足消费者日益多样化的 需求。
业务创新
推出特色市场、拍卖、闲 置交易等业务模式，丰富 平台生态。
跨界合作
与其他产业合作，打造跨 界产品和服务，拓宽商业 边界。
淘宝在金融、物流等领域的布局
金融服务
推出支付宝等金融服务产品，为 消费者和商家提供便捷安全的支
中国市场潜力
中国作为世界最大的消费 市场之一，拥有庞大的消 费者群体和购买力。
创始人马云
马云具有丰富的商业经验 和远见，他看到了电子商 务的巨大潜力，并决定创 立淘宝网。
淘宝初期的发展历程
01
02
03
04
2003年
淘宝网成立，开始运营C2C电 子商务平台。
2005年
引入第三方支付工具“支付宝 ”，解决网络交易信任问题，
利用先进技术
电商平台应利用先进技术，如人工智 能、大数据分析等，提高运营效率和 商家决策能力。
淘宝对全球电商行业的影响
01
推动电商行业快速发展
淘宝的成功经验为全球电商行业提供了借鉴和启示，推动了全球电商行
业的快速发展。
淘宝技术框架分析报告
淘宝技术框架分析报告淘宝作为国首屈一指的大型电子商务，每天承载近30亿PV的点击量，拥有近50PB的海量数据，那么淘宝是如确保其的高可用的呢？本文将对淘宝在构建大型过程中所使用到的技术框架做一个总结，并结合银行现有技术框架进展比照分析。
另外，本文还会针对金融互联网以及公司未来技术开展向给出个人看法。
淘宝技术分析CDN技术及多数据中心策略国的网络由于运营商不同〔分为电信、联通、移动〕，造成不同运营商网络之间的互访存在性能问题。
为了解决这个问题，淘宝在全国各地建立了上百个CDN节点，当用户访问淘宝时，浏览器首先会访问DNS效劳器，通过DNS解析域名，根据用户的IP将访问分配到不同的入口。
如果客户的IP属于电信运营商，那么就会被分配到同样是电信的CDN节点，并且保证访问的〔这里主要指JS、CSS、图片等静态资源〕CDN节点是离用户最近的。
这样就将巨大的访问量分散到全国各地。
另外，面对如此巨大的业务请求，任一个单独的数据中心都是无法承受的，所以淘宝在全国各主要城市都建立了数据中心，这些数据中心不但保证了容灾，而且各个数据中心都在提供效劳。
不管是CDN技术还是多个数据中心，都涉及到复杂的数据同步，淘宝很好的解决了这个问题。
银行现在正在筹建两地三中心，但主要目的是为了容灾，数据中心的利用率差，而淘宝的多个数据中心利用率为100%。
LVS技术淘宝的负载均衡系统采用了LVS技术，该技术目前由淘宝的章文嵩博士负责。
该技术可以提供良好的可伸缩性、可靠性以及可管理型。
只是这种负载均衡系统的构建是在Linux操作系统上，其他操作系统不行，并且需要重新编译Linux操作系统核，对系统核的了解要求很高，是一种软负载均衡技术。
而银行那么通过F5来实现负载均衡，这是一种硬负载均衡技术。
Session框架Session对于Web应用是至关重要的，主要是用来保存用户的状态信息。
但是在集群环境下需要解决Session共享的问题。
目前解决这个问题通常有三种式，第一个是通过负载均衡设备实现会话保持，第二个是采用Session复制，第三个那么是采用集中式缓存。
淘宝功能架构图ppt课件
淘宝客户群
淘宝直通车
淘
宝 广
广告DB
告
系
Dump数据
统
Build索引数据
广告点击消费
计费系统 JS调用广告展示
广告检索系统
DNS
ABTN网络
GTM分流 淘宝接入层
交换机 LB设备
淘宝客户群
DNS CDN系统
LB设备
站点缓存
静态页面
图片
DW部门 数据处理
TDDL/读写分 离Ibatis接口
打点/埋 点日志
SPU搜索
…搜索
1
介绍上图中提到的各个系统缩写意思
1.UIC: 用户中心(User Interface Center),提供所有用户信息相关的读写服务，如基本信息，扩展信息，社区信息，买卖家信用等级等等。 淘宝现在有两类卖家B 和C，这是通过在用户身上打不同的标签实现的，我们这次的无名良品卖家也是通过在用户身上打特殊的标签来区别于淘宝 已有的B 和C 类卖家。淘宝的TOP 平台已经开放了大部分的UIC 接口。 2.IC：商品中心(Item Center),提供所有商品信息的读写服务，比如新发商品，修改商品，删除商品，前后台读取商品相关信息等等，IC 是 淘宝比较核心的服务模块，有专门的产品线负责这块内容，IC 相关接口在TOP 中占的比重也比较大。 3.SC：店铺中心(Shop Center),类似中文站的旺铺，不过淘宝的SC 不提供页面级应用，提供的都是些远程的服务化的接口,提供店铺相关信 息的读写操作。 如：开通店铺，店铺首页，及detail 页面店铺相关信息获取，如店内类目，主营，店铺名称，店铺级别：如普通，旺铺，拓展版， 旗舰版等等。装修相关的业务是SC 中占比重较大的一块，现在慢慢的独立为一个新的服务化中心DC(design center),很多的前台应用已经通过直 接使用DC 提供的服务化接口直接去装修相关的信息。 4.TC：交易中心(Trade Center),提供从创建交易到确认收货的正 向交易流程服务，也提供从申请退款到退款完成的反向交易流程服务. 5.PC：促销中心(Promotion Center),提供促销产品的订购，续费，查询，使用相关的服务化接口，如：订购和使用旺铺，满就送，限时秒 杀，相册，店铺统计工具等等。 6.Forest：淘宝类目体系：提供淘宝前后台类目的读写操作，以及前后台类目的关联操作。 7.Tair：淘宝的分布式缓存方案，和中文站的Memcached 很像。其实也是对memcached 的二次封装加入了淘宝的一些个性化需求。 8.TFS：淘宝分布式文件存储方案(TB File System)，专门用户处理静态资源存储的方案，淘宝所有的静态资源，如图片，HTML 页面，文本 文件，页面大段的文本内容如：产品描述，都是通过TFS 存储的。 9.TDBM：淘宝DB 管理中心(TB DB Manager), 淘宝数据库管理中心，提供统一的数据读写操作。 10.RC：评价中心(Rate center),提供评价相关信息的读写服务，如评价详情，DSR 评分等信息的写度服务。 11.HSF：淘宝的远程服务调用框架和平台的Dubbo 功能类似，不过部署方式上有较大差异，所有的服务接口都通过对应的注册中心（config center）获取。
淘宝直通车
淘
宝 广
广告DB
告
系
Dump数据
统
Build索引数据
广告点击消费
计费系统 JS调用广告展示
广告检索系统
DNS
ABTN网络
GTM分流 淘宝接入层
交换机 LB设备
淘宝客户群
DNS CDN系统
LB设备
站点缓存
静态页面
图片
DW部门 数据处理
TDDL/读写分 离Ibatis接口
打点/埋 点日志
SPU搜索
…搜索
1
介绍上图中提到的各个系统缩写意思
1.UIC: 用户中心(User Interface Center),提供所有用户信息相关的读写服务，如基本信息，扩展信息，社区信息，买卖家信用等级等等。 淘宝现在有两类卖家B 和C，这是通过在用户身上打不同的标签实现的，我们这次的无名良品卖家也是通过在用户身上打特殊的标签来区别于淘宝 已有的B 和C 类卖家。淘宝的TOP 平台已经开放了大部分的UIC 接口。 2.IC：商品中心(Item Center),提供所有商品信息的读写服务，比如新发商品，修改商品，删除商品，前后台读取商品相关信息等等，IC 是 淘宝比较核心的服务模块，有专门的产品线负责这块内容，IC 相关接口在TOP 中占的比重也比较大。 3.SC：店铺中心(Shop Center),类似中文站的旺铺，不过淘宝的SC 不提供页面级应用，提供的都是些远程的服务化的接口,提供店铺相关信 息的读写操作。 如：开通店铺，店铺首页，及detail 页面店铺相关信息获取，如店内类目，主营，店铺名称，店铺级别：如普通，旺铺，拓展版， 旗舰版等等。装修相关的业务是SC 中占比重较大的一块，现在慢慢的独立为一个新的服务化中心DC(design center),很多的前台应用已经通过直 接使用DC 提供的服务化接口直接去装修相关的信息。 4.TC：交易中心(Trade Center),提供从创建交易到确认收货的正 向交易流程服务，也提供从申请退款到退款完成的反向交易流程服务. 5.PC：促销中心(Promotion Center),提供促销产品的订购，续费，查询，使用相关的服务化接口，如：订购和使用旺铺，满就送，限时秒 杀，相册，店铺统计工具等等。 6.Forest：淘宝类目体系：提供淘宝前后台类目的读写操作，以及前后台类目的关联操作。 7.Tair：淘宝的分布式缓存方案，和中文站的Memcached 很像。其实也是对memcached 的二次封装加入了淘宝的一些个性化需求。 8.TFS：淘宝分布式文件存储方案(TB File System)，专门用户处理静态资源存储的方案，淘宝所有的静态资源，如图片，HTML 页面，文本 文件，页面大段的文本内容如：产品描述，都是通过TFS 存储的。 9.TDBM：淘宝DB 管理中心(TB DB Manager), 淘宝数据库管理中心，提供统一的数据读写操作。 10.RC：评价中心(Rate center),提供评价相关信息的读写服务，如评价详情，DSR 评分等信息的写度服务。 11.HSF：淘宝的远程服务调用框架和平台的Dubbo 功能类似，不过部署方式上有较大差异，所有的服务接口都通过对应的注册中心（config center）获取。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库里的数据
第一，二阶段的单台数据库里，用户，商品，交易等数据都在一起， 存在许多的关联查询，应用完全耦合
商品 评价
用户
收藏 交易
连接数问题
小型机的内存有限，发现了Oracle数据库有连接数瓶颈， 5000个以后相当吃力。
太多的应用机器 需要数据库连接 有限的链接池
Oracle数据库
中心化，服务化
MySQL Binlog解析数据复制中心
解决商品，用户，评价，收藏夹等应用向数据仓库，搜索 增量同步数据的需求
MySQL Binlog解析数据复制中心
C client端特性： a. 支持mysql master,slave主备切换，获取binlog不受影响 b. 自动重连主机 c. 支持checkpoint, 支持断点续传binlog Java端复制代码特性： a. 支持statement, row两种复制模式 b. 支持按规则复制 c. 支持一定条件下的并行复制 c. 支持checkpoint
第二阶段 第三阶段
• MySQL迁到Oracle • Pc server升级到IBM小型机 • 低端存储升级到高端存储
• 核心业务从Oracle逐步迁到分布式MySQL集群中 • 大量采用pc server,采用本地硬盘
SQL语句变化
SQL语句复杂程度由繁到简的过程，折射出淘宝数据 架构的一些变化。
Questions ?
一些难题
数据库集群自动扩展仍然是个难题，但是是可以忍受的，底层 数据库集群经过评估，扩展的频率并不高。 MySQL DDL操作不便，锁表，对写操作影响较大，为了减少 影响，分了比较多的表，进一步加重了维护的负担。 其它。。。
光棍节大促
活动前，经过了充分的准备与系统评估工作：CDN面临的压力最大，预 估流量将会达到280G左右，准备了各个层面的系统降级方案。
水库模型
你的系统可以撑 多少？系统余量 还有多少？
数据库系统余量
两轮测试过程，确保上线稳定：
底层数据库环境性能，稳定性的基础测试，常用的工具可以采 用sysbench, orion, supersmack 选择不同的硬件，软件组合，模拟应用的压力测试，要超越当 前业务压力的几倍进行，这个压力的幅度可以根据自己的业务 增长设计一个合理的值。
构建数据查询的高速公路
应用到DB的数据写入与查询从双向通行变成了单向通行，通行 效率更高，大大避免了相互影响。“借道行驶”的情况不再出现 。
跨不过去的坎
为什么不直接迁到MySQL上 面去呢？ a. 对于核心业务，停机时间 有限，宠大的数据无法短时 间内迁移 b.无法在短时间内完成项目 发布过程中的测试 c.没有搞过mysql分布式系统 ，对完全使用MySQL还没有 信心
Online Application
History Application
Online Data Database
数据迁移程序
History Data Database
商品访问框架
淘宝商品的几个主要的查询： a.主键查询通过分布式数据库，以及分布式缓存系统解决 b.卖家商品管理类查询，这一类的查询数据量大，并且还有 like查询的需求，通过实时搜索解决 商品 主键 查询 分布式缓存 分布式数据库 注：考虑不同的读载体的技术实现，性能，成本 卖家 查询 实时搜索
用户，商品，交易三大中 心的建设
HSF的诞生
中心化后面临另一个问题，服务调用者，与服务者之间如何进 行远程通信，淘宝HSF诞生,数据库一些OLTP join问题解决。
HSF 服 务 A
服 务 BLeabharlann 数据垂直化应用中心化之后，底层数据库系统按照不同的业务数据进行了 一系列的垂直拆分.此类拆分方式具有如下的特点： a. 拆分方式简单，只需要把不同的业务数据进行分离 b. 避免了不同的业务数据读写操作时的相互影响 c. 该业务内部及其所导致的问题依旧
设计了一个宽表，冗余数据，将离散型IO合并成连续型IO
每晚动态数据，与静态数据合并一次 将首先在收藏夹应用上试点
总结
架构就是用一些简单的道理，去解决问题
对多种技术，业务特征，细节都要有所了解，考虑周全
识别系统的主要问题，花80%的精力去解决80%的问题 架构都是有时效性的，需要不断探索或者接受新的思路
多 表 关 联 Join
单 表 复 杂 查 询
主 键 查 询
淘宝电子商务网站的特点
高并发，PV13亿，光棍节促销PV达到了17亿 数据实时性要求高 数据准确性要求高 大多数页面属于动态网页 网站需要大量商品图片展示 用户通过搜索引擎，广告，类目导航寻找商品 网站读多写少，比例超过10:1 卖家相关的数据量较大，比如商品数，评价数 业务量快速增长
用户
用户登陆事件数据(日志量90%)与用户主数据(日志量10%)分离 ，不仅要分表，而且要放到不同的数据库集群中,并且作好不同 数据等级的容灾处理。
用 户 主 信 息 用 户 信 息 扩 展 用户主信息数据库 集群
用 户 信 息
用户信息扩展数据 库集群
过度中心化
用户中心调用次数，高峰时期达到了每天60亿次，用户中心 的过度中心化问题越来越显著,成为各种操作的关键路径。
淘宝数据库架构演进过程
丹臣/赵林 数据架构师
提纲
淘宝数据库发展的三个阶段 用户，商品，交易现在的架构 2010双11大促的挑战 MySQL源代码研究的一些思路 淘宝自主数据库Oceanbase原理介绍
淘宝的数据很美丽
淘宝数据库发展三阶段
第一阶段
• 整个网站采用LAMP架构 • 数据库采用几台MySQL • 应用系统分为前台，后台两大系统
数据库架构发展新思路
异构数据库读写分离原始架构图（08年8月份）:
异构的读写分离
a. 写库为集中式的oracle环境,提供数据安全性保障 b. 读库使用mysql, 采用数据分片，分库分表，每台mysql放少 量的数据,单个数据分片内部采用mysql复制机制 c. 读库的超大memory容量，起到了很好的cache作用，在内存 中的数据查询性能远远高于在硬盘上的性能 d. oracle到多台mysql按规则复制，由TDDL完成 e. 分区键的选择至关重要，尽量让数据访问落在单台数据库上 g.利用好当前的高端硬件,保护好自己的投资
用户
商品
交易
评价
问题
单库IOPS 3w 单库连接数已经4k个了， 应用还在不断加机器？ 单库每秒SQL执行次数到 4w次 搜索dump数据缓慢，DW ETL缓慢
用硬盘来拼IOPS？
一台高端存储的处理能力
480块盘的hdisk，max IOPS 6w
注意应用可以接受的IO response time,以及 IOPS点。比如3w IOPS 以上，会达到20ms以上
一个小意外
Dataguard+mirror redo对写的影响比较大，临时删除远程的 redo member解决这个问题
MySQL源代码研究
我们主要从两方面着手：
MySQL内部，源代码熟悉，性 能优化，新增功能 MySQL外部，比如利用binlog 做数据复制
MySQL源代码研究
内部新增的一些功能： a.给innodb动态加数据文件 b.禁止新连接 c.表的访问统计 d.Innodb ssd加速 e.Mysql replication并行复制
不同的时期，不同的策略
正是因为如上的业务特点： 早期的淘宝前端应用系统，严重依赖于数据库系统 早期单机式的mysql的使用方式，在业务的高速发展下，很快 达到瓶颈 Mysql迁移到Oracle，并升级到小型机，高端存储后，几年的时 间里，满足了淘宝业务快速变化发展的需要。 我们的业务发展很快，但我们的技术没有成长
我们如何做到用数据来说话？靠测试拿数据，不靠经验
数据库系统余量
数据生命周期之历史迁移
Online Data
Data
商品，交易，评价， 物流等数据都有自己的 生命周期。通过数据历 史迁移，减少在线库的 容量，提高在线库的性 能。
History Data
在线与历史应用分离
在线库与历史库重要等到级不同,在线库更高 同一应用的在线应用与历史应用分离 高级别的应用不能直接依赖于低级别的数据库
异地多数据中心的数据同步
杭州
other
青岛
异地多数据中心的数据同步
除了oracle dataguard,master-slave replication数据复制，我们 还有其它哪些可选方案？
淘宝自主数据库Oceanbase
动态数据与静态数据进行分离,动态数据采用集中式，静态数据 存放与服务采用分布式
Follow me
Taobao dba 团队blog / 我的blog subject: Data & Architecture / 我的新浪微博:丹臣 /zhaolinjnu 我的msn: echo_lin@
大数据量核心业务数据迁移思路
采用两步走战略，不仅走得稳，而且走得好： 先采用异构的数据库读写分离,将数据复制到目标mysql各结点 ，不断切换应用相关的读服务到mysql结点上，验证可靠性， 机器压力，服务响应时间
将写压力从oracle结点迁移到mysql各结点，oracle停止写
对于一些不太核心，业务不太复杂，相关影响点不多的数据，可 以直接进行迁移。
商品中心 交易中心 评价中心
用户中心
Tair分布式缓存