Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie 分布式存储与TDDL
Ähnlich wie 分布式存储与TDDL (20)
Mehr von mysqlops
Mehr von mysqlops (20)
分布式存储与TDDL
- 2. 你理解的存储有什么？ • MYSQL/ORACLE/PGSQL/SQLSERVER • HDFS/TFS/BIGTABLE • TAIR/REDIS/MEMCACHED • HBASE • Cassandra/mongodb/Couchdb/voldmort • neo4j • http://nosql-database.org/ currently 122+
- 3. 问题 • http://nosql-database.org/ [currently 122+] • “I’m the fastest” • “but we are web scale well” • 我们最安全，从不会失败 • 我们最简单
- 4. 这个topic的目标 • 介绍一般性的分布式存储知识，以及一般 性做法 • 协助大家快速的从海量的存储引擎中选择 适合自己业务特点的引擎 • 介绍TDDL在上述关键节点上的选择和思考 • 失败经验 • 切分经验 • 未来，我们的饼是什么？
- 6. 关系数据库 用户 API 关系代数和 事务引擎 K-V存储
- 7. K-v存储 • Nosql 与sql的核心区别就在于 – 数据库层是否应该全部的放弃关系代数，将所有关 系代数都交托给上层进行处理？ – 事务是否是必须应该被放弃的东西？ – 上层api，是否应该放弃sql引擎 • 永远正确定律: – 计算机其实是个分形系统，将一系列的想法不断地 重复 – 越接近硬件和微元件，速度越快。 – 所以nosql一定会快于sql。但代价是方便性
- 8. K-v存储 • 所有数据存储的最基本和最底层的结构 • 与文件系统找指定的数据的作用相同，也 是根据指定的key查找到对应的数据。 • 回忆数据结构 – 处理查找，什么查找方式能达到比较好的效果？ • 二分查找 •树 • hash
- 9. K-v存储 • 如何按照其他key找到对应的数据 – Second index – 倒排索引 • 如何能够找到符合一组查询条件的查询语 句 – 组合索引 col1,col2 – Select * from tab where col1 = ? And col2 = ? COL1 COL2 00 001 00 002 00 003 01 001
- 10. K-V分布式存储 • 很多东西可以复用，本质来说，从硬件到 软件，就是一个不断分形的过程 • 额外需要考虑的因素 – 网络延迟 • TCP/IP –公用网络，ip跳转慢，tcp包头大 • FIBRE CHANNEL – 专用 点对点传播 包头小 无ip协议 – 丢包 • Tcp 协议规范决定，努力送达但不保证一定可达
- 11. 分布式场景下的存储
- 12. 路由 • 本质来说还是个查找的过程 • 于是逻辑结构也就决定了。 – Hash • O(1)效率 • 不支持范围查询（时间这样的查询条件不要考虑了） • 不需要频繁调整数据分布 – Tree • 主要是B-Tree • O(logN)效率 • 支持范围查询 • 需要频繁调整节点指针以适应数据分布
- 13. 路由 • Hash – Id % n • 最普通的hash • 如果id % 3 -> id % 4 总共会有80%的数据发生移动， 最好情况下是倍分 id % 3 -> id % 6 会有50%的数据发 生移动 • 但数据移动本身就是个要了亲命了。
- 14. 路由 • Hash – 一致性hash Def idmod = id % 1000 ; If(id >= 0 and id < 250) return db1; Else if (id >= 250 and id < 500) return db2; Else if (id >= 500 and id < 750) return db3; Else return db4; 一致性hash
- 15. 路由 • Hash – 一致性hash
- 16. 路由 • Hash – 一致性hash • 可以解决热点问题 • 但如果热点均匀，加机器基本等于n->2n方案 因为要在每个环上都加一台机器，才能保证所有节 点的数据的一部分迁移到新加入的机器上
- 17. 路由 • Hash – 虚拟节点 Def hashid = Id % 65536 Hash id Target node id 0 0 1 1 2 2 3 3 4 0 …. … 65535 3
- 18. 路由 • Hash – 虚拟节点 • 解决一致性hash的问题 – 解决热点问题，只需要调整对应关系即可 – 解决n->n+1问题，规则可以规定只移动需要移动的数据 • 但方案相对的复杂一些 • 一般推荐使用简单方案开始，使用n->2n方案扩容 • 只有需要的情况下，再考虑平滑的扩展到虚拟节点 方案即可
- 19. 路由 • B-Tree – Hbase使用的切分方法 • 支持范围查询 • 但方案过于复杂，对于大部分场景来说，引导列都 是pk.userid一类的单值查询，用树相对复杂。 • 需要频繁的进行切分和合并操作---region server的噩 梦。 • 固定节点情况下，跨度相对较大，查找效率进一步 降低
- 20. 路由 • TDDL的选择 – 规则引擎 • Groovy脚本实现，本质是为了实现多版本的规则推送， 其他事情，可以完全委托给业务的具体需求。 • 内建对3种hash模式的支持，并且允许从简单hash平滑的 过度到一致性hash或虚拟节点hash • 允许使用外部实现规则 • 允许引入静态方法 – 默认推荐使用id % n – 实现了多版本，并且与迁移工具绑定 – 可以与其他产品无缝结合—MDDAL可以不用改动代 码
- 21. 路由 • 数据迁移 – 与规则系统绑定，需要规则系统提供多版本支 持 • 核心思路是:输入相同的参数，老规则和新规则如果 计算出了相同的结果，那么数据不用移动，如果算 出不同结果，那么数据需要移动 将增量数据 本机数据增 全量复制 数据检查 部分停写 数据检查 规则切换 删除数据 保持在本机 量复制
- 22. 将 增 本 路由 量 机 数 全 数 数 部 数 规 删 据 量 据 据 分 据 则 除 保 复 增 检 停 检 切 数 持 制 量 查 写 查 换 据 在 复 本 制 机 db0 db1 db0 db1 当id = 2时 Id % 3 =2 Id % 4 = 2 db2 不需要迁移到新节 点。 db2 db3 当id = 3时 Id % 3 = 0; Id % 4 = 3; 需要做节点移动
- 23. 路由 • 规则和迁移 – 解决scale out问题 – 可以解决一切有状态节点的扩容问题 • Redis? – 规则+动态创建数据源可以实现存储资源的管理 • 根据访问量和磁盘容量，决定你的数据节点应该如 何分配。
- 24. 一致性选择 • HA 是个永恒的难题 – 对这个问题的概要性描述CAP：在数据存了多份的前提 下，一致性和响应时间，读写可用性不可兼得，理论 的其他部分笑笑就好。 – 常见处理模型 • Dynamo :gossip 读写高可用 最终一致 • 淘宝老方案: oracle + emc 用fibre channel做p2p直连保证数据不 丢 ，但切换时间比较长 • ob : 两段提交 ，保证数据不丢，切换时间可接受，但可能存在 极短时间内写不可用 • Mysql :与mongodb ob类似，但采用的是半同步方案，切换时间 短，写存在极短时间不可用 • Mongodb cassandra : W+R>N 模型，简单来说，就是多数派 accept的时候数据才算写入成功。
- 25. 数据库HA还不够 • 在实际的线上系统，还需要考虑以下问题 – 有些机器负担写任务，因此读压力可能不均衡， 因此必须有权重设置 – 单个节点挂掉的时候，TCP超时会导致业务APP 的线程花费更多的时间来处理单个请求，这样 会降低APP的处理能力，导致雪崩。 – 因为突发情况，导致数据库请求数增加，数据 库响应变慢，导致雪崩
- 26. 数据库HA还不够 • TDDL的选择 – 分为三层
- 27. 数据库HA还不够 • Matrix 层 – 核心是规则引擎 • 可以单独抽取出来，放在其他实现里，比如MDDAL • 通过规则引擎实现了动态扩容 – 主要路径 • Sql解析->规则引擎计算->数据执行->合并结果 – 如果有更好的封装，我们非常欢迎
- 28. 数据库HA还不够 • GROUP 层 – 读写分离 – 权重 – 写的HA切换 • 写HA切换，目前的实现比较复杂 • 想借鉴uic的成功经验，但改动较大，牵一发而动全 身了，有一点过度设计。 – 读的HA切换 – 动态加新的slave节点
- 29. 数据库HA还不够 • Atom层 – 单个数据库的抽象 – 动态化的jboss数据源，ip port 用户名密码都可 以动态修改。 – Thread count .try catch模式，保护业务的处理线 程 – 动态阻止某个sql执行 – 执行次数统计和限制
- 30. 数据增量复制 • 处理数据的异构增量复制 – 按买家分库，按卖家查询 – 评价，被评价双维度查询 – 数据的增量共享 • 由binlog解析器和meta 有序消息队列两个部 分组成。
- 31. TDDL 最佳实践 • 尽可能使用一对多规则中的一进行数据切分 – 互联网行业，用户是个非常简单好用的维度。 • 卖家买家问题，使用数据增量复制的方式冗余 数据进行查询。这种冗余从本质来说，就是索 引。 • 合理利用表的冗余结构，减少走网络的次数 – 卖家买家，都存了全部的数据，这样，按照卖家去 查的时候，不需要再走一次网络回表到买家去查一 次。
- 32. TDDL 最佳实践 • 尽一切可能利用单机资源 – 单机事务 – 单机join • 好的存储模型，就是尽可能多的做到以下几点: – 尽可能走内存 – 尽可能将一次要查询到的数据物理的放在一起 – 通过合理的数据冗余，减少走网络的次数 – 合理并行提升响应时间 – 读取数据瓶颈，加slave节点解决 – 写瓶颈，用规则进行切分
- 33. 失败经验分享
- 34. 未来 • K-V是一切数据存取的最基本组成部分 – 但以前很难解决扩展性问题，现在已经很容易 就可以解决了。 • 存储节点少做一点，业务代码就要多做一 点。 • 没有银弹，想提升查询速度，只有冗余数 据这一条路可走。 • 类结构化查询语言，对查询来说非常方便