第六周总结

关系型数据库

• 数据分片

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

• 实现方式大体分两种：

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

• 集群伸缩

• 将原来的数据存储到多个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子节点也就会移除掉异常节点