分布式数据库、NoSql、Zookeeper 与 Doris

一、数据库的演进



二、分布式数据库

1.CAP原理

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能同时满足其中的2个。

当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不可用；

要么我们继续写入数据，但是数据的一致性就得不到保证。



对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受形是必须要保证的，那么在可用性和一致性上就必须二选一。



当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个错误吗或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个数据，但是并不能包含保证这个时间是最新的。



所以，关于CAP原理，更准确的说法儿是，在分布式系统必须要满足“分区耐受性”的前提下，可用性和一致性无法同时满足。

2.CAP与数据一致性冲突

大多数的分布式数据库系统都存在一些数据的一致性冲突，通常都是使用数据最终一致性的方案解决的。

如下图



对于数据库的分布式系统而言，大部分时候还是对一致性要求稍高一些。

2.1数据冲突处理策略

1.服务端根据时间戳，最后写入覆盖。

2.客户端解决冲突

比如下图，这个其实就是业务进行了选择。

3.投票解决冲突

Cassandra是典型代表

1.客户端在客户端写入数据的时候在集群中尝试写入三份数据，至少有2个服务器回复相应成功，客户端才响应成功。

2.另一个客户端在读数据的时候会从上面的三个节点读取数据，看返回的数据投票了决定看哪个返回的数据是最新的，至少要等到两个返回，要是这俩一样就要等第三个，是牺牲了一部分可用性的。



Cassandra的分布式架构

三、NoSql

1.Hbase的架构

数据分片，HRegion会通过hadoop的HDFS对数据做备份存储，同时写了三份儿数据, 提高了可用性。



流程：

1.应用程序问HMaster，我要读写的key-value要落在哪个HRegionServer上，HMaster告知要用哪个HRegionServer

2.应用程序就和上一步的HRegionServer进行通信，把数据发过去。

3.HRegionServer会找一个HRegion(分片)，HRegion会把数据写入到一个HFile里面去。

4.HFile自己去做数据的复制，复制了3份儿。



Zookeeper在这里是选主的作用，HMaster部署的可以是一个集群，当一个HMaster Down机的时候Zookeeper就可以重新选出一个主master继续提供服务。



场景：一个HRegionServer Down机

当一个HRegionServer Down机不可用的时候，其中的HFile是存储到Hadoop的HDFS里的，数据本身是有多个备份的，所以当HRegionServer挂掉的时候，文件存储还是存在的。只要把这个Down掉的HRegionServer负责的key分配给别的HRegionServer上面去就可以了，HFIle的数据是存储到了多个服务器上的，即使这台down掉了，是不影响数据的存取的。它的可用性是差一些的。



HRegionServer仅仅是管数据的读写的，存储不归它管，数据的存储是HDFS来搞定的。



总结:

1. 路由，应用程序通过HMaster的回复来进行路由，HMaster会告诉要把数据存储到哪。

2. 扩容，加一个新的服务器的时候，会进行HRegion分裂，HRegion上的一部分key给新的服务器即可，

访问的还是同样一份HFile，HFile是不会迁移的。

1. 一个key只会由一个HRegionServer负责解决了数据的一致性。



访问数据流图



2.ACID与BASE对比

关系型数据库ACID概念(拴)

1.原子性(Atomicity)：事务要么全部完成，要么全部取消。如果事务崩溃，状态回到事务之前(事务回滚)

2.隔离性(Isolation)：如果2个事务T1和T2同时运行，事务T1和T2最终的结构是相同的，不管T1和T2谁先结束，隔离性主要依靠锁实现。

3.持久性(Durability): 一旦事务提交，不管发生什么 (崩溃或者出错)，数据要保存在数据库中。

4.一致性(Consistency): 只有合法的数据(依照关系约束和函数约束)才能写入数据库。

NoSql数据库BASE概念(解)

1.基本可用(Basically Available) 系统在出现不可预知故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失。

2.Soft state(弱状态) 软状态，指允许系统中的时间存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3.Eventually consistent(最终一致性) 指系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性。



四、Doris

1.汇报文档策略

这个ppt是用来争取机会的，它是有套路和模版的。

比如: 说明当前现状，产品需求。

产品目标

这里以Doris的设计为例，产品目标是要去解决现状的问题和满足产品的实际实际需求的。

1.功能目标: kv存储Engine 逻辑管理(Namespace) 二级索引

2.非功能目标：

海量存储: 透明集群管理，存储可替换

伸缩性: 现行伸缩，平滑扩容

高可用: 自动容错和故障转移

高性能: 低响应时间，高并发

扩展性: 灵活扩展新功能

低运维成本：易管理，可监控

3.约束: 一致性，最终一致性

技术指标

逻辑架构

如上的逻辑架构，是分为三个组件。

1.客户端的sdk 2.数据存储服务器的DataServer 3.管理服务器Administrator



逻辑描述

1.提供了一个Client的SDK，应用程序就用这个sdk

2.集群中每个服务器中部署一个Data Server用来对服务器进行管理

3.数据将通过分片+路由选择的形式，写入到这些机器中

4.很多其他的NoSql都是没有Administration这个管理中心的

    它提供了配置，管理和监控三个方面的支持.

    它和HMaster有点儿像，但是又比它职责更多

配置就是: 当集群中启动了一个DataServer，应用程序如何知道呢？

    各个DataServer之间是互不感知的，启动一个DataServer的时候，要配置管理中心的IP地址

    它要向管理中心进行通报，在配置集群里面启动了一个服务器。

    包括服务器的角色是什么样子的，有两种角色。

    启动了之后就会修改配置中心的Config配置项，Administration知道了集群中配置了一台新

    机器，首先控制中心会对集群进行管理。数据要进行迁移， 待数据一致了能够对外提供服务了后。

    管理中心就会把这个新机器的配置项推送给应用程序的ClientSDK，SDK知道了集群中多了一台机器

    会用新的路由算法去算，如何路由到新的机器。

5.机器的状态要在管理控制台上点一下儿，比如扩容的时候新增的机器就要在管理界面的控制台上去控制,包括机器失效的时候，和恢复的时候都要在管理控制台进行管理

6.Monitor是监控器

五、Zookeeper

1.分布式系统脑裂

在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行命令，导致整个集群陷入混乱，数据损坏，称作分布式系统脑裂。

比如：主主复制的数据库，两个主数据库不能同时写的，因为会发生数据冲突，主主复制一定有一个主活动服务器，另一个就是主备份服务器，只能向主活动服务器写，这个时候就需要一个仲裁服务，zookeeper就是提供这样的服务的一个系统。

2.一致性算法Paxos

这算法早期的时候，主要用于讨论分布式系统中的锁如何获得。

三个角色: Proposer 提案者 Acceptors 接受者 Learner 学习者

当要做一个一致性的决策的时候的流程

1.要给Proposer提出一个提案

2.Proposer给整个集群中的Acceptors发送这个提案

3.由Acceptors来判断这个提案要不要接受

4.当有超过半数儿的Acceptors决定接受这个提案的时候，就要把这个确认的结果发送给Learner

5.所有的Learner也就得到了确认的结果了

Acceptors是有可能不接受提案的，因为有的应用是A Client发的提案，有的应用是B Client发的提案，某一个Acceptors接受了B的提案了，它就会拒绝A的提案。最后多个Acceptors来决定接受哪个。

多数同意的就会被接受，达成一致。

2.1 实际执行的3个阶段



1.Prepre阶段。Proposer向Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行Promise承诺。

2.Accept阶段。Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出 Propose请求，Acceptors针对收到的Propose请求进行Accept处理。

3.Learn阶段。Proposer在收到多数Acceptors的Accept之后，标志这本次Accept成功，决议行程，将形成的决议发送给所有Learners。

2.2 关注点

Proposer生成全局唯一且递增的Proposal ID(可使用时间戳加Server ID), 向所有Acceptors发送Prepare请求，这里无需携带提案内容，只携带Proposal ID。



Acceptors收到Prepare和Propose请求后

1. 不再接受Proposal ID小于等于当前请求的Prepare请求.

2. 不再接受Proposal ID小于当前请求的Propose请求。



3.Zab协议

Zab协议是Zookeeper在实现的时候对Paxos做了简化，这个名字是Zookeeper官方起的。

角色: Leader和Follower

1. 多个请求leader排队处理, 一个请求(提案)，当提交到集群的时候，先交给Leader，

由它来发起整个提案的决策。

1. Leader向Follower发出提案，如果Follower接受提案的话就会回复一个Ack应答。

2. 当Leader收到超过半数儿的Ack应答的时候，就决定是可以接受了的。

3. 再向所有的 Follower发送一个Commit确认。



下面这个是整个的决策过程:



数据库主主复制主服务器的选举过程

1. getdata("/servers/leader",true)

先getdata Leader的值

1. if successful follow the leader described in the data and exit

如果leader不存在说明当前没有leader，服务器就可以抢注了

1. create("/servers/leader",hostname,EPHEMERAL)

没leader的话，就把自己的主机名写进去, EPHEMERAL表示是一个临时路径

创建成功了后，当前的数据库服务器应该有就要与Zookeeper保持长链接。

当服务器down掉的时候，因为这里设置的是一个临时路径，Zookeeper就

会把上面保存的临时path路径删除了, 所以其他的服务器

再查询路径的时候就会发现没有主服务器了，就会抢注。

1. if successful lead and exit

2. goto step 1

4.性能特征

从上图中可以看出来的特征:

3台服务器的写操作的性能要比更多台服务器要块，这是因为Zookeeper的投票决策的特性决定的，机器数量越少决策的越快，当机器很多的时候读操作也就非常块了。