学习总结 - 第 6 周

本周老师继续讲解第五章内容，包括分布式数据库、NoSQL、ZooKeeper1、Doris等

一、分布式数据库

1. 数据分片，数据分片可以使用硬编码或映射表外部存储两种方式。映射表外部存储需要专门的映射表来维护分片信息，更加灵活，维护起来也会更复杂。

数据分片挑战有：需要大量的额外代码，处理逻辑因此变得更加复杂；无法执行多分片的联合查询；无法使用数据库的事务；随着数据的增长，如何增加更多的服务器。

1. 分布式数据库中间件，Mycat，以Amoeba/Cobar架构实现，可通过路由配置分布式数据库。每个服务器部署多个schema数据库，扩容时，可以将部分schema同步到新的服务器。

2. 数据库部署方案，有单一数据库、主从复制实现伸缩、分服务多个数据库集群、综合部署（按服务划分和分片数据库综合使用）。

二、NoSQL

1. CAP原理。C代表一致性，A代表可用性，P代表分区耐受性。一致性表示每次读取的数据都是最近写入的数据或者返回一个错误，而不是过期数据。可用性表示系统一直是可以正常使用的，不会引起调用者的异常，但不保证响应的数据是最新的。分区耐受性，表示即使网络原因部分服务器节点之间消息丢失或者延迟了，系统依然是可以操作的。

CAP原理，对于分布式系统必须要满足分区耐受性的前提下，可用性和一致性无法同时满足。

1. CAP原理与数据存储冲突，可以通过最终一致性来满足系统的一致性和可用性。

解决最终一致性冲突：1）可以根据时间戳，最后写入覆盖。2）由客户端解决冲突。3）投票解决冲突

1. Hbase架构，使用Zookeeper作为分布式的协调，RegionServer把自己的信息写到Zookepeer中。RegionServer为数据节点，存储数据。RegionServer实时向HMaster报告信息，HMaster知道全局的ResgionServer的运行情况，可以控制RegionServer的故障转移和Region的切分。HDFS是Hbase的底层文件系统。

2. Log Structed Merge Tree，Hbase的存储方式，比传统的B+树有更好的写操作吞吐量。原理是将写操作保存到一些相似的有序文件中，每个文件包含短时间内的改动，文件是有序的，所以之后查找会很快。文件是不可修改的，新的更新只会写到新文件中，通过周期性的合并减少文件个数。

三、Zookepper

1. 重点介绍了分布式一致性算法Paxos。

有三个角色，Proposer、Acceptor、Learner。分三个阶段，Prepare阶段，Proposer向Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行承诺。Accept阶段，Proposer收到多数Acceptors承诺的Pormise后，向Acceptors发现Propose请求，Acceptors针对收到的Propose请求进行处理。Learn阶段，Proposer收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有的Learners。

1. Zab协议，Zookeeper优化了Paxos算法。

四、Doris-海量KV Engine，老师通过这个案例介绍了自己设计的NoSQL数据库，从现状分析、项目汇报、产品需求、产品目标、技术指标、逻辑架构、概念模型、关键技术点、产品规划、项目计划、实施计划、专利申请等各方面介绍了该项目从立项、规划、实施、落地的完整过程。并介绍了关键的技术点，包括数据分区、基于虚拟节点的分区算法、集群管理模式、临时失效的failover、永久失效的failover、扩容实施数据迁移等。