淘宝分布式数据层


淘宝分布式数据层的前世今生 华黎 About me • 姓名 : 曾宪杰 • 花名 : 华黎 • 团队 : 淘宝 - 技术研发部 - 开放平台新业务部 -Java 中间件团队 • 职责 : 负责团队的整体工作 • Twiiter @vanadies10 • Sina 微博 @vanadies10 2005- 前世 水平分库 common-dao 2005~ 前世 Ø ORACLE+IBM 小型机 +EMC Ø 开始数据水平拆分 Ø 希望拆分不要过多的影响开发人员 IBM 小型机 EMC 高端存储 2005~ 前世 • common-dao – 基于数据库标识的路由 – 基于用户 id 的路由 – 对开发不完全透明 • 来看一个当时的 url – http://auction1.taobao.com/auction/item_detail-0db1-a0c6773727d2 e1184badbcf9cdc54c07.jhtml 2007 服务化 连接数问题 2007 前台 应用 1 前台 应用 1 前台 应用 1 前台 应用 2 前台 应用 2 前台 应用 2 DB DB DB 数据库连接数的问题 重复的逻辑散落在不同的应用中 2007 业务 中心 1 业务 中心 2 业务 中心 3 服务化 解决了业务核心的稳定和一致的问题 解决了重要数据库的连接数的问题 也影响了淘宝分布式数据层的诞生和发展 前台 应用 1 前台 应用 1 前台 应用 1 前台 应用 2 前台 应用 2 前台 应用 2 2008- 诞生 读写分离 非对称数据复制 2008~ 诞生 • 有这么一个库 – 数据量大、访问量大、数据重要 – 读写严重不成比例,约 18:1 • 怎么办? – 读写分离 • 怎么做读写分离 – 数据库自己做复制,应用选择读写库 2008~ 诞生 Master Slave Slave 业务 Read Read Read/Write 读写分离的结构 业务 Master Read/Write 2008~ 诞生 Master Slave 2008~ 诞生 • 很朴实的想法 – 可以用低成本来解决读的问题 – 可以用低成本解决大部分读的问题 – 对开发者尽量透明 2008~ 诞生 Slave Master1 Slave1-1 Slave1-2 …… 2008~ 诞生 • Master 的数据怎么到 Slave – 没找到特别好的现成的工具 – 解析 Master 日志,然后做复制 – 拦截 SQL 操作,做复制 2008~ 诞生 • Tddl 1.0(Taobao Distributed Data Layer) – 时间很紧,解析 DB Log 时间上有风险 – 从执行 SQL 上入手,但是解析 SQL 时间上也来不急 – 好吧,产出了一套 ugly 的 API,是使用者自己进行了 SQ L 的语法分析 – 基于消息中间件的行复制 2008~ 诞生 Tddl 是部署在应用上的 一个 jar ,没有服务端 基于消息中间件完成了 第一版的数据复制 性能也满足业务的需 求, 99.96% 的复制低 于 200ms 2009- 落地和发展 SQL 解析 规则 Mysql 集群 唯一主键 非对称复制 2009~ 落地和发展 • 拥抱变化 – 08 年底到 09 年初,一个很大很大的项目,重 构了很多代码,数据库压力下降了很多 – 原来的需求,暂时没有了 2009~ 落地和发展 • 还债 – 搞定 SQL 解析,废弃了之前的 ugly 的 API – 完成了 SQL 路由规则的支持,完成了规则和代 码的分离 – 这个时候比较像一个数据层了 2009~ 落地和发展 2009~ 落地和发展 • Mysql? – 当时我们对 Oracle 更加熟悉和了解 – 大量分表分库带来的数据和表结构维护问题 – MySQL 固有的一些问题 – 全局序列号 – DDL 操作锁表问题 – 数据异步复制的延时的问题 – Version5.0 之前分区表不稳定问题 2009~ 落地和发展 • 引入 Mysql – 核心业务还是使用 O.I.E. – 非核心业务开始逐步尝试 • 对 Mysql 的使用 – MS 结构 – 分库分表 – 读写分离 2009~ 落地和发展 • Tddl 的增强 – 复杂的路由规则 – 唯一主键 – 易用性 • 随着一个业务系统的 MYSQL 迁移上线 – 成功负载淘宝一个主要应用 – 节省成本 500w 以上 2009~ 落地和发展 • 核心的业务怎么办? – 写库为 ORACLE – 保证写数据不丢 – 运维经验较多 – 性能可以满足需求 – 读库为 MySQL – 价格便宜量又足 – 挂了影响也不大 2009~ 落地和发展 • 改进了非对称数据复制 – 和之前使用消息中间件的机制类似 – 解决了消息中间件不能理解复制任务、不能合并复制任务的缺点 – 在客户端 ( 业务应用上 ) 先直接尝试复制,提升性能 – 迁移时的常规武器 • 异构读写分离 – 使用 ORACLE( 主 )-MYSQL( 读 ) 模式 – 主库 io 压力下降 50% 以上 2009~ 落地和发展 • 非对称数据复制的扩展 – 最初是解决一个 Master 需要对应多个 Slave – 数据复制到多个目标 – 介质可以不同 – 分库分表规则可以不同 – 解决一条记录关联两个用户的按用户分库分表的问 题,比如评价 2009~ 落地和发展 • 小结 – 支持了 SQL 解析 – SQL 路由规则 – 读写分离 – 唯一 Id 的生成 – 增强非对称数据复制 2010- 重生 路由表 三层重构 工具 DbProxy 新的复制方案 2010~ 重生 如果按照 userID 为 shardingKey, 那么根据 PrimaryKey 怎么对记录 进行操作? • 路由规则后的路由表 • 看看这个 Url – http://item.taobao.com/item.htm?id=7238421044 PrimaryKey UserID Column n 0 100 TAOBAO123 2010~ 重生 User User 1 User 2 User1-M User2-M User2-S User1-S分库分表 读写分离 数据库架构的演进 之前的 Tddl ,从总体上管理业务使用的数据库整个集群 业务只能做 0 和 1 的选择 2010~ 重生 User1-M User2-M User2-S User1-S 2010~ 重生 User1-M User2-M User2-S User1-S TAtomDataSourc e TGroupDataSourc e TDataSource 数据源的三层重构 业务可以灵活选择 2010~ 重生 • 工具 – 数据的维护工作 – 经过复制后,数据是在多个节点上存在的 – 查询 – 她在哪里 - 分库分表后的问题 2010~ 重生 • 管理工具 – DB 可用性、权重、读写特性的管理 – 业务的数据源配置的管理 – DB 的流控和并发保护的管理 2010~ 重生 • 随着业务中心的机器数量增长,连接数重新成为了问题 • Client->DB 走向了 Client->Server-DB 2010~ 重生 • 目前数据复制存在的问题 – 对于主流程的影响 – 我们在之初就考虑过基于 log 的复制 – 这个债一直欠到了 2010 年 2010~ 重生 • 基于 MySQL binlog • 行复制方案 • 支持多种维度 • 支持不同目标 小结 小结 • SQL 解析,路由规则,数据合并 • Client->DB 和 Client->Server-DB 模式 • 非对称数据复制 • 三层的数据源结构 未来 • 数据的写安全 • 动态平滑扩展 • mysql 自身优化 • …… Thanks ! • 单击此处编辑母版文本样式 – 第二级 – 第三级 • 第四级 – 第五级
还剩41页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

li.shugang

贡献于2013-05-10

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf