淘宝数据库架构演进历程
淘宝技术架构介绍
·空间换时间 ·时间换空间
·效果和成本的平衡
V3.0 消息系统
·集群Topic方式 ·发送事务
操作 AA业PPP务P 系统
消息
AA消PPP息P 系统
AA后PPP续P
处理1
AA后PPP续P
处理2
AAP…PP…P
V3.0 可用性
·同城分流 ·异地容灾 ·n+1原则 主业务
可切换
边缘业务
主机房一
Weblogic
Function 2
Weblogic
Function 1
淘宝MVC
Weblogic
· 引入搜索引擎ISearch
淘宝MVC
Weblogic
EJB
淘宝MVC
EJB
淘宝MVC
OR-MapOpRin-gMapping EJB
EJBห้องสมุดไป่ตู้
OR-Mapping
OR-Mapping
Read/Write
PV 全网成交
0
2003 2004 2005 2006
V1.0
V1.1
V2.0
V2.1
2007 V2.2
2008 2009 V3.0
V1.0 2003.5 – 2004.1
· 非典时期 · 马云住宅 · LAMP · MySQL读写分离
FumncpAoteipdoaaF_nrcpuDhhnmeBpcpAot4eipdoaa_nrcpDhhF3euBpmn4cpAoteipdoaa_rncpDhFh2euBpmn4cpAoteipdoaa_nrcpDhh1eBp4
主机房二
数据同步
异地主机 房
V3.0 自动化
A:I wanna the fried chicken! B:Sir, we will be arriving at
淘宝商品体系架构的历史和演进
SDCC中国软件开发者大会电商架构专题淘宝商品体系架构的历史和演进汇报人：范围淘宝资深开发工程师目录C O N T EN T1淘宝体系架构的演进2淘宝商品架构3元数据在淘宝商品体系架构中的应用01淘宝体系架构的演进PART ONEWHY为什么要升级架构l●架构升级的目的•节约成本•提高收益l●淘宝商品体系架构随着业务的发展不断变迁•降低开发成本•提升开发效率•支持更灵活、复杂的业务电商系统发展的四个阶段WHAT石器时代单一业务系统中世纪分布式业务系统工业革命业务平台化未来业务中台化02淘宝商品架构PART TWO商品的特点1l●商品形态•实物、服务、虚拟、零售、分销、批发、供应链l●灵活的结构•基于不同的场景、视角和形态，商品千差万别l●稳定性和确定性•10亿+在线商品•亿级+条码•百万级+品牌卖家买家服务实物交易金额交易额价格交易量线上资质线下信用标签性别年龄地址商品淘宝商品结构2SPU标准产品单元Product商品SKU库存量单元营销价格库存时间地点物流市场规则规范效率个性描述描述信息特征标题多媒体图片地址库品牌库类目属性库行业属性产品要素卖家要素销售要素商品发布产品中心市场3商品生命周期前后台商品体系4商品数据流转5后台商品库后台类目标准属性……商品算法平台前台类目体系前台商品库前台类目集导购PV集……导购算法平台运营干预搜索导航用户行为配置类目属性商品发布平台治理后台类目体系运营平台数据推送服务版本化数据包前台类目属性服务数据治理服务03元数据在淘宝商品体系架构中的应用PART THREE1元数据驱动元数据•描述数据的数据元数据驱动架构•利用元数据来控制和实现应用的逻辑元数据一直都存在，并常被我们所使用•Java POJO•数据库Schema•配置信息理念-应用基础架构2•绝大多数应用采用经典Web结构•部分配置从代码中抽离出来单独管理•抽象比较好的业务提供运营平台，让运营、产品人员直接配置规则•新业务需求需要编码实现，周期以周记•通过接口接收请求、返回结果•调用初始化配置和逻辑•调用依赖应用获取数据•调用多种存储获取数据•应用根据请求执行计算逻辑，获得结果应用逻辑配置中心依赖应用依赖应用依赖应用MySql搜索KV 缓存理念-元数据驱动架构3——元数据驱动架构核心思想就是提高元数据使用比例应用逻辑配置中心依赖应用依赖应用依赖应用数据库搜索KV 缓存模型规则流程界面l 元数据包含:•模型：接口（API）、数据（DO对象）、存储（DB）•逻辑（基本能力）：组件化代码片段、脚本片段、规则、规则集•流程：组件选取、执行编排•界面：UI组件管理、可视化编辑•配置：开关、业务配置4元数据驱动的思路l●未来全局架构•不同角色的运营平台•控制逻辑配置和规则抽离•业务执行系统•三类数据：控制数据，基础数据，过程数据l●好处•通过动态配置改变应用执行逻辑，提高效率•业务和技术分离，PD、运营等非技术人员可以直接参与开发•逻辑和能力可视化好元数据驱动架构平台512 3 41 2 3 4/元数据引擎6l●元数据等同于代码，元数据修改等同于开发l●特性:–需要多版本、快照–需要继承、引用–事务、数据一致性–环境隔离(沙箱)–发布、回滚Trunk项目环境预发环境生产环境项目2日常1deploydeploydeploy日常2日常3S优点T挑战通过增加动态配置的比例，提高开发效率业务和技术分离，非技术人员可以参与开发逻辑和能力可视化好学习曲线、理念上的转变对于稳定性和性能方面有较高要求需要丰富的配套工具支撑此处添加副标题汇报人：某某此处添加主标题谢谢聆听。
淘宝网的架构演进
DB DB
Messaging
JBoss MVC Spring iBatis Remoting JBoss MVC Spring iBatis
DAL
运 行 状 况 监 测 和 报 警 系 统
Node1
Node2
Noden
Read/Write …… Node1 Node2 Noden
Tolerance of network Partition
Basically Availble
Soft-state Eventual Consistency
数据库减负
数据库能做的事
–存数据 –单条查询 –多表关联查询 –大量数据实时在线分析 –通过存储过程，函数来处理业务
简化方案
WebX介绍
Apache Turbine
–Servlet-based –MVC Pattern –Velocity/JSP –Turbine Services(Upload/Security) –Pipeline/Valve WebWork Spring
页面驱动开发
约定优于配置
发展阶段
备份 隔离 集群 分割 异步 去小型机去Oracle
拆分阶段
理论依据
–虚拟化 –CAP/BASE 基础设施 –去Oracle –Notify –HSF
CAP/BASE
ACID(atomicity/consistency/isolation/durability) Consistency Availability
Notify介绍
阿里数据库架构变迁与展望
淘宝初创
淘宝初创
淘宝初创
…… Auction Member Apache Search Apache Mod_php4 Apache Mod_php4 Apache Pear DB Mod_php4 Pear DB Mod_php4 Pear DB Pear DB 读 读写 读
MySQL Slave
单元化
OceanBase
新挑战 新机遇 -- 单元化
cdn1 cdn2
。。。
cdnN
按用户分流
中心
接入层 中心服务层 缓存层 数据层
单元1 同步调用 异步消息
接入层 服务层 缓存 层 数据层
单元2
接入层 服务层 缓存 层 数据层
单元N
接入层 服务层 缓存 层 数据层
数据同步
中心备份
单元化
新挑战 新机遇 -- 单元化
复制
MySQL Master
复制
MySQL Slave
淘宝初创
问题: 单机MySQL数据库迅速达到瓶颈 解法: MySQL迁移到Oracle，并逐步升级硬件，到小型机， 高端存储，最终形成IOE 架构
效果:
支撑了淘宝 2004 到 2009 发展高峰
辉煌时代--IOE
辉煌时代--IOE
新挑战 新机遇
全网架构 资源限制, 一个城市已经不能满足需求 容灾，单地域机房风险 AliSQL 分表数量庞大 集群拆分接近极限 业务开发复杂度 路由，关联，聚合，订正
单元化
OceanBase
新挑战 新机遇 -- OceanBase
Query Data 增删改
基线数据 (固态盘)
新挑战 新机遇 -- 单元化
单元化效益 稳定性
淘宝技术发展(Java时代：创造技术-TFS)-已发布
淘宝技术发展（Java时代：创造技术-TFS）在讲淘宝文件系统TFS之前，先回顾一下上面几个版本。
1.0版的PHP系统运行了将近一年的时间（2003.05-2004.01）；后来数据库变成Oracle之后（2004.01-2004.05，叫1.1版本吧），不到半年就把开发语言转换为Java系统了（2004.02-2005.03，叫2.0版本）；进行分库、加入缓存、CDN之后我们叫它2.1版本（2004.10-2007.01）。
这中间有些时间的重合，因为很多架构的演化并没有明显的时间点，它是逐步进化而来的。
在描述2.1版本的时候我写的副标题是“坚若磐石”，这个“坚若磐石”是因为这个版本终于稳定下来了，在这个版本的系统上，淘宝网运行了两年多的时间。
这期间有很多优秀的人才加入，也开发了很多优秀的产品，例如支付宝认证系统、招财进宝项目、淘宝旅行、淘宝彩票、淘宝论坛等等。
甚至在团购网站风起云涌之前，淘宝网在2006年就推出了团购的功能，只是淘宝网最初的团购功能是买家发起的，达到卖家指定的数量之后，享受比一口价更低的价格，这个功能看起来是结合了淘宝一口价和荷兰拍的另一种交易模式，但不幸没有支撑下去。
在这些产品和功能的最底层，其实还是商品的管理和交易的管理这两大功能。
这两大功能在2.1版本里面都有很大的变化。
商品的管理起初是要求卖家选择7天到期还是14天到期，到期之后就要下架，必须重新发布才能上架，上架之后就变成了新的商品信息（ID变过了）。
另外如果这个期间内成交了，之后再有新货，必须发布一个新的商品信息。
这么做有几个原因，一是参照拍卖商品的时间设置，要在某日期前结束挂牌；二是搜索引擎不知道同样的商品哪个排前面，那就把挂牌时间长的排前面，这样就必须在某个时间把老的商品下架掉，不然它老排在前面；第三是成交信息和商品ID关联，这个商品如果多次编辑还是同一个ID的话，成交记录里面的商品信息会变来变去；还有一个不为人知的原因，我们的存储有限，不能让所有的商品老存放在主库里面。
淘宝数据库架构演进历程及OceanBase架构
异地多数据中心的数据同步
杭州
other
青岛
异地多数据中心的数据同步
除了oracle dataguard,master-slave replication数据复制，我们 还有其它哪些可选方案？
淘宝自主数据库Oceanbase 淘宝自主数据库
动态数据与静态数据进行分离,动态数据采用集中式，静态数据 存放与服务采用分布式 设计了一个宽表，冗余数据，将离散型IO合并成连续型IO 每晚动态数据，与静态数据合并一次 将首先在收藏夹应用上试点
HSF的诞生 的诞生
中心化后面临另一个问题，服务调用者，与服务者之间如何进 行远程通信，淘宝HSF诞生,数据库一些OLTP join问题解决。
HSF A 服 务 B 服 务
数据垂直化
应用中心化之后，底层数据库系统按照不同的业务数据进行了 一系列的垂直拆分.此类拆分方式具有如下的特点： a. 拆分方式简单，只需要把不同的业务数据进行分离 b. 避免了不同的业务数据读写操作时的相互影响 c. 该业务内部及其所导致的问题依旧
C client端特性： a. 支持mysql master,slave主备切换，获取binlog不受影响 b. 自动重连主机 c. 支持checkpoint, 支持断点续传binlog Java端复制代码特性： a. 支持statement, row两种复制模式 b. 支持按规则复制 c. 支持一定条件下的并行复制 c. 支持checkpoint
水库模型
你的系统可以撑 多少？系统余量 还有多少？
数据库系统余量
两轮测试过程，确保上线稳定： 底层数据库环境性能，稳定性的基础测试，常用的工具可以采 用sysbench, orion, supersmack 选择不同的硬件，软件组合，模拟应用的压力测试，要超越当 前业务压力的几倍进行，这个压力的幅度可以根据自己的业务 增长设计一个合理的值。 我们如何做到用数据来说话？靠测试拿数据，不靠经验
淘宝技术架构
V3.0 改变
• 开始思考淘宝的本质 • 开始尝试从被动支支撑转换为主
动支支撑
• 从使用用技术开始大大幅过渡到创
造技术
• 服务化、稳定性、降低成本
V3.0 淘宝是什么
WebServer
AppServer
D Server
淘宝是一一个⺴网网站么，⺴网网站的本质是什么？
V3.0 淘宝是什么⺴网网站
淘宝技术架构进化之路
龚银
ABOUT ME
大大家最关心心的问题
• 淘宝的前期技术发展历程 • 淘宝的当前技术体系 • 淘宝下一一代技术体系展望
What is
Architect?
架构， Architect
—— 好的架构是进化出来的，不是设计出来的！ —— 不同时期和不同环境有不同的最佳架构！ —— 存在即合理，合适的才是最好的！
• 项⺫目目管理工工具 AntX • 引入入搜索引擎
ISearch
V2.1 2004.10 - 2007.1
……
• Weblogic • Weblogic • 抛弃
性能问题频现，成本高高 迁移至至 JBoss
EJB，引起 Spring
Fu2cti32 3 Fu2cti32 2 JB3ss Fu2cti32 JB3ss JB3ss 淘宝MVC JB3ss 淘宝MVC 淘宝MVC Spri2g 淘宝MVC Spri2g Spri2g OR-Mappi2g Spri2g OR-Mappi2g OR-Mappi2g OR-Mappi2g Read/Write
•
淘宝是一一个交易⺴网网站，核心心要素：要素(人人/物/合同)、过程(付款)、交流
•
功能需求：交易服务化
•
淘宝是一一个很大大的交易⺴网网站
淘宝在线交易数据演变
集群QPS：42万/秒 集群TPS：19万/秒
目标：4倍数据量下，支撑6倍现有系统压力
交易买家库去IOE硬件选型-Fusion IO
IOPS性能很高 寿命较长 稳定性比SSD好 较SSD成本高
交易买家库去IOE硬件选型-SSD
相对FIO便宜不少 满足买家库性能要求 极端情况稳定性较FIO差 极端情况稳定性较 差 极端情况稳定性较FIO差
考 虑 未 来 节 点 扩 展
分32逻辑库， 16台服务器 1024张表，尽量只对核心表作分库分表 减少各表事务依赖，把其它业务放到杂表库
交易买家库去IOE-新订单ID路由准备
买家ID后3，4位
订单ID
6323940234 79 64
Sequence 买家ID后两位
（1） 定位具体库 （2） 添加路由Tair，通过Tair拿到具体的买家ID （3） 新订单ID直接通过ID里的路由信息定位库和表 （4）老订单ID会随着历史库迁移，访问慢慢变少
一次淘宝购物之旅
一次淘宝购物之旅
第一步：找到想买的宝贝
一次淘宝购物之旅
第二步：查看宝贝详情
一次淘宝购物之旅
第三步：把想买的宝贝加入购物车
一次淘宝购物之旅
第四步：结算订单
一次淘宝购物之旅
第五步：付款
一次淘宝购物之旅
第六步：查看购买的宝贝
交易业务和系统结构介绍
淘宝交易数据库的组成结构
交易数据库
买家库(Oracle）
买家库(Mysql）
交易买家库去IOE-容灾方案
单库容灾切换
TDDL动态数据源切换（可批量切换） Mysql主库 Mysql备库
Mysql回切Oracle
程序开关切换 Oracle买家库 Mysql买家库
【架构师必看】淘宝从百万到千万级并发的14次服务端架构演进之路
【架构师必看】淘宝从百万到千万级并发的14次服务端架构演进之路# 概述本⽂以淘宝为例，介绍从⼀百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让⼤家对架构的演进有⼀个整体的认知，⽂章最后汇总了⼀些架构设计的原则。
# 基本概念在介绍架构之前，为了避免部分读者对架构设计中的⼀些概念不了解，下⾯对⼏个最基础的概念进⾏介绍：分布式系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat 分别部署在不同服务器上⾼可⽤系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有⾼可⽤性集群⼀个特定领域的软件部署在多台服务器上并作为⼀个整体提供⼀类服务，这个整体称为集群。
如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成⼀个整体提供集中配置服务。
在常见的集群中，客户端往往能够连接任意⼀个节点获得服务，并且当集群中⼀个节点掉线时，其他节点往往能够⾃动的接替它继续提供服务，这时候说明集群具有⾼可⽤性负载均衡请求发送到系统时，通过某些⽅式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的正向代理和反向代理系统内部要访问外部⽹络时，统⼀通过⼀个代理服务器把请求转发出去，在外部⽹络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理。
当外部请求进⼊系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。
简单来说，正向代理是代理服务器代替系统内部来访问外部⽹络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。
# 架构演进单机架构以淘宝作为例⼦，在⽹站最初时，应⽤数量与⽤户数都较少，可以把Tomcat和数据库部署在同⼀台服务器上。
淘宝技术架构发展总结
从个人到淘宝网仰观Java时代淘宝的技术发展(1)引言光棍节的狂欢“时间到，开抢！”坐在电脑前早已等待多时的小美一看时间已到2011年11月11日零时，便迫不及待地投身于淘宝商城一年一度的大型网购促销活动——“淘宝双11购物狂欢节”。
小美打开早已收藏好的宝贝——某品牌的雪地靴，飞快的点击购买，付款，一回头发现3000双靴子已被抢购一空。
小美跳起来，大叫一声“欧耶！”小美不知道，就在11日零点过后的这一分钟，全国有342万人和她一起涌入淘宝商城。
当然，她更不知道，此时此刻，在淘宝的一间办公室里，灯火通明，这里是“战时指挥部”，淘宝技术部的一群工程师，正在紧盯着的流量和交易数据。
白板上是他们刚刚下的注，赌谁能最准确地猜中流量峰值和全天的交易总额。
他们的手边放着充足的食物和各类提神的饮料。
一阵急促的声响起来，是前线部门询问数据的，工程师大声报着：“第1分钟，进入淘宝商城的会员有342万”。
过一会工程师主动拿起：“交易额超过1亿了，现在是第8分钟。
”接下来，“第21分钟，刚突破2亿”。
“第32分钟，3亿了”。
“第1个小时，4.39亿”。
这些数据随后出现在微博上，引起一片惊呼。
“完蛋了！”突然有人大喝一声，所有的眼睛都紧的盯着他，只见他挠挠头，嘿嘿的笑道“我赌的少了，20亿轻松就能过了，我再加5亿”，他跑去白板边上把自己的赌注擦去，写上25，接下来有人写上28，有人写上30，有人跑到微博上开下盘口，同事们纷纷下注。
接下来的这24个小时，战时指挥部的工程师们都不能休息，他们盯着的各种监控指标，适时的调整机器和增减功能。
顶住第一波高峰之后，这些人开始忙里偷闲的给自己买东西，大家互相交流着哪家买的移动硬盘靠谱，哪家衣服适合自己的女朋友，不时的有人哀嚎宝贝被人抢了、信用卡额度不够了。
同时，旁边白板上的赌注越下越大。
11月11日，这个棍子最多的日子被网民自我调侃的变成了一个节日——“光棍节”。
而淘宝网又用疯狂的折扣促销给它赋予了另外一个意义——“购物狂欢节”。
系统架构演进过程
系统架构演进过程高大上的淘宝架构我们以淘宝架构为例，了解下大型的电商项目的服务端的架构是怎样，如图所示上面是一些安全体系系统，如数据安全体系、应用安全体系、前端安全体系等。
中间是业务运营服务系统，如会员服务、商品服务、店铺服务、交易服务等。
还有共享业务，如分布式数据层、数据分析服务、配置服务、数据搜索服务等。
最下面呢，是中间件服务，如MQS即队列服务，OCS即缓存服务等。
图中也有一些看不到，例如高可用的一个体现，实现双机房容灾和异地机房单元化部署，为淘宝业务提供稳定、高效和易于维护的基础架构支撑。
这是一个含金量非常高的架构，也是一个非常复杂而庞大的架构。
当然这个也不是一天两天演进成这样的，也不是一上来就设计并开发成这样高大上的架构的。
这边就要说一下，小型公司要怎么做呢？对很多创业公司而言，很难在初期就预估到流量十倍、百倍以及千倍以后网站架构会是什么样的一个状况。
同时，如果系统初期就设计一个千万级并发的流量架构，很难有公司可以支撑这个成本。
因此，一个大型服务系统都是从小一步一步走过来的，在每个阶段，找到对应该阶段网站架构所面临的问题，然后在不断解决这些问题，在这个过程中整个架构会一直演进。
那我们来一起看一下。
1 单服务器-俗称all in one从一个小网站说起。
一台服务器也就足够了。
文件服务器，数据库，还有应用都部署在一台机器，俗称ALL IN ONE。
随着我们用户越来越多，访问越来越大，硬盘，CPU，内存等都开始吃紧，一台服务器已经满足不了。
这个时候看一下下一步演进。
2 数据服务与应用服务分离我们将数据服务和应用服务分离，给应用服务器配置更好的CPU，内存。
而给数据服务器配置更好更大的硬盘。
分离之后提高一定的可用性，例如Files Server挂了，我们还是可以操作应用和数据库等。
随着访问qps越来越高，降低接口访问时间，提高服务性能和并发，成为了我们下一个目标，发现有很多业务数据不需要每次都从数据库获取。
淘宝的核心技术及演变
淘宝的核心技术(国内乃至国际的Top，这还是2011年的数据)：拥有全国最大的分布式Hadoop 集群(云梯，2000左右节点，24000核CPU，48000GB 内存，40PB 存储容量)全国分布80+CDN 节点，能够自动找寻最近的节点提供服务，支持流量超过800Gbps 不逊于百度的搜索引擎，对数十亿商品进行搜索，全球最大的电商平台顶尖的负载均衡系统，顶尖的分布式系统，顶尖的互联网思想，功能多样运行极其稳定丰富的生态产业以及先进的数据挖掘技术……很多很多下面来看看淘宝技术演变过程。
马总在2003年4月7日秘密叫来阿里巴巴的十位员工，来到杭州一个隐秘的毛坯房，要求他们在一个月左右的时间内做出一个C2C 网站。
结果当然还是直接买的快，一个基于LAMP 架构的网站，原名是PHPAuction，老美开发的一个拍卖网站。
当然必须要做修改才能用。
2003年底，淘宝注册用户23万，PV 31万/day，半年成交额3371万。
很显然MySQL 无法撑得起如此大的访问量，数据库瓶颈出现了。
幸好阿里的DBA 队伍足够强大，他们使用Oracle 替代了MySQL。
Oracle 那时就已经有了强大的并发性访问设计——连接池，从连接池取连接的耗费比单独建立连接少很多。
但是PHP 当时并没有官方提供支持语言连接池特性，于是多隆前辈用Google(不会是Baidu)搜到了一个开源的SQL Relay，于是数据库软件方面的瓶颈暂时解决了。
随之而来的是面临硬件性能瓶颈，阿里买了EMC 的SAN 存储设备，加上Oracle 高性能RAC，硬件容量也暂时没问题了。
因为SQL Relay 的问题实在过于严重，2004年于是淘宝终于做出了跨时代的决策——使用Java重写网站。
淘宝请了Sun 的高级工程师来帮忙做Java 架构。
那么他们是如何做到修改编程语言而不改变网站使用呢——模块化替换，今天写好了A 模块，另开一个新域名，将连接指向该模块，同时别的模块不变，等到全部模块完成的时候，原域名放弃。
淘宝网数据库架构演变_4
拆分如何兼顾、解决多维度查询呢？
27
如何解决
两份数据 按照不同维度拆分，承担各自不同的业务场景。
框架： 两份数据+读写分离
28
现有架构
Aplication Application RW RW
主库2
主库1
1.引入读库集群 2.采用mysql和廉价pc服务器 3.采用1主多备来分摊读压力 4.业务进行分级
Isearch（搜索，实时搜索） Tair（基于key value的全内存系统） Tfs（taobao file system） Nosql（ Cassandra 。。。） Bigtable
17
做合适的事情
18
Agenda
• 数据库基本框架 • 数据库架构演变 • 案例：交易核心数据库演变关键点
Oracle基本框架
Aplication Aplication
出现硬件故障时，物理备库激活成为主 库，替代主库对外提供服务。
逻辑备库主要提供dw使用。
主库
物理备 库
逻辑备 库
Dw
3
MySQL基本框架
Aplication Aplication
M-S架构： M-M架构：
Aplication Aplication
Rjdbc+自动推送
主备数据库进行独立的管理，配置两个数据源。 数据源中哪一个是活跃的，取决于ConfigServer(配置中心)上的配置。
Configserver：
Agenda
• 数据库基本框架 • 数据库架构演变 • 案例：交易核心数据库演变关键点
初期架构
2003年： 快速开发 Mysql，pc服务器 oracle
Master
Slave
淘宝分布式数据层
–
–
–
•
异构读写分离
–
使用 ORACLE( 主 )-MYSQL( 读 ) 模式 主库 io 压力下降 50% 以上
–
2009~ 落地和发展
•
非对称数据复制的扩展
–
最初是解决一个 Master 需要对应多个 Slave 数据复制到多个目标 介质可以不同 分库分表规则可以不同 解决一条记录关联两个用户的按用户分库分表的问 题，比如评价
如果按照 userID 为 shardingKey, 那么根据 PrimaryKey 怎么对记录 进行操作？
•
路由规则后的路由表
•
看看这个 Url
–
/item.htm?id=7238421044
2010~ 重生
数据库架构的演进
分库分表 User
User 1
•
••Βιβλιοθήκη 小结小结•
SQL 解析，路由规则，数据合并 Client->DB 和 Client->Server-DB 模式 非对称数据复制 三层的数据源结构
•
•
•
未来
•
数据的写安全 动态平滑扩展 mysql 自身优化 ……
•
•
•
Thanks !
•
单击此处编辑母版文本样式
–
–
第二级
第三级
•
第四级 – 第五级
读写分离
User1-M
User1-S
User 2
User2-M
User2-S
2010~ 重生
之前的 Tddl ，从总体上管理业务使用的数据库整个集群
User1-M
User1-S
User2-M
淘宝网技术
高性能电子商务网站-淘宝网技术架构研究2008年淘宝的交易额是1000亿规模，2009年的时候是2000亿规模，2010年淘宝网的交易额4000亿规模，如何构建一个支撑这么大交易规模的高性能、并发的电子商务平台网站呢？以下结合网络资料，研究一下淘宝网的技术架构变迁。
淘宝网从2003年开始建立的，从1.0到1.5的版本.2005年开始2.0的版本，2012年4.0的版本上线。
马云的创业团队共10个人，马云以及他的秘书，8个里面有3个开发人员，三丰、多龙(音)、虚竹，还有UED的二当家，三位运营人员，小宝、阿柯和破天，总经理是财神。
团队开始研发是2003年4月7日，一个月后的5月10日淘宝第一个版本上线。
这段时间，创业团队关在小区里面写代码，每天早上9点到晚上1、2点。
淘宝网第一个版本MALT架构，采用PHP+MySQL首先花2000美金买了一个MALT架构网站，很精典的LAMP技术架构，刚开始的编程语言和数据库是PHP+MySQL，然后配套开发后台管理系统。
一开始部署在一台单机服务器上，流量增长后，把发邮件功能部署在一台机器上，后来再增加机器出来。
2004年MySQL撑不住了，数据存储的引擎很大缺点会锁表，一读的话把表锁住了，读的量一上来经常会锁掉，然后重启。
MySQL撑不住了，开始考虑换Oracle，除了Oracle强大之外还有一个原因是阿里巴巴那些年03、04年Oracle 人才积累达到非常强大的水平。
那时Oracle给全球的研发人员发一个称号“ACE”，那时全球三百多位，那时中国十来位，而阿里巴巴有三位。
阿里巴巴在Oracle方面能力非常强大。
换了Oracle有一个问题，PHP跟Oracle很不搭的东西，PHP一个用户访问过来建立一个连接切掉一个连接，而Oracle提供的连接数量非常有限的，因为有连接池的功能。
怎么用PHP来连接Oracle?我们就抄袭别人看，eBay用的太贵，没有用。
找了一个日本的，但是上了一个当，总重启。
手机淘宝构架演化实践
2014年12月19日~20日，ArchSummit北京2014大会顺利举行。
“移动互联网，随时随地”是非常火爆的一个专题。
阿里无线事业部技术负责人庄卓然（花名南天）任出品人。
来自阿里无线事业部的高级专家李敏分享了《手机淘宝架构演化实践》李敏主要负责淘宝无线客户端和无线网站基础服务、购物主链路的架构、研发方面的工作。
从09年开始参与手机淘宝研发团队的组建和线上产品研发，先后负责过无线部门的社区、会员、营销、交易等多条产品线的技术工作，构建和发展了阿里无线技术体系中包括交易链路、百亿级别高性能API网关、WebApp平台等多个重要技术产品，经历和见证了阿里巴巴无线从开始之初到成为日活上亿级别电商应用技术变迁和积累。
本文即根据李敏的演讲整理而成。
发展阶段从2009年开始，DAU从100万增长到超过1亿，面临的问题、包括研发支撑所需要解决的事情各不相同。
在用户量和业务复杂度的线性递增下，架构也进行了相应的演进。
如下图所示，具体可以分为四个阶段：∙第一阶段，手淘的前身WAP网站，业务初立、变化快，需要快速发布，采取HTML模板和单一应用，最大程度满足快速发布和修改的需要；甚至不需要改动后端的业务代码，在前面的模板上做一些修改就可以了。
∙第二阶段，DAU的快速增长，WAP/Android/iOS多个平台的业务起来了，需要在多个平台上进行快速的业务复制和业务管控，统一API网关出现。
∙第三阶段，DAU进一步增长，线上系统越来越多，业务的多样性需求更多的体现出来，基于HTML5的一整套解决方案上线，更多的HTML5和Native混合的业务形态，API 网关进行进一步优化和扩展，更方便的接入方式。
∙第四阶段，当DAU达到100M的时候，全集团的业务都需要在手淘透出，API网关被部署到更多的IDC机房，如何更有体系化的进行有效的研发、接入更多业务、并进行更有效的业务监控，需要更加体系化的架构治理。
API网关做WAP的时候没有所谓的API网关，为什么要用API网关呢？随着应用数量的增多，每个应用分别暴露的API出口很多，修改的话逻辑很复杂，这时候应该引入一个统一的网关。
淘宝网架构变迁和挑战
通用的基础产品
计算机组成
输入
设备 数据、程序
外存
数据、程序 输出
数据、程序 设备
内存
冯.诺依 曼型计 算机
运算 器
控制 器
CPU 计算机硬件结构图
主机
计算机系统的本质
数据处理 数据存储 数据访问
网站结构示意图
CDN
搜索 Cache 分布式存储 幵行计算平台 监控 运维平台
--- from
Application A
Application B
Application Programming Interface
• MOM的优点 – 松耦合 – 异步处理
Message Oriented Middleware
消息中间件
传统方式
do action Call A Call B
淘宝网架构变迁和挑战
About me
姓名:曾宪杰 花名:华黎 淘宝-产品技术-Java中间件团队 团队博客 /team/jm/ Sina微博 @曾宪杰_华黎 Twitter @vanadies10
内容提要
淘宝网架构的变迁 通用的基础产品 我们面临的挑战
太多的应用机器
需要数据库连接
有限的链接池
Oracle数据库
V3.0：产品化思维及服务导向框架 2007.10-2009.11
需求
支撑大型团队，丰富业务的幵行开发 软件模组化，中心化（用户，交易，商品，店铺，评价等），走向鬆耦 合 基础软件产品化 独立团队开发，做深，做大 从盖独立别墅到建造高楼大厦！
支撑高速的业务增长 快速扩容 （几十亿PV，几千亿GMV，几万台机器）
architecture_design
淘宝数据平台白皮书黄裳，菲青研发技术部2009年10月有效期至：2010年12月31日目录1. 背景和目地 (3)2. 范围 (4)3. 现有数据结构及需求 (4)3.1. 简单key/value（K-V）数据 (4)3.2. 复杂结构化数据 (5)3.2.1. 核心交易类系统 (5)3.2.2. 信息类系统 (5)3.2.3. 离线数据处理系统 (5)3.3. 数据需求总结 (6)4. 数据处理策略 (7)4.1. 逻辑在线数据处理策略 (7)4.1.1. 主数据(库)拆分 (8)4.1.1.1. 数据拆分原则 (9)4.1.2. 延迟写入（先写缓存再持久） (10)4.1.3. 读写分离 (11)4.2. 逻辑离线数据处理策略 (12)4.3. 物理存储系统选择策略 (13)4.3.1. Oracle数据库 (14)4.3.2. MySQL数据库 (14)4.3.3. 实时索引 (15)4.3.4. 飞天 (15)4.3.5. TFS (16)4.3.6. Tair/TDBM (17)5. 数据平台的角色与功能 (17)6. 一个数据决策辅助工具 (19)7. 结论 (20)1.背景和目地淘宝是一个高速发展、规模庞大的交易网站，对稳定性、容量，高可用性和扩展性有非常高的要求。
而在数据层面更是核心，可以理解高效，稳定，和可扩容的数据策略是淘宝网最重要的一个环节。
因此淘宝从03年创立开始至今，都不停的在为数据的优化做着不懈的努力。
以下是淘宝网“数据层”（这里的数据层是一个比较广的含义，表示数据的获取和存储）的一些关键时刻：03年，淘宝开始时使用MySQL数据库。
04年2月份，因为数据稳定性和容量的考虑，迁移到Oracle。
04年5月份，基于对未来扩展性和容量的要求，Oracle数据库拆分为DB1、DB2和DBC 三个数据库，其中DB1和DB2是同样类型的数据，按照一定规则进行拆分（水平拆分），DBC 和DB1/DB2是按照功能进行的拆分（垂直拆分）。
oceanbase 发展历程
oceanbase 发展历程
OceanBase数据库的发展历程如下：
一、诞生与初期发展：
1.2010年：OceanBase项目由阳振坤博士带领的初创团队在阿里巴巴集团内
部启动。
2.第一个应用场景是淘宝网的收藏夹业务，该业务具有高并发和大数据量的特
点，OceanBase通过独创的方法解决了大表连接小表的性能瓶颈问题。
二、产品演进与关键节点：
1.2012年：OceanBase发布了支持SQL的标准版本，标志着其从定制API库
转变为通用的关系型数据库系统。
2.2014年双11期间：OceanBase开始承担支付宝部分交易流量，初步验证了
其在金融级业务场景下的稳定性和高性能表现。
3.技术创新与突破：OceanBase在分布式架构上持续创新，推出“三地五中心”
城市级容灾新标准，提升了系统的可用性和可靠性。
三、商业化进程与行业认可：
1.随着技术成熟及业务规模扩大，OceanBase逐渐支撑起了包括蚂蚁集团（原
支付宝）在内的更多核心业务，并且在实践中不断优化和扩展能力。
2.在TPC-C和TPC-H基准测试中刷新记录，体现了其在联机事务处理（OLTP）
和决策支持系统（DSS）领域的世界级技术水平。
3.OceanBase逐步走向市场化，对外提供商业服务，为更多的企业客户解决大
规模、高并发、高可用性等数据库挑战。
总结来说，OceanBase自2010年以来，历经多年研发和实战考验，成长为一款国产自主可控的原生分布式数据库，在全球数据库领域内取得了显著的技术成果和市场地位。
- 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
用户
用户登陆事件数据(日志量90%)与用户主数据(日志量10%)分离 ，不仅要分表，而且要放到不同的数据库集群中,并且作好不同 数据等级的容灾处理。
用 户 主 信 息 用 户 信 息 扩 展 用户主信息数据库 集群
用 户 信 息
用户信息扩展数据 库集群
过度中心化
用户中心调用次数，高峰时期达到了每天60亿次，用户中心 的过度中心化问题越来越显著,成为各种操作的关键路径。
Follow me
Taobao dba 团队blog / 我的blog subject: Data & Architecture / 我的新浪微博:丹臣 /zhaolinjnu 我的msn: echo_lin@
一个小意外
Dataguard+mirror redo对写的影响比较大，临时删除远程的 redo member解决这个问题
MySQL源代码研究
我们主要从两方面着手：
MySQL内部，源代码熟悉，性 能优化，新增功能 MySQL外部，比如内部新增的一些功能： a.给innodb动态加数据文件 b.禁止新连接 c.表的访问统计 d.Innodb ssd加速 e.Mysql replication并行复制
不同的时期，不同的策略
正是因为如上的业务特点： 早期的淘宝前端应用系统，严重依赖于数据库系统 早期单机式的mysql的使用方式，在业务的高速发展下，很快 达到瓶颈 Mysql迁移到Oracle，并升级到小型机，高端存储后，几年的时 间里，满足了淘宝业务快速变化发展的需要。 我们的业务发展很快，但我们的技术没有成长
一些难题
数据库集群自动扩展仍然是个难题，但是是可以忍受的，底层 数据库集群经过评估，扩展的频率并不高。 MySQL DDL操作不便，锁表，对写操作影响较大，为了减少 影响，分了比较多的表，进一步加重了维护的负担。 其它。。。
光棍节大促
活动前，经过了充分的准备与系统评估工作：CDN面临的压力最大，预 估流量将会达到280G左右，准备了各个层面的系统降级方案。
大数据量核心业务数据迁移思路
采用两步走战略，不仅走得稳，而且走得好： 先采用异构的数据库读写分离,将数据复制到目标mysql各结点 ，不断切换应用相关的读服务到mysql结点上，验证可靠性， 机器压力，服务响应时间
将写压力从oracle结点迁移到mysql各结点，oracle停止写
对于一些不太核心，业务不太复杂，相关影响点不多的数据，可 以直接进行迁移。
多 表 关 联 Join
单 表 复 杂 查 询
主 键 查 询
淘宝电子商务网站的特点
高并发，PV13亿，光棍节促销PV达到了17亿 数据实时性要求高 数据准确性要求高 大多数页面属于动态网页 网站需要大量商品图片展示 用户通过搜索引擎，广告，类目导航寻找商品 网站读多写少，比例超过10:1 卖家相关的数据量较大，比如商品数，评价数 业务量快速增长
水库模型
你的系统可以撑 多少？系统余量 还有多少？
数据库系统余量
两轮测试过程，确保上线稳定：
底层数据库环境性能，稳定性的基础测试，常用的工具可以采 用sysbench, orion, supersmack 选择不同的硬件，软件组合，模拟应用的压力测试，要超越当 前业务压力的几倍进行，这个压力的幅度可以根据自己的业务 增长设计一个合理的值。
用户，商品，交易三大中 心的建设
HSF的诞生
中心化后面临另一个问题，服务调用者，与服务者之间如何进 行远程通信，淘宝HSF诞生,数据库一些OLTP join问题解决。
HSF
服 务 A 服 务 B
数据垂直化
应用中心化之后，底层数据库系统按照不同的业务数据进行了 一系列的垂直拆分.此类拆分方式具有如下的特点： a. 拆分方式简单，只需要把不同的业务数据进行分离 b. 避免了不同的业务数据读写操作时的相互影响 c. 该业务内部及其所导致的问题依旧
构建数据查询的高速公路
应用到DB的数据写入与查询从双向通行变成了单向通行，通行 效率更高，大大避免了相互影响。“借道行驶”的情况不再出现 。
跨不过去的坎
为什么不直接迁到MySQL上 面去呢？ a. 对于核心业务，停机时间 有限，宠大的数据无法短时 间内迁移 b.无法在短时间内完成项目 发布过程中的测试 c.没有搞过mysql分布式系统 ，对完全使用MySQL还没有 信心
设计了一个宽表，冗余数据，将离散型IO合并成连续型IO
每晚动态数据，与静态数据合并一次 将首先在收藏夹应用上试点
总结
架构就是用一些简单的道理，去解决问题
对多种技术，业务特征，细节都要有所了解，考虑周全
识别系统的主要问题，花80%的精力去解决80%的问题 架构都是有时效性的，需要不断探索或者接受新的思路
数据库架构发展新思路
异构数据库读写分离原始架构图（08年8月份）:
异构的读写分离
a. 写库为集中式的oracle环境,提供数据安全性保障 b. 读库使用mysql, 采用数据分片，分库分表，每台mysql放少 量的数据,单个数据分片内部采用mysql复制机制 c. 读库的超大memory容量，起到了很好的cache作用，在内存 中的数据查询性能远远高于在硬盘上的性能 d. oracle到多台mysql按规则复制，由TDDL完成 e. 分区键的选择至关重要，尽量让数据访问落在单台数据库上 g.利用好当前的高端硬件,保护好自己的投资
第二阶段 第三阶段
• MySQL迁到Oracle • Pc server升级到IBM小型机 • 低端存储升级到高端存储
• 核心业务从Oracle逐步迁到分布式MySQL集群中 • 大量采用pc server,采用本地硬盘
SQL语句变化
SQL语句复杂程度由繁到简的过程，折射出淘宝数据 架构的一些变化。
用户
商品
交易
评价
问题
单库IOPS 3w 单库连接数已经4k个了， 应用还在不断加机器？ 单库每秒SQL执行次数到 4w次 搜索dump数据缓慢，DW ETL缓慢
用硬盘来拼IOPS？
一台高端存储的处理能力
480块盘的hdisk，max IOPS 6w
注意应用可以接受的IO response time,以及 IOPS点。比如3w IOPS 以上，会达到20ms以上
商品中心 交易中心 评价中心
用户中心
Tair分布式缓存
Mysql集群
用户中心中的读写分离
在其它中心中内臵可以访问tair的客户端，大部份的读不需要经过用 户中心，直接读tair，写需要经过用户中心。
商品中心 交易中心 评价中心
用户中心
Tair分布式缓存
Mysql集群
交易的读写分离框架
主库按照买家拆分，读库按照卖家拆分。
我们如何做到用数据来说话？靠测试拿数据，不靠经验
数据库系统余量
数据生命周期之历史迁移
Online Data
Data
商品，交易，评价， 物流等数据都有自己的 生命周期。通过数据历 史迁移，减少在线库的 容量，提高在线库的性 能。
History Data
在线与历史应用分离
在线库与历史库重要等到级不同,在线库更高 同一应用的在线应用与历史应用分离 高级别的应用不能直接依赖于低级别的数据库
淘宝数据库架构演进历程
丹臣/赵林 数据架构师 2010-12-12
提纲
淘宝数据库发展的三个阶段 用户，商品，交易现在的架构 2010双11大促的挑战 MySQL源代码研究的一些思路 淘宝自主数据库Oceanbase原理介绍
淘宝的数据很美丽
淘宝数据库发展三阶段
第一阶段
• 整个网站采用LAMP架构 • 数据库采用几台MySQL • 应用系统分为前台，后台两大系统
Questions ?
异地多数据中心的数据同步
杭州
other
青岛
异地多数据中心的数据同步
除了oracle dataguard,master-slave replication数据复制，我们 还有其它哪些可选方案？
淘宝自主数据库Oceanbase
动态数据与静态数据进行分离,动态数据采用集中式，静态数据 存放与服务采用分布式
Online Application
History Application
Online Data Database
数据迁移程序
History Data Database