架构师训练营 -week6- 学习总结

发布于: 2020 年 07 月 15 日
架构师训练营-week6-学习总结

分布式数据库

主从复制:用来做读写分离,提升访问性能,降低数据库并发压力。

主主复制:增加数据库服务器的负载均衡性,每次只对一个主数据库写入,另一个数据库复制主数据库的数据,当主数据库失效时,快速成为主数据库对外提供服务。

数据分片:

主要解决两个问题:单表数据量过大,单表写入操作压力过大。

硬编码实现数据分片:对用户id取余。

映射表外部存储实现数据分片:应用代码将分区键映射成服务器编号,比硬编码更灵活。实践中不多见,因为一次数据查找变成了两次数据查找,且单表数据量大的情况下,映射表的建立也是困难的。这种实现方式灵活、但增加了应用程序的复杂性、使是数据不一致可能性更高。

分布式数据库中间件实现数据分片:对应用程序透明。应用程序用访问数据库的方式访问中间件,由中间件进行路由选择数据库服务器,并写入/读取数据。

集群的伸缩:

问题:增加服务器时,要使新服务器有数据,迁哪些数据,用什么算法进行路由。

路由规则为余数哈希:原来的几个数据库的数据要互相倒腾,再将部分数据迁移给新数据库。

路由规则为一致性哈希:需对每一条数据计算验算哈希值,确定是否需要迁移到新数据库。

实践中的扩容策略:

实践中一个数据库服务器部署多个数据库实例,当扩容时,只需要将数据库实例迁移到新的服务器中。在实例迁移完成后,再改路由规则对应的url。

CAP原理

可用性:每次请求都应该得到一个响应,而不是返回一个错误或者失去响应,不过这个响应不需要保证数据是最近写入的(Every request receives a (non-error) response, without the gurantee that it contains the most recent write)。

一致性:每次读取的数据都应该是最近写入的数据或者返回一个错误(Every read receives the most recent write or an error),而不是过期数据,也就是说,数据是一致的。

分区耐受性:因为网络原因,部分服务器节点之间消息丢失或者延迟了,系统依然是可以操作的。(The system continues to operate despite an arbitrary bumber of messages being dropped or delayed by the network between noeds)

指对于一个分布式系统,特别是一个分布式数据存储系统而言,它的可用性(Availability)、数据一致性(Consistency)、分区耐受性(Partition tolerance)是不可能一次性同时满足的。分布式系统必须满足分区耐受性的条件下,可用性与一致性无法同时满足。

最终一致性:

基于CAP原理,提出的新概念,可指在用户看来数据是一致的。

最终一致性解决写冲突:

简单处理冲突:根据时间戳,最后写入覆盖。(要求时间戳的一致性)

客户端解决冲突:交给用户决定数据的最终写入。

投票解决冲突(Cassandra):尝试写入多个节点,等待至少一般以上节点响应更新成功。尝试从多个节点读取,等待至少一半以上节点返回,取最新版本,当数据不一致时,需进行投票决定。

数据库比较指标:

ACID与BASE

ACID:针对关系型数据库

A:原子性(Atomicity),事务要么都完成,要么都取消。

C:一致性(Consisntency),只有合法的数据才能写入数据(例unique key)。

I:隔离性(Isolation),多个事务同时运行,事务的最终结果是相同的。隔离性主要靠锁实现。

D:持久性(Durability),一旦事务提交,不管发什么,数据都要保存在数据库中。

BASE:针对NoSql数据库

BA:基本可用(Basically Available),指系统出现不可预知故障时,允许损失部分可用性。

S:弱/软状态(Soft state),指允许系统中的数据存在中间状态,并认为中间状态的存在不会影响系统的整体可用性。

E:最终一致性(Eventually consistent),指系统中所有的数据副本,在经过一段时间的同步后,最终能达到一个一致的状态。

Doris

系统架构主要包含四个部分:kv-client、data-server、store、administration

关键技术点:数据分区(路由选择)、临时失效的fail over、永久失效的fail over、扩容实施数据迁移

解决海量数据存储、客户端计算分区、分区算法、client向config server抓取分区配置。

基于虚拟节点的分区算法

轮询各个物理节点的虚拟节点个数,根据物理节点上虚拟节点个数与物理节点上应有的虚拟节点平均个数来决定哪些虚拟节点需要被迁移到新的物理节点上,再修改相应的映射关系。

均衡性:数据分布均衡

波动性:X/(M+X),优于一致性Hash的X/M

基本访问架构:

需有两套group,kv-client同时写多个服务器,读取数据时,随机从一个group中读取数据。

瞬时失效:

在秒级能恢复访问的情况下时,用重试的方式(一般3次)。

临时失效:

当重试阶段没有成功时,会将某节点失效的信息通知到config server,config server也尝试连接访问(3次),如果尝试过程中,访问成功,则判定节点失效不成立,否则,确认节点失效,并通知到所有的kv-client,使其不再访问该节点,并启用备用节点。

在失效节点未恢复的过程中,数据仍旧写入到正常运行的节点,且将数据操作日志写入到备用节点中。在失效节点恢复期间,将备用节点的数据迁移回节点中,这个过程中只写不读,数据迁移时,发生数据冲突则用时间戳进行判定选择。

永久失效:

当超过一定时间(可在adminstration进行配置)没有恢复,则判定该节点永久下线,系统发出报警到运维人员。手动添加新服务器节点,且复制一份数据到新服务器节点中。

扩容实施数据迁移:

将虚拟节点物理化为一个文件,计算出需迁移的虚拟节点时,则将对应的文件复制到新的物理节点上(前提,一台一台的加)。

ZooKeeper

在分布式环境中,ZooKeeper可提供做出一致性决定的帮助,避免分布式脑裂。

ZooKeeper的zab协议是基于分布式一致性算法Paxos做了改进。

发布于: 2020 年 07 月 15 日 阅读数: 11
用户头像

晓-Michelle

关注

还未添加个人签名 2020.05.30 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营-week6-学习总结