架构师训练营第六周总结

发布于: 4 小时前
架构师训练营第六周总结

分布式数据库

主从复制

MySQL主从复制使用一台Master一台Salve两台数据库服务器组成主从复制,主库负责写,从库负责读,有效降低了主库的读写压力。主库上所有数据更新都记录在binlog之中,从库会定时从主库读取binlog然后保存为relaylog,并由从库的sql执行线程执行重放以达到数据同步的目的,从库可以有多台,以分散读请求压力。MySQL主主复制,实际上客户端还是只会写入一个主库,另一个主库平时会自动同步数据,每个台主库又可以有多台从库用于处理读取请求,一旦写主库发生故障,会自动转移到备用的主库继续写,同时读请求也会转为发送给备用的从库,至此备用主从就转变为了主主从,等到故障的主库恢复后,会从备用主库同步数据成为备份主从,主主复制主要是提高了数据库的可用性。

数据分片

分片即将不同的数据记录分散存储在不同的数据库中。常用的分片方式有:硬编码分片,应用代码将分片Key映射成服务器编号;映射表外部存储分片,即查表法,在外部存储Key和服务器编号的对应管理,请求时通过查找该表的方式查出目标服务器;分片会大幅降低数据库的查询能力,需要大量额外代码来访问数据,无法执行跨分片的联合查询,无法使用数据库事务。分片的编码方式又可以分为客户端SDK和分片中间件两种方式:客户端方式即应用引入分片SDK,通过SDK解析SQL语句,然后根据预设的路由规则由执行代理路由到指定的服务器,然后将返回的结果进行合并后返回给应用;中间件的方式,核心模块和SDK方式一样工作,但是在前后端增加了用于远程调用的通讯模块。现在主流采用的是中间件模式。分片之后面临的一个问题就是如果数据继续增长,需要配置新的服务器扩容,如何以最小代价达成,如何迁移数据。数据库分片并不会采用一致性哈希算法,这个算法的问题在于当插入新的服务器节点(或虚拟节点)时,需要计算所有的Key从而决定数据的迁移方向,这个代价非常大。因此,现实中数据库分片多采用预定义数据库schema总数,然后使用Key对schema总数取余来得出Key要保存的schema,每个物理数据库服务器上均匀的存储多个schema,新添加服务器之后只需要将部分schema整体搬迁到新服务器上即可,这个有点类似Redis的存储桶,其实是一个逻辑单元到物理服务器的映射,Key只需要关心分片存储在哪个逻辑单元即可,物理服务器分摊逻辑单元。

NoSQL

CAP原理

一致性C:每次读取的数据都应该是最近写入的数据或者返回一个错误,而不是过期数据,也就是说,数据是一致的。即要么拿到最新数据,要么返回一个错误。

可用性A:每次请求都应该得到一个响应,而不是返回一个错误或者失去响应,不过这个响应不需要保证数据是最近写入的,也就是说系统需要一直都是可以正常使用的,不会引起调用者的异常,但是并不保证响应的数据是最新的。

分区耐受性P:即使因为网络原因,部分服务器节点之间消息丢失或者延迟了,系统依然应该是可以操作的。

当网络分区失效发生的时候,我们要么取消操作,这样数据就是一致的,但是系统却不可用;要么我们继续写入数据,但是数据的一致性就得不到保证。对于一个分布式系统来说,网络失效一定会发生,也就是说,分区耐受性是必须要保证的,那么在可用性和一致性上就必须二选一。当网络分区失效,也就是网络不可用的时候,如果选择了一致性,系统就可能返回一个错误码或者干脆超时,即系统不可用。如果选择了可用性,那么系统总是可以返回一个数据,但是并不能保证这个数据是最新的。在分布式系统必须满足分区耐受性的前提下,可用性和一致性无法同时满足。

Zookeeper

分布式系统中,不同服务器获得了相互冲突的数据信息或者执行指令,导致整个集群陷入混乱,数据损坏,便成为分布式系统脑裂。比如说MySQL的数据主主复制,同一时间只能由一台主库对外提供写服务,客户端如何知道哪台服务器是写主库?当故障发生,服务器迁移的时候,客户端又如何知道这件事?这就需要一个服务器来仲裁,但是提供仲裁的服务器自身也需要高可用,也会有多台服务器,他们的一致性又需要更高一级的仲裁,这就无穷无尽了。因此解决分布式系统的一致性算法闪亮登场,通过Paxos,Zab等协议,类似于投票选举的方式将多数节点承认的共识记录为最终结果。zk最早是为了解决分布式锁,即为了协调资源访问而诞生的,它提供了一些简单易用的API接口,可以实现分布式配置管理,Master选举等场景功能。

用户头像

一剑

关注

还未添加个人签名 2017.11.23 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第六周总结