淘宝在线交易数据演变

胡嘉川（牧劳）2012-04-21

一次淘宝购物之旅交易业务和系统结构介绍2003~2008 从 Mysql 到小型机 Oracle2009 年交易库拆分为买家库和卖家库2010 年交易卖家库的优化和买家库一拆二2011 年交易卖家库从 Oracle 到 Mysql, 磁盘 SSD2011 年交易买家库去小型机和 Oracle, 磁盘 FusionIO

主要内容

一次淘宝购物之旅

一次淘宝购物之旅第一步：找到想买的宝贝

一次淘宝购物之旅第二步：查看宝贝详情

一次淘宝购物之旅第三步：把想买的宝贝加入购物车

一次淘宝购物之旅第四步：结算订单

一次淘宝购物之旅第五步：付款

一次淘宝购物之旅第六步：查看购买的宝贝

交易业务和系统结构介绍

淘宝交易数据库的组成结构

买家库1

买家库2

买家库3

买家库32

Mysql + FusionIO

卖家库1

卖家库2

卖家库3

卖家库16

Mysql + SSD

Hbase集群

交易数据库

历史库

买家库的业务结构

已买到 交易流程 单条查询

下单

付款

确认收货

退款

买家数据库

卖家库的业务结构

卖家数据库

已卖出 Detail页交易查询 TOP导出订单

淘宝交易流程介绍

下单 付款 发货 确认收货

COD交易 卡易售 自动发货 分销交易

酒店交易

机票交易 普通宝贝 直冲交易 商超交易

商城家装

淘宝交易角色介绍

买家 卖家

下单

付款

确认收货

交易查询

发货

修改价格

交易查询

淘宝交易数据库的系统结构

消息中间件 交易复制系统

交易服务系统 买家库

卖家库

写

读

2003~2008从MYSQL到 Oracle

2003年的数据库体系

MySQL Master

……

Apache

Mod_php4

Pear DB

Auction

Apache

Mod_php4

Pear DB

Member

Apache

Mod_php4

Pear DB

Search

Apache

Mod_php4

Pear DB

MySQL Slave

MySQL Slave

复制 复制

读写读

读

2003年到 2008年数据库的演变

Oracle ，小型机Mysql

商品

用户

交易

业务发展 垂直拆分

2008 年交易日均达到 200 万订单

2009年交易库拆分为买家库和卖家库

2009年交易库概况

Oracle

小型机 EMC交易主库

交易写入

已买到查询

已卖出查询

宝贝详情

TOP导订单

2009 年日均交易达到 600 万订单

把卖家查询分离出去

已卖出

Detail页

各种卖家辅助工具

TOP导出订单

累计售出数

销售列表

如何拆分卖家库（ 2009年 7月）

买家

卖家

买家库

卖家库

写交易，已买到

买家单条查询交易

卖家单条查询交易和写交易

按卖家查询交易

16个 Oracle节点

如何迁移和实时复制订单数据

交易系统

订单更改发 Notify 消息

卖家库交易复制系统

订阅交易消息

实时更新卖家库数据

卖家库拆分后所承担的业务结构

卖家库主库

卖家库备 1

卖家库备 2已卖出查询

Detail页交易查询

TOP及其它卖家查询

卖家库拆分后的一些故障

卖家库1

卖家库2

卖家库3变慢

卖家库3

卖家库4

HSF服务

前端请求

防止此问题采取的措施 -流控

防止此问题采取的措施 -监控

卖家主库监控

卖家备一监控

卖家备二监控

2010年交易卖家库的优化和买家库一拆二

卖家库的压力越来越大

大卖家查询

各类卖家辅助工具

TOP 订单导出

Detail 订单查询

备1

卖家主库

备2

卖家数据库

卖家库的优化 -查询 Tair化

累计售出 Tair化

销售列表 Tair化

卖家提醒 Tair化

卖家查询 Tair化原理

Notify

交易系统

Detail Tair

交易复制系统

获取累计售出数和销售列表

Tair 里没数据，到 TP取

业务变更，实时更新 Tair

买家库拆分方案准备 -选型

一拆二

一拆多

Oracle

Oracle

comm

comm2

Comm 备库

Comm2 备库

小型机 +EMC

PC+EMC

Oracle

Oracle

买家拆分方案准备 -业务模型

已买到查询

交易流程 买家 单条查询

买家拆分确定最终方案

一拆二

Comm(交易老主库 )

Comm(交易老备库 )

Comm备 (原 IC主 )

Comm2备 (原 IC备 )

交易数据是冗余两份，不需要迁移数据不使用 TDDL ，对 DAO 层暴露路由

买家拆分准备工作，订单 ID路由

订单 ID 6323940234

Sequence

79 64

买家 ID后两位

卖家 ID后两位

（ 1 ） 定位具体库（ 2 ） 为保持简单老订单 ID ，直接查两次（ 3 ） 不依赖路由表

2011年卖家库去 O和买家库去 IOE

卖家库继续只有一倍余量

卖家查询的 IO瓶颈越来越大

Oracle的授权费用问题

卖家库的去 O选型

KSearch OceanBase

卖家库

Mysql + SSD

目标：解决磁盘 IO 瓶颈

卖家库去 O的详细步骤

1. 设定 4倍容量， 4倍性能余量目标

2. 收集接口访问数据，准备性能测试方案

3. 准备交易增量复制和全量导入

4. Beta卖家查询，观察日志

5. 全部切换到Mysql，添加监控

买家库去 IOE前的准备 -已买到的 Tair化

已买到列表

订单详情

交易买家库扩展目标（ 2011年）

当前性能情况

集群 QPS： 7万 /秒

集群 TPS： 3000/秒

极限性能情况

集群 QPS： 14万 /秒

集群 TPS： 6000/秒

交易买家库 Oracle 集群只有一倍余量

拆分后目标

集群 QPS： 42万 /秒

集群 TPS： 19万 /秒

目标： 4 倍数据量下，支撑 6 倍现有系统压力

交易买家库去 IOE硬件选型 -Fusion IO

IOPS性能很高

寿命较长

较 SSD成本高

稳定性比 SSD好

交易买家库去 IOE硬件选型 -SSD

相对 FIO便宜不少

满足买家库性能要求

极端情况稳定性较 FIO差

极端情况稳定性较 FIO差

交易买家库去 IOE硬件选型 -EMC+PC

Oracle结合很好，不丢数据

有 4倍余量

成本过高，扩展性不好

交易买家库去 IOE硬件选型 -成本对比当前买家 Oracle 主库成本： 2200 万RMB

RAID:504万 RMB

不做 RAID： 364万 RMB

RAID:294万 RMB

1060万 RMB

交易买家库去 IOE最终硬件选定 -FusionIO

稳定性好

性能最好，性价比高

硬件在发展，成本在降低

性能测试结果： MYSQL 成为了性能瓶颈， FIO 的极限远未达到单台 QPS:3.5W * 16 = 56 万单台 TPS:1.2W * 16 = 19.2 万

交易买家库去 IOE-如何分库分表

分库分表目标

保持简单

考虑4倍数据量

考虑4倍性能

考虑未来节点扩展

分 32 逻辑库， 16 台服务器1024 张表，尽量只对核心表作分库分表减少各表事务依赖，把其它业务放到杂表库

交易买家库去 IOE-新订单 ID路由准备

订单 ID 6323940234

Sequence

79 64

买家 ID后两位

买家 ID后 3， 4位

（ 1 ） 定位具体库（ 2 ） 添加路由 Tair ，通过 Tair 拿到具体的买家 ID（ 3 ） 新订单 ID 直接通过 ID 里的路由信息定位库和表（ 4 ）老订单 ID 会随着历史库迁移，访问慢慢变少

交易买家库去 IOE-更新丢失如何补偿

交易系统

支付宝

买家库

对账系统

通过支付宝恢复淘宝交易

交易买家库去 IOE-增量复制和全量导入

交易系统

Notify

买家库(Oracle）

Tradelogs

订阅交易消息复制

买家库（Mysql）

交易数据写入

对账系统

交易买家库去 IOE-如何 Beta

交易系统 买家库(Oracle）

写交易

买家库(Mysql）

已买到和订单详情查询 Mysql

交易买家库去 IOE-容灾方案

单库容灾切换

Mysql主库 Mysql备库

TDDL 动态数据源切换（可批量切换）

Mysql回切 Oracle

Oracle买家库 Mysql买家库

程序开关切换

交易买家库去 IOE-停机发布

数据一致性保证

全量对账

每天增量对账

停机前一天开启实时对账

发布阶段

实时对账保证停前数据一致

停 Oracle写

发新代码

经验教训总结

一些经验教训尽量短事务，利用消息中间件实现最终一致性更新数据按照固定的顺序更新，防止死锁处理异步事务比同步事务快导致事务回滚率高尽量去掉一切单点，设计快速容灾手段对资源做好流量控制，防止互相影响建立快速对账的手段，出问题时可以快速恢复数据底层改动线上 BETA 时尽量使用异步方式数据库有较大余量时尽量不要引入实时缓存

谢谢大家

我现在愿意回答您的任何问题