淘宝网数据库架构演变_4
淘宝商品体系架构的历史和演进
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介绍
淘宝的架构
淘宝的架构淘宝用的是JBoss,框架是iBATIS,缓存服务器是自己开发的,基本遵循SNA架构,水平扩展,数据库是Oracle,阿里集团的DBA几乎是国内最强悍的。
目前淘宝的系统架构正在重构,计划用两到三年时间重写,目标有两个:1、水平扩展已经不满足需求了,还需要水平加垂直扩展2、开放API,让店家可以把外部网站资源集成到淘宝,不必直接在淘宝开店淘宝首席架构师是原来JBoss的Ben Wang,现在正在招募技术高手加盟,从事这项很有挑战性的工作:设计下一代开放性、支撑数十亿访问量的在线电子商务网站淘宝架构更详细的情况就不方便透露了。
淘宝网,是一个在线商品数量突破一亿,日均成交额超过两亿元人民币,注册用户接近八千万的大型电子商务网站,是亚洲最大的购物网站。
那么对于淘宝网这样大规模的一个网站,我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构,也会很想了解在淘宝网中是否采用了开源的软件或者是完全采用的商业软件。
那么下面我就简单的介绍一下淘宝网中应用的开源软件。
对于规模稍大的网站来说,其IT必然是一个服务器集群来提供网站服务,数据库也必然要和应用服务分开,有单独的数据库服务器。
对于像淘宝网这样规模的网站而言,就是应用也分成很多组。
那么下面,我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。
操作系统我们首先就从应用服务器的操作系统说起。
一个应用服务器,从软件的角度来说他的最底层首先是操作系统。
要先选择操作系统,然后才是操作系统基础上的应用软件。
在淘宝网,我们的应用服务器上采用的是Linux操作系统。
Linux操作系统从1991年第一次正式被公布到现在已? ? 走过了十七个年头,在PC Server 上有广泛的应用。
硬件上我们选择PC Server而不是小型机,那么Server的操作系统供我们选择的一般也就是Linux,FreeBSD, windows 2000 Server或者Windows Server 2003。
淘宝数据库架构演进历程及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 选择不同的硬件,软件组合,模拟应用的压力测试,要超越当 前业务压力的几倍进行,这个压力的幅度可以根据自己的业务 增长设计一个合理的值。 我们如何做到用数据来说话?靠测试拿数据,不靠经验
淘宝技术架构介绍, 了解淘宝,了解淘宝的架构需求
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
淘宝技术架构
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买家库
淘宝功能架构图ppt课件
2
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)获取。
手机淘宝App技术架构
真机实验室
发布之前,通过线下自动化驱动测试保障基本稳定性和性能。 SDK在运行阶段自动收集性能、稳定性问题
1
• • •
核心SDK 能力
检测组件 Galileo
• • • •
•
移动日志 tLog
安全模式 SafeMode 安全气垫 热修复 Hotfix 开关服务 Orange
测试完毕后,进行灰度发布。通过SDK和大数 据体系评估APP的质量,性能和用户的体验, 以及在多种机型,环境上问题的暴露。
超级App“淘宝”诞生之路
手机淘宝App技术架构
淘宝的移动互联网演进史
企业级移动开发平台EMAS
阿里巴巴移动场景最佳实践
手机淘宝演进历史(2008 - )
手淘早期的技术架构
技术限制业务发展
手机淘宝泛质量管理体系
线下 自动化保障
•
自动化驱动 性能度量: OnlineMonotor 稳定性度量: CrashReport 自定义事件度量: AppMonitor
37.5
Weex开发框架
手淘Android发布频次
客户端团队
>30天 7天
2013 2014
30
22.5
15
3-4天
2015
7.5
1.7次/天
2016
0
谢谢!
4
手机淘宝整体高可用保障机制
• •
• •
• •
淘宝的移动互联网演进史
企业级移动开发平台EMAS
阿里巴巴移动场景最佳实践
淘宝的移动互联网演进史
企业级移动开发平台EMAS
阿里巴巴移动场景最佳实践
超级App的架构设计
千人千面的技术支撑
淘宝的核心技术及演变
淘宝的核心技术(国内乃至国际的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 模块,另开一个新域名,将连接指向该模块,同时别的模块不变,等到全部模块完成的时候,原域名放弃。
51-电子商务网站(淘宝网)的系统架构解析
电子商务网站(淘宝网)的系统架构解析淘宝网,是一个在线商品数量突破一亿,日均成交额超过两亿元人民币,注册用户接近八千万的大型电子商务网站,是亚洲最大的购物网站。
那么对于淘宝网这样大规模的一个网站,我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构,也会很想了解在淘宝网中是否采用了开源的软件或者是完全采用的商业软件。
那么下面我就简单的介绍一下淘宝网中应用的开源软件。
对于规模稍大的网站来说,其IT必然是一个服务器集群来提供网站服务,数据库也必然要和应用服务分开,有单独的数据库服务器。
对于像淘宝网这样规模的网站而言,就是应用也分成很多组。
那么下面,我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。
操作系统我们首先就从应用服务器的操作系统说起。
一个应用服务器,从软件的角度来说他的最底层首先是操作系统。
要先选择操作系统,然后才是操作系统基础上的应用软件。
在淘宝网,我们的应用服务器上采用的是Linux操作系统。
Linux操作系统从1991年第一次正式被公布到现在已¾¬走过了十七个年头,在PC Server上有广泛的应用。
硬件上我们选择PC Server而不是小型机,那么Server的操作系统供我们选择的一般也就是Linux,FreeBSD,windows2000 Server或者Windows Server2003。
如果不准备采用微软的一系列产品构建应用,并且有能力维护Linux或者FreeBSD,再加上成本的考虑,那么还是应该在Linux和FreeBSD之间进行选择。
可以说,现在Linux和FreeBSD这两个系统难分伯仲,很难说哪个一定比另外一个要优秀很多、能够全面的超越对手,应该是各有所长。
那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉,这个熟悉一方面是系统管理方面,另外一方面是对于内核的熟悉,对内核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。
淘宝网数据库架构演变_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
淘宝技术架构演进之路
淘宝技术架构演进之路1.概述 本⽂以淘宝为例,介绍从⼀百到千万级并发情况下服务端架构的演进过程,同时列举出每个演进阶段遇到的相关技术,让⼤家对架构的演进有⼀个整体的认知,最后汇总⼀些架构的设计原则。
2.基本概念 在介绍架构之前,为了避免读者对架构设计中的⼀些概念不了解,下⾯对接个最基础的概念进⾏介绍:分布式系统中的对个模块在不同服务器上部署,即可成为分布式系统,如Tomcat和数据库分别部署在不同的服务器上,或者两个相同的Tomcat分别部署在不同的服务器上。
⾼可⽤系统中部分节点失效时,其他节点可以接替他继续提供服务,则可认为系统具有⾼可⽤性。
集群:⼀个特定领域的软件部署在多台服务器上并作为⼀个整体提供⼀类服务,这个整体成为集群;如Zookeeper中的Master和Slave分别部署在多台服务器上,共同组成⼀个整体提供⼏种配置服务。
在常见的集群中,客户端往往能链接任意⼀个节点获得服务,并且当集群中⼀个节点掉线时,其他节点往往能够接替他继续提供服务,这时候说明集群具有⾼可⽤性。
负载均衡:请求发送到系统时通过某些⽅式吧请求均匀的分发到多个节点上,使系统中每个节点能够均匀的出来请求负载,则认为系统是负载均衡的。
正向代理和反向代理:系统内部要访问外部⽹络时,统⼀通话⼀个代理服务器吧请求转发出去,在外部⽹络来看就是代理服务器发起的访问,此时代理服务器实现的是正向代理;当外部请求进⼊系统时,代理服务器吧该请求转发到系统中某台服务器上,对外部请求来说,与之交互的只有代理服务器,此时代理服务器实现的是反向代理。
简单来说,正向代理就是代理服务器代替系统内部来访问外部⽹络的过程,反向代理就是外部系统请求访问系统时通过代理服务器转发到内部服务器的过程。
3.架构演进3.1.单机架构 以淘宝为例,在⽹站最初期,应⽤数量与⽤户数量都较少,可以吧Tomcat和数据库部署在同⼀台服务器上。
浏览器往 发起请求时,⾸先经过DNS服务器(域名系统)吧域名解析转换为实际IP地址10.102.1.4,浏览器转⽽访问该IP对应的Tomcat。
淘宝网技术
高性能电子商务网站-淘宝网技术架构研究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用的太贵,没有用。
找了一个日本的,但是上了一个当,总重启。
淘宝网架构变迁和挑战
通用的基础产品
计算机组成
输入
设备 数据、程序
外存
数据、程序 输出
数据、程序 设备
内存
冯.诺依 曼型计 算机
运算 器
控制 器
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,几万台机器)
淘宝海量数据产品技术架构
淘宝海量数据产品技术架构回顾关系型数据库仍然是王道分库分表、冷热分离NoSQL是SQL的有益补充用冗余避免网络传输和随机读用中间层隔离前后端异构数据源的整合缓存是系统化的工程数据一致性、穿透与雪崩矛盾之美SQLNoSQL计算时机“预算”Hadoop/实时计算引擎“现算”MySQL+中间层Hbase+中间层计算场所本地MySQL单机HbaseRegionServer集中MyFOX中间层Prom中间层数据存储冷7200SATA盘HDFS热15000SAS盘+缓存HDFS+缓存谢谢淘宝海量数据产品技术架构张轩丞(朋春)淘宝网-数据平台与产品部关于张轩丞(朋春)淘宝数据平台与产品部(杭州)vi党,脚本语言爱好者关注NodeJS,cnode社区组织者之一*******************:我是aleafs数据平台与产品淘宝网淘宝卖家供应商消费者搜索、浏览、收藏、交易、评价...一些数字淘宝主站:30亿店铺、宝贝浏览10亿计的在线宝贝数千万量级交易笔数数据产品:50G统计汇总结果千万量级数据查询请求平均20.8ms的响应时间(6月1日)海量数据带来的挑战计算计算的速度处理吞吐量存储存储是为了更方便地查询硬盘、内存的成本查询“大海捞针”全“表”扫描架构总览主站备库RAC主站日志数据源MyFOXProm存储层数据中间层/glider查询层数据魔方淘宝指数开放API产品Hadoop 集群/云梯计算层实时流数据DataX/DbSync/TimeTunnel1500节点,每日40000JOB,处理数据1.5PB,凌晨2点结束,结果20T今天的话题关系型数据库仍然是王道NoSQL是SQL的有益补充用中间层隔离前后端缓存是系统化的工程关系型数据库仍然是王道关系型数据库有成熟稳定的开源产品SQL有较强的表达能力只存储中间状态的数据查询时过滤、计算、排序数据产品的本质拉关系做计算SELECTIF(INSTR(f.keyword,'''')>0,UPPER(TRIM(f.keyword)), CONCAT(b.brand_name,'''',UPPER(TRIM(f.keyword))))ASf0, SUM(f.search_num)ASf1,ROUND(SUM(f.search_num)/AVG(f.uv),2)ASf3FROMdm_fact_keyword_brand_dfINNERJOINdim_brandbO Nf.keyword_brand_id=b.brand_idWHEREkeyword_cat_idIN(''500025 35'')ANDthedate<=''2011-07-09'' ANDthedate>=''2011-07-07''GROUPBYf0ORDERBYSUM(f.search_num)DESCLIMIT0,100存储在DB中的数据分布式MySQL集群字段+条目数分片MyISAM引擎离线批量装载跨机房互备云梯APPMySQL集群数据装载数据查询MyFOX透明的集群中间层—MyFOX透明查询基于NodeJS,1200QPS数据装载路由计算数据装入一致性校验集群管理配置信息维护监控报警MyFOX-数据查询取分片数据(异步并发)取分片结果合并(表达式求值)合并计算缓存路由SQL解析语义理解查询路由字段改写分片SQL计算规则APC 缓存XMyFOX-节点结构MyFOX热节点(MySQL)15kSAS盘,300G12,raid10内存:24G成本:4.5W/T 冷节点(MySQL)7.2kSATA盘,1T12,raid10内存:24G成本:1.6W/T路由表30天无访问的冷数据新增热数据小结根据业务特点分库分表冷热数据分离降低成本,好钢用在刀刃上更有效地使用内存SQL虽牛,但是…如果继续用MySQL来存储数据,你怎么建索引?NoSQL是SQL的有益补充全属性交叉运算不同类目的商品有不同的属性同一商品的属性对有很多用户查询所选择的属性对不确定Prometheus定制化的存储实时计算Prom—数据装载Pro mHbaseHbaseHbase……索引:交易id列表属性对交易1(二进制,定长)交易2Prom—数据查询查索引求交集汇总计算写入缓存Prom—数据冗余明细数据大量冗余牺牲磁盘容量,以得到:避免明细数据网络传输变大量随机读为顺序读小结NoSQL是SQL的有益补充“预算”与“现算”的权衡“本地”与“集中”的协同其他的数据来源Prom的其他应用(淘词、指数等)从isearch获取实时的店铺、商品描述从主站搜索获取实时的商品数…异构数据源如何整合统一?用中间层隔离前后端[pengchun]$tail~/logs/glider-rt2.log127.0.0.1[14/Jun/2011:14:54:29+0800]"GET/glider/db/brand/brandinfo_d/get_hot _brand_top/where…HTTP/1.1"200170.065数据中间层—Glider多数据源整合UNIONJOIN输出格式化PERCENT/RANKOVER…JSON输出Glider架构DispatcherController配置解析请求解析一级缓存actionMyFOXProm二级缓存datasourceJOINUNIONfilter缓存是系统化的工程glider缓存系统前端产品一级缓存data二级缓存URL请求,nocache?nocache?nocache?Min(ttl)ttl,httpheaderetag,httpheader小结用中间层隔离前后端底层架构对前端透明水平可扩展性缓存是把双刃剑降低后端存储压力数据一致性问题缓存穿透与失效。
淘宝数据仓库核心架构设计的历史与发展
•
•
5/数据仓库价值挖掘与发现 数据产品 数据团队 6/联系我们
数据仓库架构方式
集线器架构 总体方法 体系结构 复杂度 建模方法 建模工具 易访问性 数据集成度 数据变化度 从上向下 总线架构 从下向上 先建立全企业的原子级数据仓库,然 按照业务过程建立数据集市,通过数据总线和一致 后在此基础上建立部门级应用 性维度达到企业级的一致性 非常复杂 面向主题,数据驱动 传统的ER模型 低 企业级的数据集成 源系统数据发生了较大的变化 较为简单 面向过程,应用驱动 维度模型 高 独立业务领域内的数据集成 源系统数据相对稳定
ETL主要做什么?
• 数据采集 • 数据同步 • 数据分发
数据转换/清洗
• 数据转换 • 数据清洗
• • • •
数据装载 数据转换 数据清洗 数据压缩
建立维度实事 中间表
• • • • 建立维度数据 建立实事数据 数据归并 数据切分
• • • •
数据集市 指标库 数据产品 数据挖掘
数据抽取
数据装载/转换 /清洗
用户需求处理
我们目前有哪些ETL工具平台
ETL调度发展
Crontab时代
• 完全为了解决 定时启动的问 题 • 无法解决时序 前后置依赖问 题 • 元法解决均衡 负载问题 • 无法解决优先 级问题 • 运维的灾难
RAC天网时代
• 根节点定时启 动 • 任务之间完全 基于触发启动 • 能很好解决均 衡负载的问题 • 能很好的解决 优先级问题 • 一键式运维, 轻松快捷 • 不能解决rac单 节点失效的问 题。
数据库模 型
主题
1/数据仓库概述
数据仓库基本特征 数据仓库基本架构
2/数据仓库建设
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Mysql
oracle
oracle
2004年: 稳定性,高性能 逐步开始采用oracle,小型机, 高端硬件存储
oracle:商品,交易,评价,收藏,用户等(3套oracle环境)
网站迅猛发展,数据库一定要保证高可用性,最稳妥的 方法?
8
解决问题
找“老板”投钱
Oracle,小型机,高端硬件存储
9
垂直拆分
拆分如何兼顾、解决多维度查询呢?
27
如何解决
两份数据 按照不同维度拆分,承担各自不同的业务场景。
框架: 两份数据+读写分离
28
现有架构
Aplication Application RW RW
主库2
主库1
1.引入读库集群 2.采用mysql和廉价pc服务器 3.采用1主多备来分摊读压力 4.业务进行分级
2008年: 业务迅猛发展,单 台小型机很快就达 到瓶颈,开始进入
oracle
oracle oracle oracleoracle oracle
大规模垂直拆分 阶段
高可用带来了高成本 Oracle:商品,交易,用户,评价,收藏夹(8-10套数据库)
10
垂直拆分优缺点
优点: 减少应用之间的耦合 数据库业务单一,可以针对具体的业务类型优化
遭遇瓶颈
卖家交易后台管理:
20
瓶颈在哪儿
1. 模糊查询 2. 大量数据count操作 3. list查询分页查询 4. 查询条件复杂,用户可以动态选择
备注: 交易实时性要求非常高,需要实时展示,不能有延迟
21
如何解决
这球怎么踢?
22
实时搜索
大数据量处理尽量通过搜索来实现。 相比其他的方案,搜索很好的解决了标题的模糊like查询。
Notify消息机制复制
R
M-1
M-2
M-3
….
M-10 …...
M-15
M-16
R
S-1
S-2
S-3
S-4
S-10 …... S-15
S-16 S2-15
S2-16
29
小结
垂直拆分 水平拆分 读写分离 对数据库的定位
30
交流时间
逻辑备库主要提供dw使用。
主库
物理备 库
逻辑备 库
Dw
3
MySQL基本框架
Aplication Aplication
M-S架构: M-M架构:
Aplication Aplication
Master
Slave
Master
Master
Slave
4
Failover的困惑
主备切换如何做到不影响到应用,不需要开发人工干预?
数据库能做什么
1.存数据 2.单条查询(querybyid) 3.多表关联sql查询 4.通过存储过程,函数来处理业务 5.大量数据实时在线分析(sum,count ,group by)
我们对数据库的定位是什么?
16
合理的使用技术
数据库尽量只负责保存数据 尽量通过应用服务器来分摊复杂计算(order by、sum、group by、 count..)
Isearch(搜索,实时搜索) Tair(基于key value的全内存系统) Tfs(taobao file system) Nosql( Cassandra 。。。) Bigtable
17
做合适的事情
18
Agenda
• 数据库基本框架 • 数据库架构演变 • 案例:交易核心数据库演变关键点
tbtest = (DESCRIPTION = (failover = on ) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = tbtest) ) )
Rjdbc+自动推送
主备数据库进行独立的管理,配置两个数据源。 数据源中哪一个是活跃的,取决于ConfigServer(配置中心)上的配置。
Configserver:
Agenda
• 数据库基本框架 • 数据库架构演变 • 案例:交易核心数据库演变关键点
初期架构
2003年: 快速开发 Mysql,pc服务器 oracle
数据库架构演变(2003-2010)
丁原 dingyuan@
日பைடு நூலகம்:2010.06
1
Agenda
• 数据库基本框架 • 数据库架构演变 • 案例:交易核心数据库演变关键点
Oracle基本框架
Aplication Aplication
出现硬件故障时,物理备库激活成为主 库,替代主库对外提供服务。
缺点: 硬件成本,Oracle license费用
垂直扩展可能带来的问题?
11
可怕的扩展
3->8套->16套->?
物理主库,物理备库,逻辑备库 oracle,小型机,高端存储,可怕的硬件投入
找“老板”继续投钱 ? 可怕的成本,可怕的垂直扩展 垂直扩展并没有打破集中式,可怕的集中式
12
水平拆分
淘宝不断发展,系统压力增长远远超过2倍/每年,新业务不断上 线,在好的硬件也很容易达到瓶颈,
Aplication Application
isearch
增量dump
Db
23
遭遇新的瓶颈
通过监控平台采集了部分sql的执行量(12小时)
数据库接近4万次/每秒的查询,每个小时在1.5亿次左右,还 在快速增加中。
24
瓶颈在哪儿
读太多(单台查询,多条查询) 更新量太大,每天将近1亿次的更新 sql执行量增长非常快
水平拆分?
问题: 1.需要解决拆分带来的成本问题 2.我们会增加很多服务器,必须要解决可维护性 3.我们也要解决可扩展性
13
水平拆分
去Oracle 去小型机 去高端存储
Mysql,廉价pc服务器 应用上做容灾,不在过度依赖数据库 依赖硬件
分布式,低成本,可扩展,易维护
14
他他他
他能搞定一切吗?
15
备注: 实时性要求非常高 不管是卖家还是买家,肯定不乐意看到付款的成功订单,系统 却显示未付款。
如何解决读?
25
可选方案
Tair 实时搜索 通过廉价pc实现读写分离 其他
我们选择了什么?
26
读写分离
通过廉价pc实现读写分离
场景: 1.买家查询 2.卖家查询 3.单条id查询 4.关联查询 5.其他查询