学习总结 - 第 6 周

发布于: 17 小时前

本周老师继续讲解第五章内容,包括分布式数据库、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、扩容实施数据迁移等。

用户头像

饶军

关注

还未添加个人签名 2020.03.23 加入

还未添加个人简介

评论

发布
暂无评论
学习总结 - 第 6 周