第六周总结

本周对分布式数据库的数据分片，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就是这么实践的，大家可以借鉴一下。