[分布式系统]2_分布式数据共享方式_P1

欢迎来到啾啾的博客🐱,一个致力于构建完善的Java程序员知识体系的博客📚,记录学习的点滴,分享工作的思考、实用的技巧,偶尔分享一些杂谈💬。

欢迎评论交流,感谢您的阅读😄。

引言

在微服务架构中,服务和组件往往以集群形式存在。

一份数据,如注册表信息,其存在于注册中心集群的多个注册中心服务上。然而,微服务架构的网络往往是不可靠的,我们如何在不可靠的网络条件下,正确地同步可能实时动态变更的注册表信息呢?

即"分布式环境下如何保证数据同步的可靠",也即集群数据的一致性。

一、分布式数据共享方式

1.状态转移

这里书中将数据的同步操作称呼为"状态转移",下面直接更直接的数据同步来描述。

数据同步+事务控制。

把"数据同步"操作当做事务来处理,当需要同步数据的集群中的每一个服务都反馈同步成功后才提交事务,否则回滚。

这样的设计方案有2PC与3PC。

还有MySQL的主从全同步复制,会等待所有Slave节点(从节点)的Binlog都写入后,才会提交Master节点的事务。

这样的设计有一个很明显的问题,任意一个Slave或者说协作者出现问题,整个数据同步操作都需要回滚,Slave节点越多,整体的数据同步越不可用。

即,采用"数据同步+事务控制"的设计方法,集群服务越多,可用性越低。

2.操作转移

我们想要保证数据同步的可用性,除了直接同步复制数据外,还有一种常用的方法是"通过某种操作,让源数据变成目标数据"。

在书中,这样的操作也被称作"操作转移(Opreation Transfer)"。能够使用确定的操作促使状态间产生确定的转移结果的计算模型,成为"状态机(State Machine)"。

即,基于"操作转移"概念,多个服务的初始状态一致,接受的操作指令序列也是一致,那么操作指令执行完成后的最终状态也是一致的。

"同步"操作指令的过程为"广播指令",不同服务执行指令期间,允许系统内部状态不一致,只需要保证最终一致,这种模型为成为"状态复制机(State Machine Replication)"

3.少数服从多数

在分布式中,还有一种原则是"少数服从多数",即多数节点同步完成,或者是操作转移了,那么剩下的节点可以忽略,这样可以减弱集群扩大带来的可用性下降,这种思想原则也被成为"Quorum机制"。

ZooKeeper集群就是这样的做法,使用Zab协议,基于Quorum机制,超过半数节点写操作成功就算成功。

少数未响应的节点,后续还是会收到"广播指令"
ZK官网文档

其实这一段应该不能算作一节,但是觉得这一个原则能体现分布式架构的设计最终还是权衡CAP的设计就写成一节了。

融合的、渐进的、权衡的设计。

相关推荐
快来卷java3 小时前
深入剖析雪花算法:分布式ID生成的核心方案
java·数据库·redis·分布式·算法·缓存·dreamweaver
2401_871290584 小时前
Hadoop 集群的常用命令
大数据·hadoop·分布式
冰 河4 小时前
《Mycat核心技术》第21章:高可用负载均衡集群的实现(HAProxy + Keepalived + Mycat)
分布式·微服务·程序员·分布式数据库·mycat
小样vvv5 小时前
【分布式】深入剖析 Sentinel 限流:原理、实现
分布式·c#·sentinel
千航@abc6 小时前
zookeeper的作用介绍
分布式·zookeeper·云原生·云原生组件
得物技术9 小时前
分布式数据一致性场景与方案处理分析|得物技术
分布式
潘多编程20 小时前
SpringBoot分布式项目订单管理实战:Mybatis最佳实践全解
spring boot·分布式·mybatis
星光璀璨山河无恙1 天前
【Hadoop】Hadoop3.1.4完全分布式集群搭建
大数据·hadoop·分布式
失业写写八股文1 天前
本地事务 vs 分布式事务:核心区别与解释
分布式·后端