第六周总结

用户头像
石印掌纹
关注
发布于: 2020 年 07 月 14 日

关系型数据库

  • 数据分片

  • 用于解决大数据量数据存储,将一张大表按照指定路由规则分成若干张子表,用户访问数据库时通过分片规则访问对应子表

  • 实现方式大体分两种:

  • 一种是用户端实现路由逻辑:比如通过硬编码定制好路由规则

  • 集群伸缩

  • 将原来的数据存储到多个scheme(数据库)中

  • 当增加节点时,只需要将部分数据库移动到新的节点中,所以路由方式无需改变,只需要改底层数据库的url

CAP原理

  • C:Consistency 一致性,每次读取的数据都应该是最新写入的数据或者返回一个错误,而不是过期数据。也就是说要么不返回数据,只要返回数据一定正确

  • A:Availability 可用性,每次请求都可以得到一个响应,而不是错误结果或者是去响应。这个响应不需要保证数据是最新的。也就是说系统可以一直保持响应,不会导致调用者的异常,但不保证每次数据一定是最新的

  • P:Parition tolerance,分区耐受性,即使因为网络原因部分服务器节点之间消息丢失或者延迟,系统依然是可以操作的

  • 其中C和P是冲突的

  • 最终一致性解决方案

  • 写冲突处理,根据时间戳,最后写入覆盖

  • 投票解决冲突(Cassandra)

  • 写请求尝试写入时,需要等待半数以上节点响应更新成功。

  • 读请求需要等待半数以上节点返回数据,如果数据不同需要内部投票决定最终数据。

  • 如果读写请求无法得到半数以上节点响应,那么这些请求就无法成功处理,因此失去了部分可用性

Hbase解决方案

  • Hbase的数据存储在HFile中,存储在Hdfs中,每条数据做三个备份。一条数据选择一个HRegion进行存储,HRegion通过Hdfs做备份存储。应用程序找到Hmaster获取到指定的HRegionServer,HRegionServer将数据路由到HRegion上,再存储进入HFile

  • 所以如果HMaster不可用,整个系统就会异常。所以需要HMaster集群,但是HMaster不可以同时做出响应,否则相当于集群脑裂,此时需要zk进行选举主HMaster,当主master宕机后,由zk重新选举新的主master。

  • 如果HRegionServer挂掉,此时如果有请求访问Hbase会返回该HRegionServer不存在,需要等待Hbase系统将这个HRegionServer负责的key重新分配给其他HRegionServer后才能继续响应,分配过程中这部分数据是无法访问的,这个分配过程可能需要几十分钟。

  • 所以Hbase一致性较高,可用性较差

  • 

  •  Hbase的存储结构使用的是Log Structed Merge Tree(LSM树)也叫Log合并树。

  • Hbase的数据存储在Hadoop文件系统中,该系统不能对中间的数据进行修改,只能在数据结尾进行追加写,所以HFile不能对已存在的数据做修改或者删除。

  • 所以选择了LSM树,写入性能会远远高于B+树。当有写入请求时Hdfs会在内存中建一棵树根据key进行排序,不管是增加、修改、删除,都会在这颗树上新增节点,删除是新增标记,修改对应着key以及变更的数据。

  • 当这颗树达到一定规模时,会和硬盘上的树进行合并,合并过程中会进行检查,对原来的数据根据key更新或删除或直接新增。

  • 所以Hbase在写入的时候只写内存并且都是增加数据

  • 读数据的时候如果是获取刚写入的数据会很快,如果是很陈旧的数据,需要按照树的新旧挨个向后查找会比较慢

  • 数据合并速度也很快,因为两棵树合并时的写操作都是顺序写

Doris分布式KV存储原理

  • 数据分区算法

  • 分配一万个虚拟节点到一定数量物理节点上

  • 利用hash算法将数据路由到指定节点进行存储

  • 需要扩容增加机器时从旧节点移动一定数量虚拟节点到新机器上(类似redis的hash槽)路由算法保持不变

  • 基本访问架构

  • 一个集群分成两个group

  • 对等Node访问

  • 读请求随机挑选一个节点,写请求同时写两个group的两个节点保证数据不会丢失

  • 可用性场景

  • 瞬时失效:秒级失效,如JVM GC时候STW,网络抖动

  • 临时失效

  • 如果写请求有其中一个节点写入失败,client会通知管理服务器,管理服务器会进行一次确认检查,如果响应还是异常,此时通知整个集群该节点失效。

  • 此时client依然还会写两份数据,只是原来应该写入失效节点的数据,会写入临时备份节点,备份节点记录的并不是最终结果数据,而是数据执行日志类似mysql binlog。

  • 应用有三种状态:正常,失效,失效恢复

  • 如果之后一段时间失效节点恢复,在提供服务前会将临时备份节点中属于自己的数据全部同步给自己,同步期间失效节点进入失效恢复状态,此时由于数据不一致该节点只写不读,如果同步期间同一份数据client又一次进行写入,此时会比较数据产生时间戳丢弃掉历史旧数据。

  • 临时失效期间可用节点会承担所有读请求

  • 永久失效:机器下线

  • 集群扩容

  • 每个虚拟节点数据存储在对应独立存储文件中

  • 将一个group节点全部进入临时失效状态

  • 将指定虚拟节点分配到新的机器上,同步虚拟节点对应数据时直接将存储文件scp到新节点,可以在分钟级完成

  • 该group恢复,同样的方式扩容另一个group

Zookeeper

  • Zab协议(简化的paxos算法):由master接收写请求,如果是从节点收到写请求会被转发给master,master向follower发出提案请求(propose),如果收到过半节点应答ack,就决定这个提案被接受,再向所有follower发送commit,从节点写入数据

  • 投票选举:如果leader节点挂掉需要重新投票选举,此时集群不可用。ZK中每个节点都有对应编号ID,选举时其余节点会投票给ID最大的节点成为leader

  • 负载均衡与失效转移

  • 监听zk一个node节点

  • 服务启动后在这个node节点下写入子临时子节点,和zk建立长链接

  • 用户获取列表时只需要获取初始监听节点的所有子节点

  • 如果服务宕机,该服务与zk长链接断开,临时节点失效,node子节点也就会移除掉异常节点

用户头像

石印掌纹

关注

还未添加个人签名 2018.11.22 加入

还未添加个人简介

评论

发布
暂无评论
第六周总结