Transcript 买家库
淘宝在线交易数据演变 胡嘉川（牧劳） 2012-04-21 主要内容 一次淘宝购物之旅 交易业务和系统结构介绍 2003~2008从Mysql到小型机Oracle 2009年交易库拆分为买家库和卖家库 2010年交易卖家库的优化和买家库一拆二 2011年交易卖家库从Oracle到Mysql,磁盘SSD 2011年交易买家库去小型机和Oracle,磁盘 FusionIO 一次淘宝购物之旅 一次淘宝购物之旅 第一步：找到想买的宝贝 一次淘宝购物之旅 第二步：查看宝贝详情 一次淘宝购物之旅 第三步：把想买的宝贝加入购物车 一次淘宝购物之旅 第四步：结算订单 一次淘宝购物之旅 第五步：付款 一次淘宝购物之旅 第六步：查看购买的宝贝 交易业务和系统结构介绍 淘宝交易数据库的组成结构 交易数据库 买 买 买 家 家 家 库 库 库 1 2 3 买 家 库 32 Mysql + FusionIO 卖 卖 卖 家 家 家 库 库 库 1 2 3 Mysql + SSD 卖 家 库 16 Hbase集群 历史库 买家库的业务结构 买家数据库 已买到 交易流程 下 单 付 款 确 认 收 货 单条查询 退 款 卖家库的业务结构 卖家数据库 已卖出 Detail页交易查询 TOP导出订单 淘宝交易流程介绍 COD交易 酒店交易 下单 机票交易 卡易售 付款 普通宝贝 自动发货 发货 确认收货 直冲交易 分销交易 商城家装 商超交易 淘宝交易角色介绍 买家 下 单 付 款 卖家 确 认 收 货 交 易 查 询 发 货 修 改 价 格 交 易 查 询 淘宝交易数据库的系统结构 写 交易服务系统 读 买家库 卖家库 消息中间件 交易复制系统 2003~2008从MYSQL到Oracle 2003年的数据库体系 …… 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 复制 MySQL Master 复制 MySQL Slave 2003年到2008年数据库的演变 商品 Mysql Oracle，小型机 业务发展 垂直拆分 交易 用户 2008年交易日均达到200万订单 2009年交易库拆分为买家库和卖家库 2009年交易库概况 Oracle 交易主库 小型机 EMC 2009年日均交易达到600万订单 交 易 写 入 已 买 到 查 询 已 卖 出 查 询 宝 贝 详 情 TOP 导 订 单 把卖家查询分离出去 各种卖家辅助工具 已卖出 TOP导出订单 累计售出数 Detail页 销售列表 如何拆分卖家库（2009年7月） 买家 写交易，已买到 买家单条查询交易 买家库 卖家单条查询交易和写交易 卖家 16个Oracle节点 按卖家查询交易 卖家库 如何迁移和实时复制订单数据 订单更改发Notify消息 交易系统 订阅交易消息 实时更新卖家库数据 卖家库 交易复制系统 卖家库拆分后所承担的业务结构 Detail页交易查询 卖家库备1 卖家库主库 TOP及其它卖家查询 已卖出查询 卖家库备2 卖家库拆分后的一些故障 卖 家 库 1 卖 家 库 2 卖 家 库 3 变 慢 卖 家 库 3 HSF服务 前端请求 卖 家 库 4 防止此问题采取的措施-流控 防止此问题采取的措施-监控 卖家主库监控 卖家备一监控 卖家备二监控 2010年交易卖家库的优化和买家库一拆二 卖家库的压力越来越大 卖家数据库 大卖家查询 各类卖家辅助工具 卖家主库 TOP订单导出 Detail订单查询 备1 备2 卖家库的优化-查询Tair化 累计售出Tair化 销售列表Tair化 卖家提醒Tair化 卖家查询Tair化原理 获取累计售出数和销售列表 Detail Tair Tair里没数据，到TP取 业务变更，实时更新Tair 交易复制系统 交易系统 Notify 买家库拆分方案准备-选型 Oracle 一拆二 comm Oracle 一拆多 comm2 Comm备库 小型机+EMC Comm2备库 Oracle PC+EMC Oracle 买家拆分方案准备-业务模型 已买到查询 交易流程 买家 单条查询 买家拆分确定最终方案 一拆二 Comm(交易老主 库) Comm(交易老备 库) 交易数据是冗余两份，不需要迁移数据 不使用TDDL，对DAO层暴露路由 Comm备(原IC主) Comm2备(原IC备) 买家拆分准备工作，订单ID路由 卖家ID后两位 订单ID 6323940234 79 64 Sequence 买家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后3，4位 订单ID 6323940234 79 64 Sequence 买家ID后两位 （1） 定位具体库 （2） 添加路由Tair，通过Tair拿到具体的买家ID （3） 新订单ID直接通过ID里的路由信息定位库和表 （4）老订单ID会随着历史库迁移，访问慢慢变少 交易买家库去IOE-更新丢失如何补偿 交易系统 买家库 通过支付宝恢复淘宝交易 支付宝 对账系统 交易买家库去IOE-增量复制和全量导入 交易数据写入 交易系统 买家库(Oracle） 对账系统 订阅交易消息复制 Notify Tradelogs 买家库（Mysql） 交易买家库去IOE-如何Beta 写交易 交易系统 已买到和订单详情查询Mysql 买家库 (Mysql） 买家库(Oracle） 交易买家库去IOE-容灾方案 单库容灾切换 TDDL动态数据源切换（可批量切换） Mysql主库 Mysql备库 Mysql回切Oracle 程序开关切换 Oracle买家库 Mysql买家库 交易买家库去IOE-停机发布 数 据 一 致 性 保 证 全量对账 每天增量对账 停机前一天开启实时对账 实时对账保证停前数据一致 发 布 阶 段 停Oracle写 发新代码 经验教训总结 一些经验教训 尽量短事务，利用消息中间件实现最终一致性 更新数据按照固定的顺序更新，防止死锁 处理异步事务比同步事务快导致事务回滚率高 尽量去掉一切单点，设计快速容灾手段 对资源做好流量控制，防止互相影响 建立快速对账的手段，出问题时可以快速恢复 数据底层改动线上BETA时尽量使用异步方式 数据库有较大余量时尽量不要引入实时缓存 谢谢大家 我现在愿意回答 您的任何问题