微服务架构-SpringCloudAlibaba-096：Nacos集群部署实现原理&分布式一致性算法raft协议

1 Nacos集群的课程内容介绍

课程内容：

1. Nacos集群部署在不同环境需要注意哪些
2. Nacos与Eureka、Zookeeper的区别
3. 分布式系统中一致性协议有哪些
4. Nacos Raft一致性心跳的实现原理

2 部署伪集群Nacos模式

Nacos核心：注册中心、分布式配置中心
注册中心 没有必要将数据持久化到数据库中，可以持久化到本地的硬盘。
分布式配置中心 默认是将数据持久化到本地嵌入式的数据库，最好改为持久化到mysql。

伪集群：
127.0.0.1:8848
127.0.0.1:8849
127.0.0.1:8850

注意事项：Nacos在不同的版本下运行集群是不一样：

1. nacos在windows版本下运行默认是单机版本，如果想集群启动需要指定startup.cmd -m cluster；
2. nacos在linux版本下运行默认是集群版本，如果想连接单机版本startup.cmd –m standalone；

注意事项：集群的ip地址不能采用127.0.0.1，修改为本机ip
192.168.149.1:8848
192.168.149.1:8849
192.168.149.1:8850

集群效果：

3 注册中心设计Ap与CP区别

Nacos与Eureka区别：
最大区别：Nacos支持两种模式CP/AP模式 从Nacos1.0版本开始，模式就是AP模式

CAP定律
在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

在分布式系统中，如果服务器是集群的情况下，
一致性©：每个节点同一时刻查询的数据必须保持一致性；
可用性(A)：集群节点中，部分的节点出现了故障仍然可以继续使用；
分区容错性§：在分布式系统中网络存在脑裂的问题，部分的Server与整个集群失去联系无法形成一个群体。
CAP三者无法兼顾，只有在CP和AP之间选择一个平衡点。

采用CP：虽然服务不能用，但是必须要保证数据一致性；
采用AP：可以短暂保证数据不一致性，但是最终可以一致，不管怎么样，要保证服务能够可用；
大多数注册中心都是AP模式。

4 Eureka与Zookeeper的区别

Eureka与Zookeeper实现注册中心的区别？
Zookeeper采用CP保证数据的一致性问题，原理采用ZAB原子广播协议（核心原理两阶段提交协议2PC）。当zk领导因为某种原因宕机的情况下，会自动触发重新选一个新的领导角色，整个选举的过程为了保证数据一致性的问题，在选举的过程中整个zk环境是不可使用的，客户端短暂可能无法使用到zk，意味着微服务采用该模式可能无法实现通讯。（本地有缓存除外）
注意：可运行的节点必须满足过半机制，整个zk环境才可以使用。

Eureka采用AP的设计理念架构注册中心，完全去中心化思想，也就是说没有主从概念。每个节点都是均等的，采用相互注册原理，你中有我我中有你，只要最后有一个Eureka节点存在就可以保证整个微服务可以实现通讯。

一般使用注册中心，可用性优先，可以读取数据短暂不一致，但是至少要保证注册中心可用。
中心化：必须围绕一个领导角色作为核心，选举出领导和跟随者角色；
去中心化：每个角色都是均等。

5 Nacos与Eureka的区别

Eureka与Nacos实现注册中心的区别？
Nacos从1.0版本支持CP和AP混合模式（可以手动切换模式）集群，默认采用AP保证服务可用性，CP的形式底层集群通过raft协议保证数据的一致性问题。
如果采用AP模式注册服务的实例仅支持临时注册形式，在网络分区产生抖动的情况下，仍然还可以继续注册服务列表
选择CP模式必须保证数据的强一致性问题，如果网络分区产生抖动的情况下，是无法注册服务列表。选择CP模式可以支持注册实例持久化。

什么情况下选择CP或AP模式？
必须要求读取接口的地址保证强一致性的问题，可以采用CP模式；一般情况都是采用AP模式。

如何实现切换模式？
$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP
必须是发送put请求（集群模式每个节点都要发送）

Eureka与Nacos有哪些区别
Eureka采用AP模式形式实现注册中心；
Nacos默认采用AP模式，在1.0版本之后采用AP+CP模式混合实现注册中心。
Eureka与Nacos底层实现集群协议哪些区别
Eureka去中心化，角色对等。
Nacos采用Raft协议实现集群，产生领导角色。

Raft协议属于分布式一致性协议的算法
什么是分布式系统一致性算法？
应用于系统软件实现集群，保持每个节点数据同步性，保证数据一致性问题。
场景：Redis集群、Nacos集群、MongoDB集群

分布式事务一致性框架与分布式系统一致性算法有哪些区别？
分布式事务一致性框架：解决在实际系统中产生的跨事务导致分布式事务问题，核心靠的就是最终一致性；rocketmq事务消息、rabbitmq补单、lcn、seata等。
分布式系统一致性算法：解决系统集群之后每个节点保持数据一致性的问题。
主要算法：raft（nacos）、zab（Zookeeper）、paxos等。

6 简单回顾Zab协议集群模式原理

Zookeeper基于ZAB协议实现保证每个节点之间数据同步的问题，中心化思想集群模式，分为领导者和跟随者角色。
在程序中如何认为某个节点能力比较强？
对每个节点配置一个myid或者serverid，数值越大表示能力越强，或者随机时间

整个集群中为了保持数据的一致性问题，必须满足过半机制，可运行节点数>n/2+1，整个zk环境才可以使用。
ZAB协议实现原理是通过比较myid，myid谁最大谁就可能是领导角色，只要满足过半机制就可以成为领导角色，后来启动的节点不会参与选举。

ZAB协议如何保证数据的一致性的问题
所有写的请求统一交给领导角色实现，领导角色写完数据之后再将数据同步给每个节点。
注意：数据之间同步采用2pc两阶段提交协议。

每个写的请求产生一个zxid，数据同步过程中leader节点发两次通知，第一次通知带上zxid给每个follower节点是否可以接收数据，只要满足过半的节点响应可以接收zxid=100的数据，leader节点就把zxid=100的数据同步给follower节点（第二次通知）。

Leader宕机新leader选举过程：
先去比较zxid，zxid 谁最大谁就是为领导角色（表示该节点数据最新）；
如果zxid相等的情况下，myid谁最大谁就为领导角色；

7 Raft协议选举基本的概念

Raft协议算法中角色|名词：

1. 状态：跟随者、竞选者（候选人）、领导角色
2. 大多数： >=n/2+1（n为集群节点总数） 3/2=1+1=2
3. 任期：每次选举一个新的领导角色，任期都会实现增加
   注意：任何算法都是来源于生活。
4. 竞选者谁的票数最多，谁就是为领导角色。

存在的疑问：
服务器集群是偶数的情况下，多个竞选者，产生的票数都完全一样，谁为领导角色？

8 Raft协议选举底层实现原理

选举的过程是怎么样的？

1. 默认的情况下每个节点都是为跟随者；
2. 每个节点会随机生成一个选举的超时时间，例如大概是100-300ms，在这个超时的时间范围内必须要等待；
3. 超时时间过后，当前节点的状态可能由跟随者变为竞选者状态，会给其他的节点发出选举的投票通知，只要该竞选者有超过半数以上即可选为领导角色。
   核心设计的原理：谁超时时间最短谁最大概率为领导角色。

Raft生成的随机数一样的情况下如何处理？

1. 如果所有节点的超时时间随机数都是一样的情况下，当前投票全部作废，重新随机生成超时时间。
2. 如果有多个节点生成的随机都是一样的情况下，比较谁的票数最多，谁就是为领导。3. 如果票数完全一样的情况，直接作废，重新进入随机生成超时时间。
   建议集群节点为奇数。

Raft协议故障恢复实现重新选举
如果跟随者节点不能及时收到领导角色的消息的话，那么这时候跟随者状态就会变为竞选者状态，会给其他的节点发出选举投票通知，只要该竞选者有超过半数以上投票即可选举为领导角色。

9 Raft采用日志复制形式同步数据

数据是如何保持一致性的？类似zab两阶段提交协议

1. 所有写的请求都是统一交给领导角色完成，会写入该对应的日志，标记该状态是未提交状态；
2. 为了提交该日志，领导角色就会将该日志以心跳的形式发送其他的跟随者，只要满足过半的跟随者可以写入该数据，则直接通知其他节点同步该数据，这个过程称为日志复制。