网站做了泛解析 为什么影响seo,黄页网站建设,如何制作漂亮的微信公众号,广东深圳最近出什么事了#x1f44f;作者简介#xff1a;大家好#xff0c;我是爱敲代码的小黄#xff0c;阿里淘天Java开发工程师#xff0c;CSDN博客专家#x1f4d5;系列专栏#xff1a;Spring源码、Netty源码、Kafka源码、JUC源码、dubbo源码系列#x1f525;如果感觉博主的文章还不错的话… 作者简介大家好我是爱敲代码的小黄阿里淘天Java开发工程师CSDN博客专家系列专栏Spring源码、Netty源码、Kafka源码、JUC源码、dubbo源码系列如果感觉博主的文章还不错的话请三连支持一下博主哦博主正在努力完成2023计划中以梦为马扬帆起航2023追梦人联系方式smallyellow521加我进群大家一起学习一起进步一起对抗互联网寒冬 文章目录 复制领导者与追随者同步复制与异步复制如何设置新从库处理节点宕机从库失效追赶恢复主库失效故障切换 复制日志的实现基于语句的复制逻辑日志复制(基于行)基于触发器的复制 复制延迟问题读已之写单调读一致前缀读多主复制运维多个数据中心需要离线操作的客户端协同编辑 处理写入冲突同步与异步冲突检测避免冲突收敛至一致的状态 多主复制拓扑 无主复制节点故障读修复和反熵 总结 与可能出错的东西比“不可能”出错的东西最显著的特点就是一旦真的出错通常就彻底玩完了。 —— 道格拉斯・亚当斯1992 复制
简介通过网络连接的多台机器上保留相同数据的副本。
原因降低延时、可用性、吞吐量
数据存放地与用户接近减少网络请求延时避免单机故障提升可用性机器数量可伸缩提升读取吞吐量
困难
如果复制的数据不随时间而改变复制将变的非常简单但复制的过程中数据经常是变更的
解决
在分布式场景下一般使用三种变更复制算法
单领导者多领导者无领导者
领导者与追随者
副本存储数据库拷贝的每个节点
问题当存在多个副本时如何确保所有数据都落在了所有的副本上
解决方案基于领导者的复制
原理 我们将其中一个副本指定为 领导者(主库) 当客户端想要写入数据时必须将请求发送给领导者(主库)它将数据写入到本地存储 其他副本成为追随者只读副本 每当领导者将新数据写入本地存储时它也会将数据变更发送给所有的追随者称为复制日志。每个追随者从领导者拉取日志并更新本地数据库副本按照领导者相同的处理顺序来进行写入 当客户想要从数据库查询数据 领导者和任一追随者都可以查询只有领导者可以写入数据
同步复制与异步复制 Follower 1同步复制 好处保持与主库强一致的最新数据坏处从库挂掉主库也无法写入数据 Follower 2异步复制 好处从库挂掉主库也能写入数据坏处无法保持与主库强一致的最新数据
目前业界常用方式半同步
在数据库中开启同步复制其中一个从库是同步的其余所有的从库均是异步的如果该从库不可用则将另外一个异步从库改为同步复制
通常情况下基于领导者的复制都配置成完全异步一旦主库失效不可恢复复制给从库的数据也将丢失。
即使已经向客户端确定成功写入也不能保证是持久的。
当然也有优点即使所有的从库都落后了主库也可以正常写入。
如何设置新从库
原因
增加从库副本数量替换失败的节点
过程
在某个时刻获取主库的一致性快照将快照复制到新的从库节点从库链接主库并拉取快照后的所有数据变更等从库处理完快照之后的数据变更从库就赶上了主库
复制过程可参考Redis 和 MySQL
处理节点宕机
系统中的任何节点都可能宕机即使个别节点生效也能保持整个系统的运行并尽可能控制节点停机带来的影响
从库失效追赶恢复
在本地磁盘中从库记录从主库收到的数据变更。
如果从库崩溃并重新启动或者网络中断等原因从本地日志中获取最后一个事务
连接到主库请求在从库断开期间发生的所有数据变更当解决完这些变更之后就赶上了主库正常接受数据变更流。
主库失效故障切换
故障切换将其中一个从库提升为新的主库重新配置客户端将他们的写操作发送给新的主库其他从库需要开始拉取来自新主库的数据变更。
过程
确定主库失效心跳检测选择一个新的主库选举机制重新配置系统以启动新的主库
问题 异步复制新主库的数据落后老主库。解决方式丢掉老主库中未复制的写入 数据库与外部存储协调丢弃写入内容极其危险 例如在 GitHub 的一场事故中一个过时的 MySQL 从库被提升为主库 数据库使用自增 ID 作为主键因为新主库的计数器落后于老主库的计数器所以新主库重新分配了一些已经被老主库分配掉的 ID 作为主键 这些主键也在 Redis 中使用主键重用使得 MySQL 和 Redis 中的数据产生不一致最后导致一些私有数据泄漏到错误的用户手中。 脑裂两个节点都误认为自己是主库 超时时间的配置如何正确的配置主库失效的超时时间
复制日志的实现
基于语句的复制
主库记录每个写入请求并将该语句发送给从库
问题
任何调用 非确定下函数 的语句在每个副本生成不同的值。 NOW()获取当前时间RAND()获取一个随机数 语句必须按照顺序执行避免并发问题 UPDATE … WHERE 某些条件必须现有某些条件数据再进行 UPDATE
### 传输预写式日志(WAL)
存储引擎通常会将写操作追加到日志中 mysql 通过 redo、undo 日志实现 WAL。 redo log 称为重做日志每当有操作时在数据变更之前将操作写入 redo log这样当发生掉电之类的情况时系统可以在重启后继续操作。 undo log 称为撤销日志当一些变更执行到一半无法完成时可以根据撤销日志恢复到变更之间的状态。 mysql 中用 redo log 来在系统 Crash 重启之类的情况时修复数据事务的持久性而 undo log 来保证事务的原子性。 缺点由于日志记录的非常底层WAL包含哪些磁盘块中的哪些字节发生了变化当从库和主库运行不同版本时会出现数据解析问题。
逻辑日志复制(基于行)
复制和存储引擎使用不同的日志格式将复制日志从存储引擎的内部实现中解耦出来这种复制日志被称为逻辑日志。
例如MySQL 的 Binlog
插入行日志包含所有列的新值删除行日志包含主键更新行日志包含主键及更新列的新值
优点逻辑日志和存储引擎内部实现解耦系统可以做到兼容。从而使主库和从库可以运行不同版本的数据库软件。
基于触发器的复制
将数据更改发生时的自定义代码记录在数据库系统中使用外部程序读取该表进行响应的复制。
复制延迟问题
当前存在一个主库多个从库在数据复制的过程中如果从库落后于主库我们会看到过时的信息。
对主库和从库执行相同的查询得到不同的结果等后续一段时间后从库追上主库保持一致被称为 最终一致性。
读已之写 用户在界面提交一些数据将其写入到主库主库异步复制给从库从而从库追赶上主库。
但如果用户在提交完数据后立即查询从库会发现自己提交的数据库丢失不见
这种情况下我们需要 写后读一致性也称为 读己之写一致性我们需要保证如果用户重新加载页面他们总会看到他们自己提交的任何更新
解决方法
对于用户可能修改的内容总是从主库获取 用户个人资料只能本人编辑而不能其他人编辑从主库读取自己的档案其他用户档案去从库读取 跟踪上次更新的时间在数据更新的一分钟内从主库读取监控从库的复制延迟滞后主库超过一分钟的从库不接受查询请求
单调读 当前从库 2 落后从库 1如果用户从不同从库读取
先读取的从库 1拿到了最新数据后续读取从库 2拿到了旧数据
从用户体验来看时间看上去好像回退了所以我们需要单调的读取。
单调读 可以保证这种异常不会发生其程度比 强一致性 弱比 最终一致性 更强。
实现方式每个用户总是从一个副本中进行读取不同客户可以从不同副本读取。可以基于用户 ID Hash 来选择副本而不是随机选择读取的数据库副本。
一致前缀读
如果我们有两个因果关系的数据 Mr. Poons Mrs. Cake你能看到多远的未来 Mrs. Cake 通常约十秒钟Mr. Poons. 假如
Cake 说的话是一个延迟较低的从库Poons 说的话是一个延迟较高的从库
当第三个人在读取数据时会出现这种情况 Mrs. Cake 通常约十秒钟Mr. Poons. Mr. Poons Mrs. Cake你能看到多远的未来 如果某些分区的复制速度慢于其他分区那么观察者可能会在看到问题之前先看到答案。
需要保证一致前缀读如果一系列写入按照某个顺序进行那么任何人读取这些写入时也看以同样的顺序读取。
解决方案确保任何因果相关的写入都写入到相同的分区
多主复制
如果数据库被分区每个分区有一个主库。
多领导配置处理写入的每个节点都必须将该数据变更转发给其他节点
在这种情况下每个主库同时是其他主库的从库。
### 多主复制的应用场景
运维多个数据中心 多主配置中在每个数据中心都有主库每个数据中心内使用常规的主从复制
在数据中心之间每个数据中心的主库会将自身变更同步到其他主库。
单主和多主对比
性能 单主每个写入操作必须穿过互联网进入主库所在的数据中心网络延时较大多主每个写入操作在本地数据中心进行处理与其他数据中心异步复制网络延时较小 容忍数据中心停机 单主主库所在的数据中心发生故障切换另一从库成为主库多主数据中心可以独立于其他数据中心继续运行
多主复制的缺点多主复制在数据库属于改装的功能常常存在微妙的配置缺陷。因此多主复制被认为是危险的领域应尽可能避免。
需要离线操作的客户端
多主复制的另一种适用场景是应用程序在断网之后仍然需要继续工作。比如日历应用
在这种情况下每个设备都有一个充当主库的本地数据库在所有的设备的日志副本之间同步。
协同编辑
实时协作编辑应用程序允许多个人同时编辑文档
当一个用户编辑文档时所做的更改将立即应用到其本地副本并异步复制到服务器。
如果不发生编辑冲突则应用程序必须对文档加锁为了加速协作尽可能将加锁的单位设置的非常小。
处理写入冲突
多主复制最大的问题写入冲突 假如两个人同时更改一个页面
用户 1 将页面标题从 A 更改为 B用户 2 将页面标题从 A 更改为 C
当异步复制时就会出现冲突。
同步与异步冲突检测
如果在单主数据库中两个操作是串行的不会发生冲突
但多主数据库中两个分别写入不同的主库后续异步复制必然出现冲突问题
避免冲突
处理冲突的最简单的策略就是避免它们如果应用程序可以确保特定记录的所有写入都通过同一个主库那么冲突就不会发生。
例如一个用户编辑自己数据的应用程序确保来自特定用户的请求始终路由到同一数据中心并使用该数据中心的主库进行读写。
收敛至一致的状态
我们上述的例子中在多个主库的情况下我们的写入顺序是不确定的
数据库必须以一种收敛的方式解决冲突所有副本必须在变更复制完成时收敛到一个相同的最终值。
解决方案
给每个写入分配唯一ID时间戳、长随机数、UUID挑选最高 ID 的写入作为胜利者给每个副本分配唯一IDID更高的写入具有更高的优先级将这些值链接在一起比如B/C将冲突显式的暴露出来交于用户决定比如GIT冲突
多主复制拓扑
复制拓扑用来描述写入操作从一个节点传播到另一个节点的通信路径。 无主复制
客户端直接写入几个副本中另一种情况由一个 协调者 代表客户端写入。
节点故障
无主配置中发生节点故障不需要故障转移
如果有三个副本两个副本写入成功一个副本写入失败 当我们不可用的副本重新上线存的是落后的数据
解决方案当一个客户端从数据库中读取数据时它不仅仅把它的请求发送到一个副本而是将读请求将被并行地发送到多个节点通过版本号来确定哪个值是最近更新的。
读修复和反熵
复制方案应确保最终将所有数据复制到每个副本。在一个不可用的节点重新联机之后它如何赶上它错过的写入
读修复当客户端并行读取多个节点时检测落后节点的回应并将最新值写会落后节点。适用于频繁读取的值反熵过程数据存储具有后台进程进程不断查找副本之间的数据差并进行相关的复制追齐。
总结
鲁迅先生曾说独行难众行易和志同道合的人一起进步。彼此毫无保留的分享经验才是对抗互联网寒冬的最佳选择。
其实很多时候并不是我们不够努力很可能就是自己努力的方向不对如果有一个人能稍微指点你一下你真的可能会少走几年弯路。
如果你也对 后端架构 和 中间件源码 有兴趣欢迎添加博主微信smallyellow521一起学习一起成长
我是爱敲代码的小黄阿里巴巴淘天集团Java开发工程师双非二本培训班出身
通过两年努力成功拿下阿里、百度、美团、滴滴等大厂想通过自己的事迹告诉大家努力是会有收获的
双非本两年经验我是如何拿下阿里、百度、美团、滴滴、快手、拼多多等大厂offer的
我们下期再见。 从清晨走过也拥抱夜晚的星辰人生没有捷径你我皆平凡你好陌生人一起共勉。
