分布式下的MS

MS模式是分布式系统中非常重要的一种复制模式,为了和配图协调,请允许这里直接使用了master-slave的缩写,没错,MS!

好,从现在开始,我们的标题变为:分布式系统下的master-slave复制。

什么是复制?

复制的意思很明显,就是把一份数据复制到指定的节点上。

复制的种类

复制现在主要有两种,一种主从复制,还有一种就是对等复制。

这里主要关注主从复制。

主从复制主要的动作

在主从分布的情况下,你把一份数据复制到多个节点。其中一个节点作为master。这个master是数据的权威同时通常也负责数据的更新。除了master之外的其它节点为slave或者叫secondaries。主从复制过程就是把数据从master同步到slave的过程。

上面这张图是就是数据从master复制到slave。master处理所有的写操作;而读数据可以从master上读也可以从slave上读。

主从复制能够解决哪些问题?

1、提高读取能力

在需要频繁读取数据集的情况下,主从复制可以通过扩展来提高读取性能。你可以通过增加更多的slave节点的方式,通过这种水平扩展的方式,来处理更多的读取请求。并且可以把所有的读取请求都交给slave节点来处理。

2、故障恢复能力

(1)、读取故障恢复能力

master挂了,slave节点依然可以处理读取。这种优势对于那种大部分情况都是读取的场景是非常有用的。

要想让读取具备故障恢复能力,那么我们就要把写在我们的应用程序里边的“读”的path和“写”的path分开,也就是他们的path必须是不同的,这样你的写操作出现故障时,我们的读取依然坚挺。读写分离怎么搞呢?就是要你通过两个独立的分开的数据库connection来分别提供读和写。这样的能力一些的数据库交互库都是不提供的。当然了,你要开发这样的支持,其实和开发其它的功能是一样的,也是要通过不断的测试来确保这个故障恢复能力的有效性。我们可以把写操作禁用了,然后再试试看是不是能正常的读取。

(2)、写入故障恢复能力

当master挂了以后,自然就不能提供写入能力了。现在整个集群是一个只提供读取能力的集群。直到出问题的master自己恢复了过来或者一个新的master被选举出来。所以在主从架构下,slave作为master的备份就很关键,这样即使master挂了,我们也可以非常迅速的就从茫茫的slave中选出一个新的master来。

这种快速选出新的master的能力,让主从复制变得很有用,即使没有了提高读取性能的能力。当我们的slave节点专心做备份这一件事情的时候,我们就可以把所有的读取和写入都交给master来做。这样的做法是不是会让你很容易联想到那种热备份的单机方案。这种方案让你既拥有了单机配置的简单又拥有强大的故障恢复能力。

现在再来说说选master的这个事情。master可以手动配置指定,也可以是通过自动选举产生。手动指派的意思就是在你配置集群的时候,就配置一个node作为master。自动指派就是指在你创建了集群了以后,他们就热闹地开始选举了,最后在茫茫的节点中选出一个master来。通过简单的配置就可以在master挂掉后自动的选出新的master,这大大缩短了集群的罢工时间。

主从复制不适合的场景

频繁写入的场景

由于master节点既要负责处理写入请求,又要负责把数据同步到slave节点。自然主从复制模式对于那种频繁写入的场景并不是很适合,虽然这种模式它是分流了一部分的读取请求到slave节点,看起来好像为写入请求也有所帮助。

主从复制不足之处

不一致

主从复制是分布式系统中非常重要的复制方式之一。不一致自然也就是成了分布式系统的主要问题了。或者说在分布式系统中就压根不存在一致性,至少是绝对意义上的一致。所以也只能说说“最终一致”。

在主从复制的模式下,有可能不同的客户端访问不同的slave节点,最后得到不同的value。因为有可能master的同步工作正在做,只同步了一部分节点,另外一部分节点还没有同步完。有一种最尴尬的情况,就是一个客户端刚刚写入一条数据,然后他立马就去读自己写入的这条数据,结果没读到。即使你使用主从复制仅仅是为了做个热备份也会遇到这样的问题,因为如果master挂了,那么任何的更新将不会被同步到slave节点上去。

总结

总之,主从架构,让你的集群拥有了读取的水平扩展和备份的水平扩展能力,同时也让你拥有了failover的能力。

但主从复制也存在不足之处,那就是不具备写入的水平扩展能力,同时复制的时延让集群的一致性变得没有那么绝对。

对于那些不是频繁写入但要求频繁读取的场景是足够而实用的了。

原文发布于微信公众号 - ImportSource(importsource)

原文发表时间:2017-02-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏WindCoder

网易MySQL微专业学习笔记(十二)-MySQL容量评估

这个系列属于个人学习网易云课堂MySQL数据库工程师微专业的相关课程过程中的笔记,本篇为其“MySQL业务优化与设计”中的MySQL数据类型相关笔记。

481
来自专栏IT大咖说

微软:云原生的MySQL托管服务架构及读写分离的优化

内容来源:2017 年 08 月 24 日,微软中国首席产品经理宋青见在“ODF 2017开源数据库论坛(北京)”进行《云原生的MySQL托管服务架构及读写分离...

873
来自专栏Elasticsearch实验室

Elasticsearch分片使用优化

  与大多数分布式系统一样,Elasticsearch按照一定的Hash规则把用户数据切分成多个分片,然后打散到不同机器进行存储,从而实现大规模数据的分布式存储...

56719
来自专栏云技术

性能超前,详解腾讯云新一代Redis缓存数据库

当前内存数据库发展迅速,用户对于存储系统的要求也越来越高,为了满足各类业务场景的需要,腾讯云设计了新一代的内存数据库,不但保留了原来系统的高性能,高可用等特性,...

52216
来自专栏java、Spring、技术分享

从零开始学架构读书笔记

  软件架构的出现是为了解决系统规模增加后出现了系统耦合严重,开发效率低,逻辑复杂,扩展困难等问题。所以架构设计是为了解决软件复杂度而存在的,所以架构设计的目地...

1944
来自专栏程序员的SOD蜜

消息服务框架(MSF)应用实例之分布式事务三阶段提交协议的实现

一,分布式事务简介 在当前互联网,大数据和人工智能的热潮中,传统企业也受到这一潮流的冲击,纷纷响应国家“互联网+”的战略号召,企业开始将越来越多的应用从公司内网...

2597
来自专栏腾讯大数据的专栏

分布式系统场景注入测试

前言 大数据浪潮下,海量数据处理能力的提升是推动大数据不断前行的基础,海量数据处理的分布式系统应运而生,hdfs、hadoop、spark、storm、MQ等...

2138
来自专栏Java进阶干货

用Redis轻松实现秒杀系统

用上这三招,不论秒杀时负载多大,都能轻松应对。更好的是,Redis能够满足上述三点。因此,用Redis就能轻松实现秒杀系统。

591
来自专栏架构师之旅

Mysql在大型网站的应用架构演变

写在最前: 本文主要描述在网站的不同的并发访问量级下,Mysql架构的演变 可扩展性 架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展...

1688
来自专栏数据库

分布式数据库数据一致性原理说明与实现

前言 分布式数据库的数据一致性管理是其最重要的内核技术之一,也是保证分布式数据库满足数据库最基本的ACID特性中的 “一致性”(Consistency)的保障。...

5039

扫码关注云+社区