Week 06- 作业二:学习总结

发布于: 2020 年 07 月 14 日

本周的主要内容围绕分布式数据的容灾、冲突解决展开。

数据库的主从复制、主主复制:

主从复制:主数据库复制到从数据库上,这样就可以实现数据的读写分离。

主数据库写数据,从数据库读数据,一方面提升了数据的读并发的处理能力,2台服务器/更多台读数据服务器 提高了读数据的处理能力,另一方面也提高了数据库系统的可用性。

当某一台从数据库宕机时,数据库读写都不受影响。

当写数据库当机时,至少读数据库不受影响。

 

但写数据库宕机时,系统就不可用,数据库是系统的关键,于是就提出主主复制模式。

 

主主复制:2个主数据库之间进行数据同步,主主复制是用来解决数据库写操作高可用,保证一台主数据库宕机时,另一台服务器提供写服务。但不能提升写操作的并发处理能力。应用程序在连接主数据时,一个时期内只能连接一个主数据库,当其中一个主数据库宕机时,才能连接另外一个主数据库,所以2个主数据库放在一起,写操作能力并没有增强。

 

最后,不管是主从复制、主主复制所有的数据库存储的都是一要的数据,整个的数据的存储能力也没有提升。当数据量比较大时,单数据库存不下时,不管是主主复制还是主从复制都解决不了。

所以又提出来分布式数据库分片处理存储。

数据分片

主要原理模块:进行SQL解析,找到分片的键,根据分片的键,进行路由选择,选择服务器,建立数据库连接,将返回的数据进行合并,返回应用程序。

分布式数据库扩容,主要的手段是,把一开始数据库分片规划好,将来的扩容规模,服务器规模有多大,一开始就要规划好,就要分这么多的片。服务器少的时候,把很多片对应的schema/数据库实例放在一个服务器上,当服务器进行扩容时,把这个数据库schema,至接迁移到新服务器上就可以了。路由规则不用变,最多就是改规则里对应的的URL,这个分片要落到哪个URL上,改成新服务器URL即可。

CAP原理

CAP不可能三角:对于一个分布式系统而言,一致性、可用性、分区耐受性3 个指标不可兼得,只能在 3 个指标中选择 2 个。

通过CAP不可能三角进行数据存储冲突的解决(Cassandra 投票),同时为了防止服务器脑裂问题,引入分布式应用程序协调服务(e.g. zookeeper)进行调度。

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

dean

关注

还未添加个人签名 2019.11.06 加入

还未添加个人简介

评论

发布
暂无评论
Week 06- 作业二:学习总结