第六周总结

发布于: 2020 年 07 月 12 日
第六周总结

本周对分布式数据库的数据分片,NoSql数据库, Zookeeper 的知识做了讲解,同时还拿实际的Doris案例,进行了分析。还有NoSql数据库涉及到的CAP原理和由CAP延伸出来的Base原理。

数据分片:

如果应用拥有的是海量数据,而只是放在一台数据服务器上,会带来的很慢的访问效果。我们会根据不同的场景进行数据的分片,即将数据按照一定的算法,存放到不同的服务器上。

数据分片的挑战:

  • 需要大量的额外代码,处理逻辑因此变得更加复杂。

  • 无法执行多分片的联合查询。

  • 无法使用数据库的事务

  • 随着数据的增长,如何增加更多的服务器。

数据分片的实践:

最初是使用硬编码进行数据分片,根据数据的key值映射到不同的服务器。

后来使用分布式数据库的中间件,进行数据分片,满足了大多数的场景需求。

例如:分布式处理中间件Cobar的使用

Cobar系统组件模型:

数据的部署方案:

数据库的部署方案,从最初的单服务单数据库(一个数据库服务器)的架构,到单服务单数据库(主从模式的多个数据库服务器),到后来的两个服务2个数据库(主从模式的多个数据库服务器),到最终使用数据分片的综合部署策略,才让数据分片浮出水面。

CAP原理

详情见https://xie.infoq.cn/article/3b742d7216f5e9721f7729861

分布式数据库的最终一致性

分布式数据库,最终要实现数据的最终一致。

简单的冲突处理策略是: 根据时间戳,最后写入覆盖。

后来,比较流行的是投票解决冲突的方式,例如Cassandra,在写入数据时,如果是三个服务器节点,会等待至少2个更新成功,才算成功。而读取数据时,尝试从三个服务器节点读取数据,等待最少两个节点返回结果,才能获取最新版本的数据。

分布式系统脑裂:

在一个分布式系统中,不同服务器获得了相互冲突的数据信息或者执行指令,导致整个集群,陷入混乱,数据损坏,被称作分布式系统脑裂。而ZooKeeper就很好的解决了这个头疼的问题。

ZooKeeper :

ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

ZooKeeper中的Zab协议使用了分布式一致性算法Paxos。 Paxos其=中有三个角色:Proposer(提议人), Acceptor(接受者),Leaner(学习者)。

Paxos算法的实现逻辑是:

第一阶段:Prepare阶段

Proposer 向Acceptors发出Prepare请求,Acceptors 针对收到的Prepare请求进行Promoise承诺。

第二阶段:Accept阶段

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

第三阶段:Learn阶段

Proposer在收到Acceptors的Accept之后,标志着本次Accept成功,决议形成,将形成的决议发给所有的Learners.

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

Acceptors 收到Prepare 和 Propose请求后:

  • 不再接受Proposal ID 小于等于当前请求的Prepare请求。

  • 不再接受Proposal ID 小于等于当前请求的Propose请求。

这样就不会出现2个propose的进行提案的冲突。

Zookeeper使用的Zab协议就是基于算法,实现了ZooKeeper Server里面的Leader Server的选择,来解决分布式系统脑裂的问题。

在讲解Doris案例时,老师提到如何让公司支持你做一个新产品,首先要知道怎么做,有哪些关键技术点,把核心的思路捋顺。然后,再去把产品的亮点和使用后能解决的问题,着重突然出来。这个思路,是很不错的,并且在Doris就是这么实践的,大家可以借鉴一下。

用户头像

胡江涛

关注

放肆才叫青春 2019.05.11 加入

IT软件工程师,一枚

评论

发布
暂无评论
第六周总结