分布式存储及分布式一致性算法

Date:  2020/7/15    V1.0

Author： Jessie

前言

分布式数据库和分布式存储是分布式系统中难度最大的地方。本周根据实际中遇到如下问题的解决方案和演进思路进行梳理：

l  如何提高数据并发读能力

l  如何提高数据并发写能力

l  如何进行数据库部署

l  CAP原理

l  HBSE

l  分布式一致性算法Paxos

l  Zookeeper

数据复制——提高数据并发读能力

目的：数据复制能提高数据读并发操作能力。

MySQL数据复制：包括主从复制和主主复制。

1.利用主从复制实现数据库读写分离，写操作访问主数据库，读操作访问从数据库，从而使数据库具有更强大的访问负载能力，支撑更多的用户访问。



一主多从的优势：

分摊负载、专机专用、便于冷备和高可用



2. 主主复制：



a.不要对两个数据库同时进行数据写操作，因为这种情况会导致数据冲突。

b.复制只是增加了数据的读并发处理能力，并没有增加写并发的能力和系统存储能力。

c.更新数据表的结构会导致巨大的同步延迟。

数据分片——提高数据写并发能力

数据分片的目标：

数据复制只能提高数据读并发操作能力，并不能提高数据写操作并发的能力以及数据整个的存储容量，也就是并不能提高数据库总存储记录数。如果我们数据库的写操作也有大量的并发请求需要满足，或者是我们的数据表特别大，单一的服务器甚至连一张表都无法存储。解决方案就是数据分片。

分片的方案：

将一张数据表切分成较小的片，不同的片存储到不同的服务器上面去，通过分片的方式使用多台服务器存储一张数据表，避免一台服务器记录存储处理整张数据表带来的存储及访问压力。

利用分片键的路由算法。通过分片键，根据某种路由算法进行计算，使每台服务器都只存储一部分数据。一个分片存储到哪个服务器上面去，到哪个服服务器上面去查找，是通过分片键进行路由分区算法计算出来的。在SQL语句里面，只要包含分片键，就可以访问特定的服务器，而不需要连接所有的服务器，跟其他的服务器进行通信。

现在有一些专门的分布式数据库中间件，比较知名的有Mycat。Mycat是一个专门的分布式数据库中间件，应用程序像连接数据库一样的连接Mycat，而数据分片的操作完全交给了Mycat去完成。

数据库部署

• 单一服务和单一数据库 

• 主从复制实现伸缩     

• 两个Web服务及两个数据库     

• 综合部署方案 



CAP原理与高可用数据



对于分布式系统而言，网络失效一定会发生，那么分区耐受性必须保证，那么就需要在可用性和一致性上二选一。也即是CAP原理下，三个原则是无法同时满足的。

传统关系数据库CP，牺牲A，现在互联网应用大都为AP，牺牲部分C，利用其它补偿做到数据最终一致。

通过数据备份（数据冷备、数据热备：异步热备，同步热备）、失效转移保证数据的高可用性。参考Doris的案例实现原理，理解故障时，如果做到数据的访问转移、备份恢复。

详见我的另一篇详解: CAP原理及Doris案例分析:https://xie.infoq.cn/article/81bce1f6b89ec2030aee03056



HBASE——分布式存储系统

HBase是一个构建在HDFS上的分布式列存储系统；基于Google BigTable模型开发的，典型的key/value系统；主要用于海量结构化数据存储。与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

hbase之所以是CP系统,实际和底层HDFS无关,它是CP系统,是因为对每一个region同时只有一台region server为它服务,对一个region所有的操作请求,都由这一台region server来响应,自然是强一致性的.在这台region server fail的时候,它管理的region failover到其他region server时,需要根据WAL log来redo,这时候进行redo的region应该是unavailable的,所以hbase降低了可用性,提高了一致。



分布式一致性算法Paxos及活锁、过半问题

Paxos算法

在一个分布式系统中，不同服务器获得相互冲突的数据信息或执行指令后，导致集群陷入混乱，成为“分布式系统脑裂”。引入分布式一致性算法。

业界广泛使用在分布式计算中的Paxos，是一种基于消息传递的分布式一致性算法，由Leslie Lamport发明。Google的Chubby，Apache的Zookeeper都是基于它的理论来实现的。Paxos算法需要解决的问题就是如何在一个可能发生集群机器异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致。也可以理解成分布式系统中达成状态的一致性。

Paxos算法中有三个角色：

• Proposer提议者。只要Proposer发的提案Propose被半数以上的Acceptor接受，Proposer就认为该提案例的value被选定了。

• Acceptor接受者：只要Acceptor接受了某个提案，Acceptor就认为该提案例的value被选定了

• Learner记录员：Acceptor告诉Learner哪个value就是提议者的提案被选定，Learner就认为哪个value被选定。

在具体的实现中，一个进程可能同时充当多种角色。比如一个进程可能既是Proposer又是Acceptor又是Learner。Proposer负责提出提案，Acceptor负责对提案作出裁决（accept与否），learner负责学习提案结果。



Paxos是基于消息传递的具有高度容错性的分布式一致性算法。

Paxos算法分三个阶段：

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

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

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



Paxos算法的活锁问题（保证算法活性）

可能还会存在一种极端情况，当有两个proposer依次提出一系列编号递增的议案，那么会陷入死循环，无法完成第二阶段，也就是无法选定一个提案。

通过选取主Proposer，就可以保证Paxos算法的活性。选择一个主Proposer，并规定只有主Proposer才能提出议案。这样一来，只要主Proposer和过半的Acceptor能够正常进行网络通信，那么肯定会有一个提案被批准（第二阶段的accept），则可以解决死循环导致的活锁问题。

 “主Proposer”也是通过Paxos过程选定的，只不过这次选定的“值”就是主Proposer。

过半概念

Paxos算法引入了过半的概念，也就是少数服从多数。解决了2PC，3PC的太过保守的缺点，且使算法具有了很好的容错性，另外Paxos算法支持分布式节点角色之间的轮换，这极大避免了分布式单点的出现，因此Paxos算法既解决了无限等待问题，也解决了脑裂问题。

Zookeeper



为了简化Paxos实现，Zookeeper使用了一种叫ZAB（ZooKeeper Atomic Broadcast，ZooKeeper原子消息广播协议）的算法协议。基于ZAB算法，Zookeeper集群保证数据更新的一致性，并且通过集群方式保证了Zookeeper系统高可用。但是Zookeeper系统中所有服务器都存储相同的数据，也就是数据没有分片存储，因此不满足分区耐受性。

大数据系统通常是主从架构，主服务器管理集群的状态和元信息，为了保证集群状态不发生脑裂，所以运行期只能有一个主服务器工作，举HDFS的例子来说，也就是一个Active状态的Namenode，但是为了保证高可用，所以还需要一个Standby状态的Namenode。

很多大数据系统都依赖Zookeeper提供的一致性数据服务，用于选举集群当前工作的主服务器。一台主服务器启动后向Zookeeper注册自己为当前工作的主服务器，因此另一台服务器就只能注册为热备主服务器，应用程序运行期都和当前工作的主服务器通信。

因为Zookeeper系统的多台服务器存储相同的数据并且每次数据更新都要所有服务器投票表决， 所以和一般的分布式系统相反，Zookeeper集群的性能会随着服务器数量的增加而下降。



参考文献

https://blog.csdn.net/h_rhui/article/details/95339894

https://blog.csdn.net/woshiwanxin102213/article/details/17584043

https://blog.csdn.net/liao0801_123/article/details/106925567

https://blog.csdn.net/weixin_44240370/article/details/98479283