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

欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧，偶尔也分享一些杂谈💬。
欢迎评论交流，感谢您的阅读😄。

引言

在微服务架构中，服务和组件往往以集群形式存在。
一份数据，如注册表信息，会存在于注册中心集群的多个注册中心服务上。
然而，微服务架构的网络往往是不可靠的，在这种不可靠的网络条件下，我们如何保障我们的注册信息是安全可靠、具备抗风险能力呢？又如何正确地同步可能实时动态变更的注册表信息呢？
即，多个节点数据怎么可靠存储？存储的数据变动后如何保证可用？

一、分布式数据共享方式

1.状态转移（State Transfer）

以“数据同步”为代表的数据复制方法，被称为状态转移（State Transfer）。
比如持久化方式中的”快照“（Snapshotting）。MySQL的mysqldump导出主集群的全量数据。Redis从节点首次连接主节点时同步RDB快照文件。

这种同步操作往往伴随着"事务控制"。当需要同步数据的集群中的每一个服务都反馈同步成功后才提交事务，否则回滚。
比如数据同步的2PC与3PC方案。

2.操作转移（Opreation Transfer）

我们想要保证数据同步的可用性，除了直接同步复制数据外，还有一种常用的方法是“通过某种操作，让源数据变成目标数据”。
这样的操作也被称作”操作转移（Opreation Transfer）“。而能够使用确定的操作促使状态间产生确定的转移结果的计算模型，则被称为“状态机（State Machine）”。

基于“操作转移”概念，多个服务的初始状态一致，接受的操作指令序列也是一致，那么操作指令执行完成后的最终状态也是一致的。
“同步”操作指令的过程为“广播指令”，不同服务执行指令期间，允许系统内部状态不一致，只需要保证最终一致，这种模型为成为“状态复制机（State Machine Replication）”

持久化方式中”日志“操作就属于操作转移。比如MySQL的binlog主从复制，通过重放binlog实现主从同步；Redis的AOF日志文件，主节点通过AOF记录的命令同步到从节点（操作转移）。

3.少数服从多数

在分布式中，还有一种原则是“少数服从多数”，即多数节点同步完成，或者是操作转移了，那么剩下的节点可以忽略，这样可以减弱集群扩大带来的可用性下降，这种思想原则也被成为“Quorum机制”。
ZooKeeper集群就是这样的做法，使用Zab协议，基于Quorum机制，超过半数节点写操作成功就算成功。
少数未响应的节点，后续还是会收到“广播指令”
ZK官网文档

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