欢迎来到啾啾的博客🐱，一个致力于构建完善的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的设计就写成一节了。
融合的、渐进的、权衡的设计。