手机网站微信分享代码,辽宁省城乡和住房建设厅网站,黔东南网页设计,下载中国建设银行官网站基本概念
数据的复制指的是通过网络链接的多台机器保留相同的副本
为什么要进行数据的复制 使得用户和数据在地理上比较接近#xff0c;因为大数据要求我们将计算安排在数据存放的位置和我们基本的内存模型不是很一样 #xff0c;比如磁盘调入内存之类的。即使系统的一部分…基本概念
数据的复制指的是通过网络链接的多台机器保留相同的副本
为什么要进行数据的复制 使得用户和数据在地理上比较接近因为大数据要求我们将计算安排在数据存放的位置和我们基本的内存模型不是很一样 比如磁盘调入内存之类的。即使系统的一部分机器出现了故障系统也能正常工作这个指的是如果一个节点出现宕机应该怎么处理才能使系统正常工作。扩展可以接收读请求机器的数量如果有很多个机器进行读如果只有一个副本的话那么系统就会发生崩溃有点类似于DNS泛洪攻击的原理。
领导者和追随者的复制
我们这里假设的情景是基于领导者的复制或者是说主从库的复制。
副本的概念 当有多个副本的时候我们会思考几个问题当存储多个副本的时候如何确保所有的数据落到所有的副本上就类似于通知从教学秘书下放到计算学部大群 我们到底是采用让所有的同学向教学秘书确认他收到消息了才算下放完成还是说让辅导员老师通知班长下放消息 然后反馈给教学秘书我已经全通知完了。同步和异步的优劣 同步的好处是可靠性很高 但是缺点是消耗资源异步的优点 我们发现follower1的复制是同步的 但是2的复制是异步的半同步 实际上 数据库大多是采用半同步复制的策略也就是上面的图展示的样子指定一个主库并且从中指定一个从库使得主库和从库的复制是同步的主库和其他从库的复制是异步的。这样的好处是如果一个主库发生的宕机那么我们指定好了一个新的主库之后就把这个同步的从库的内容直接复制过去就行了。半同步背景下节点的加入节点的宕机复制日志的实现细节 我们采用比较多的是半同步复制那么我们不妨看下底层的具体是如何实现的
由于大数据具有实时性的特点任何时候都可能发生数据的更新所以我们从库拉取的数据也未必是最新的数据我们的数据库需要进行如下处理首先拉取主库的一致性快照快照复制到新的从库节点然后将这些快照复制到新的从库节点之后从库连接主库并拉取复制快照之后的所有变更这样新的节点就赶上主库了。
系统中任何的节点都可能宕机包括主库 从库1 从库n也就是大老板 小老板 打工人都有可能出现故障如果是从库发生故障 那么解决的方法非常简单就是和新加入的节点的方法类似首先修好之后从库连接主库并拉取宕机之后的日志完成追赶。。主库发生故障这个问题是非常棘手的首先我们需要考虑选谁充当主库这个可以通过选举产生也就是统计相同副本数量的个数来选举其次有可能出现两个或者多个从库同时充当主库的情况类似于汉高祖失去权力之后 各路诸侯纷争这个时候就会出现一个脑裂的情况解决方法很粗暴如果两个的话随机关闭一个。还有一个问题就是可能会存在冲突的写入老领导回来之后可能会产生冲突的写入避免冲突写入的方法就是忽略老节点的写入但是这样会破坏数据的持久性写入的原则。
日志的复制 基于语句的复制主库想要写入什么内容比如情景是关系数据库update或者是delete之类的语句但是这样可能会产生一想不到的后果比如我让你们寝室的人都去老师那签到本来老师以为是239的人是小明和小方但是这两个人串寝室了所有结果是小红和小绿去老师那报道了所以除非有特别确定的结果基于语句的复制是不好的。传输预写日志:缺点是需要和存储引擎打交道时间开销比较大。逻辑日志的复制基于行的复制有利于向后兼容不同的数据库存储软件。基于触发器的复制
复制的延迟
复制的另外一个原因是适用于读多写少的情景我们回顾一下 数据库更新的过程如果一个客户想要往数据库写数据首先发送请求给领导者领导者收到数据之后写入其本地的存储从库也被称作是只读副本他不会直接读取数据领导者将新的数据变更发送给所有的追随者也就是复制日志记录每个追随者拉取日志更新更新本地的数据库副本那么就回到了我们数据复制的第三点原因扩展可读机器的数量。 最终一致性在不发生错误的情况下 主库和从库数据保持一致性的状态叫做最终一致性。读己之写我们写入数据库之后想要快速的看到自己的更新一种方法是直接看自己从主库看别人从其他的库读第二种方法是检测状态。
多主复制
数据中心内部采用主从复制的原则数据中心之间采用多主复制的原则
对比内容单主复制多主复制出现故障时故障切换让数据中心的一个追随者成为领导者每个数据中心可以独立于其他数据中心运行并且发生故障时的数据中心归队时复制会自动赶上容忍网络敏感因为写操作是同步的临时的网络中断不影响写入应用场景离线的客户端
并发控制当多个人写入的时候可能存在冲突解决的方法是加锁 或者是根据时间戳设置ID 或者是在读取的时候设置限制。
