分布式数据库如何平衡一致性和读写延迟.docx

《分布式数据库如何平衡一致性和读写延迟.docx》由会员分享，可在线阅读，更多相关《分布式数据库如何平衡一致性和读写延迟.docx（12页珍藏版）》请在第一文库网上搜索。

1、分布式数据库如何平衡一致性和读写延迟?为了提供高可用能力、避免数据丢失，在分布式数据库或存储系统中需要设立数据副本机制，而副本的引入，可以说是分布式存储中的万恶之源。多副本之间应该满足强一致吗？强一致会导致请求延迟增加多少？强一致约束下能提供哪些可用性？诸如此类，种种问题，不一而足。此外，分布式系统中的CAP原理可以被表述为：在网络分区存在的情况下，强一致与可用性是不可兼得的。由此发展出符合BASE标准的NoSQL数据库，在这类数据库中，以最终一致性取代强一致性。那么，我们所说的强一致和最终一致究竟是指什么呢？强一致意味着多副本数据间的绝对一致吗？显然，在分布式系统中，由于网络通信延迟的存在，

2、多副本的严格一致是不可能的。那是代表返回写入请求时多副本已经达到完全一致了吗？熟悉Raft的朋友会立即指出，不一定，Raft就只需要在quorum中（超过半数）副本达成一致即可返回写入成功。抑或是只需要quorum的一致即可吗？这决于具体的算法，如果我们不限定读取操作只被leader处理，那么，达成quorum 一致之后仍然可能读取到旧数据。而在实际系统中，一致性问题的解法可能更加复杂，需要在一致性、读写延迟中做出权衡。以时序数据库TDengine为例,我们为元数据的读写提供强一致性；时序数据在部分场景中则需要降低读写延迟、提高吞吐，仅需满足最终一致即可；而在另一些场景中，时序数据又需要有强一

3、致保证。为了更好地探讨一致性的相关问题，我们首先需要为不同的一致性级别下一个定义。从并发模型中的一致性到分布式多副本一致性一致性模型(consistency model )最早是定义在并发模型上的lo常用的一致性级别定义包括以下5种：严格一致性(strict consistency )线性一致性(linearizability ,又译可线性化)顺序一致性(sequential consistency )因果一致性(casual consistency )FIFO 一致性(FIFO consistency,又称 PRAM consistency, pipelinedRAM concsistenc

4、y ) o之所以能够从并发模型直接推广到分布式多副本系统，是因为它们都可以建立在抽象的多读者、多写者寄存器(MWMR register, multiple writermultiple reader register)模型之上2o值得注意的是，这里的寄存器是抽象的概念，并不是硬件寄存器。它泛指定义了读、写操作的一系列值的存储对象。在并发系统中，读操作与写操作可能是多线程并发地在不同CPU上执行;在分布式系统中，它们可能是多进程被分布在不同的物理节点上执行。但相同的是，这两类系统中的读操作与写操作都有一定的延迟，不是瞬间完成的。为了便于理解，我们不会照搬形式化的定义，而是提供一些更符合直觉，但不

5、失准确的描述。线性一致性：假设在分布式系统中存在绝对的物理时钟(真实时间)，进程与进程之间不存在时间的漂移。那么，我们将读写操作的开始与结束的真实时间记录下来，为每个操作从开始到结束的持续时间段中选择一个时刻点，视该操作为在此时刻瞬间完成。如此，所有操作都可以被等效为一个进程在真实时间轴上瞬时完成的读写操作。若所有的读操作得到的都是上一次写操作的结果，那么，该系统满足线性一致性。PlA read) t 1足read。t 2图1可以看到，进程p3的写操作R.write(3)开始和结束都分别晚于进程p2的写操作R.write(2)的开始与结束，但由于它们时间有交的,R.write(3)的线性化点(

6、操作的等效时刻)可以先于R.write(2)o因此，图1系统满足线性一致性。顺序一致性：但是在实际的分布式系统中，并不存在绝对的真实时间3o因此，在外部的观察者看来，任意单个进程的操作顺序是确定的，但考虑所有操作的某种全序关系时，一个进程的读写操作可以被插入到其他进程的任意两个操作之间。不同的插入方式，会生成不同的全序关系，只要能保证存在一个合法的全序关系，则满足顺序一致性。所谓的合法是指：1.全序化后读操作必须读到上一个写操作的值；2.单个进程内的操作先后顺序与在全序关系中的操作先后顺序一致。Init x:=0Read x= 0Read x= 2pl1Init x := 0Write x :

7、= 2P2Init x:=0Write x := 2Total order 11Init x:=0Read x= 0Total order 21Read x= 0Read x= 2Read x= 2Write x := 2Init x:=0Read x= 0Write x := 2Read x= 2Total order 3图2Init x := 0Read x= 1Read x= 2pl11kInit x = 0一Write x:=2Write x := 1P2 11k图3由于不存在绝对时间，我们不再要求画出读写操作的起止时刻，而将其视为瞬间完成的操作。在图2中，全序1、2、3中，只有3是一

8、个合法的全序，因此图2中的读写满足顺序一致性。而在图3中，不存在一个合法的全序，因此，图3中的读写不满足顺序一致性。由此可见，线性一致性可以被看作顺序一致性在存在绝对时间的系统模型下的特例。因果一致性：由于进程p2是读取了进程pl写入的结果之后写入，进程p2的写入值和进程pl的写入值可能存在因果关系。那么，所有在同一个进程内的连续读操作都不可以先读到进程p2的写入值,再读到进程pl的写入值。Init x := 0Write x := 1P1Init x := 0Read x= 1Write x := 3P2Init x := 0Read x= 1Read x= 3P3Init x := 0Re

9、ad x = 3Read x = 1P4Init x:=0Write x := 1PlInit x := 0Write x := 3P2Init x := 0Read x= 1Read x= 3Init x := 0Read x = 3Read x = 1P4图4中，进程pl和p2 , p2先读到了 pl写x: = l的结果，然后写x: = 3o写x: = 3可能是由读x = l计算而来，因此存在因果关系。p3满足了因果一致性，p4则违背了因果一致性。图5中，p2不再读x = l,因此不存在因果关系。该系统满足因果一致性,但不满足顺序一致性。FIFO 一致性:FIFO 一致性不会考虑多个进程之

10、间的操作排序。对任意一个进程的写操作1与写操作2,若写操作1先于写操作2完成，那么任何进程不可以先读到写操作2的值，再读到写操作1的值。图3就是一个违背FIFO 一致性的例子。图4与图5中，由于不存在同一个进程中的多个写操作，因此都满足FIFO 一致性。最终一致性(Eventual consistency ):最终一致性，可以这样定义，若系统中不再发生写操作，经过一段时间后，所有的读操作都会得到同样的值。Read x= 3Init x := 0Write x := 1plLlnit X ：=0 write x := 2Read x= 3P2 11-Init x := 0Write x := 3

11、Read x= 3Init x := 0.Read x = 2 Read x = 1 Read x = 3P4 11图6以图6为例，最终一致的结果，既可能是1 ,又可能是2 ,还可能是3（在不存在绝对时间的系统，甚至无法定义最后写入的值是1、2还是3）,但所有进程再足够长的时间后的读结果都必须保持一致。多副本的一致性级别是由并发模型中的一致性级别直接应用到分布式系统中的结果，但有少许差别。细心的朋友可能注意到，我们并没有提及严格一致性，那是因为严格一致性要求数据被立即同步（比如在CPU的下一个时钟周期可见），这只能存在于单机系统中，并不存在于存在消息延迟的分布式系统中4o我们通常所说的强一致，

12、通常是指线性一致性或顺序一致性线性一致性与顺序一致性之间的区别，也可以被理解为系统模型的区别，即系统中是否存在绝对时间。弱于顺序一致性的一致性级别都可被称为弱一致，而最终一致性是弱一致性的一种形式。探讨一致性级别时，一个常犯的错误是与事务的隔离级别混淆，事实上，虽然它们之间存在一定的联系，但并不是同一回事。当一个数据库在隔离级别上满足可串行化(Serializable ),在一致性上满足线性一致性，则称为严格可串行化(Strict Serializable ),这是一个统一了一致性级别与隔离级别的定义。另一个常犯的错误是将一致性(consistency )与共识(consensus )混淆。共

13、识问题是在分布式系统中有明确定义的一类问题，解决共识问题的经典算法是paxos ;强一致读写可以通过一系列的全序共识实现，Raft便是这以上定义的一致性级别可以被认为是以数据为中心(Data-centric )的一致性级别，另一种定义方式是以客户端为中心(Client-centric),还可以定义出写后读、读后写、单调写、单调读的一致性，此处不再赘述4o一致性级别分析：以Raft为例下面我们以Raft为例分析其一致性级别。在正常情况下，Raft是在leader上完成读与写操作的，可以被看作单读单写的系统，若这个系统中将leader的时间视为绝对时间，则可认为提供了线性一致性。但是，我们还需要考

14、虑异常情况，当消息延迟时，Raft可能出现短暂的双主;若出现网络分区，可能持续处于多主状态。一种实现方式是，假如每个leader在提供读服务时都不做额外操作，那么，如果多数派分区的leader已经完成了新的写入，少数派分区的leader仍然提供读服务，就可能读到旧数据。这个问题的一种解决方法是，让少数派分区的leader直接拒绝读服务。这如何实现呢？让leader在与客户端交互，完成读操作前发送一个no-op并至少得到半数回应,由于少数派分区的leader无法得到半数回应，因此无法提供读服务。关于如何在Raft中获得线性一致性的详细探讨可详见Raft论文7中第 8 节 Client Inter

15、actionoTDengine提供的一致性级别在上述的分析中可以看到，Raft中实现线性一致性会为读操作和写操作都带来至少2个RTT的延迟（client视角,从client到leader,再由leader到follower）;即使仅实现顺序一致性，也会在写时带来至少2个RTT的延迟。在TDengine中，为了降低写入数据的延迟、提高吞吐量，我们为元数据（表数据、表的标签数据）提供强一致性，为时序数据提供最终一致性与强一致性两种可选的一致性级别。当用户选择最终一致同步，写入的延迟可以被降低到1个RTT （从client到leader）,这大大优于Raft这类强一致复制协议提供的性能。随着TDengine集群版的开源