【微服务架构】 CAP理论和BASE理论，附带nacos，zookeeper，eureka的区别

【微服务架构】 CAP理论和BASE理论，以及nacos，zookeeper，eureka的区别

---

CAP理论

cap理论，在一个分布式架构系统中，有三要素，一致性（Consistency），可用性（Availability），分区容错性（Partition tolerance），但是这三要素不能同时满足，具体如下：

一致性（Consistency）：

一致性要求各个节点的数据都保持一致，如果某个节点出现了分区，
如果不能及时的同步其他节点的数据，那么这个节点就违反了一致性，
要么这个节点停掉，要么整个系统停止调，
如果需要保证系统的一致性，那么就需要牺牲掉违反一致性的节点，就不满足了可用性。
（网络分区释义：在分布式环境下，节点和节点之间进行网络通信，可能会出现网络故障，而非服务故障，导致认为某些节点不可用，数据无法同步过去，就造成了整个系统出现了数据不一致问题）
比如zookeeper，如果出现了网络分区的情况，那么此节点将变得不可用，如果是leader节点，那么会进行重新选举新的leader节点

可用性（Availability）：

可用性要求所有节点尽量可用。当发生网络分区问题是，出现了节点与节点之间通信故障问题，导致多个节点数据无法保持一致性的情况。也仍然让该节点保持可以用，不会像zk一样直接停掉通讯鼓掌的节点，牺牲掉一定的数据一致性，因为这个时候从不同节点读取到的数据就是不同的了。eureka，nacos都支持AP架构，不过一般来说会通过心跳机制来保证数据的最终一致性。
心跳机制主要是一种检测节点是否健康的一个机制，各个节点以固定频率给其他节点发送一些元数据信息，状态等，如果另外的节点正常响应，那么就表示这个节点和他的通信状态是健康的，但是心跳检测失败不一定就是节点挂掉了，可能是网络故障，延迟，带宽被打满等其他情况

分区容错性（Parition tolerance）：

分区容错性，当出现网络分区的情况时，不能就让程序变得不可用了，还是需要保持程序可用的状态，在分布式架构中，分区容错性是必须要满足的，所以一般只存在两种架构，CP（zookeeper集群），AP（eureka集群，nacos集群，redis集群）

---

BASE理论

• BA： 基本可用（Basically Available）
• S: 软状态（Soft State）
• E: 最终一致性(Eventual Consistency)

基本可用（Basically Available）

只要节点不给挂完，就属于基本可用的情况。

软状态（Soft State）

对于没有同步过去保持一致性的数据处于软状态

最终一致性(Eventual Consistency)

如果节点恢复了，通过心跳机制再达到数据一致性，期间没有一致，但是最终一致了，属于最终一致性。

---

AP架构 和 CP架构写数据

AP架构

• 不同节点可以向任意节点写入数据，数据写入成功后，立刻给客户端响应写成功的信号
• 当出现网络分区故障时，导致节点之间通讯故障，B节点无法给A节点写入数据，这个时候客户端访问A节点的时候，就会出现和B节点数据不一致的情况,当网络故障恢复后,才会通过心跳机制保证最终一致性

CP架构

• 所有节点写数据只能向leader节点写入数据，获取数据可以从任意节点获取数据，然后leader节点再通过心跳机制向各个子节点同步数据
• 在给leader节点写入数据成功后，不是立马给客户端返回成功的信号，而是需要leader将数据同步给其他节点之后（数量默认是超过总节点一半），才会响应给客户端

---

脑裂问题

脑裂

集群的脑裂通常是发生在出现网络分区故障的时候，一个大集群会分裂成多个小集群，小集群中自己选举出了自己的master节点，导致原先的集群会出现多个master节点对外单独提供服务的情况

如何避免脑裂

leader选举时，要求获取到总投票数的1/2以上的，有了这个选举机制，当发生网络分区故障时，最多只有一个小集群选出leader，因为每个节点投票只有一张，只会有一个超过1/2被投票的节点，所以只会被选举出一个leader节点。

ps：文章内容性质属于笔记，由本人查看网上资料或实践后的个人理解，不保证准确性，仅供参考，如有意见，欢迎讨论指正。