上一篇：如何基于Nacos实现分布式配置中心？ | 带你读《Spring Cloud Alibaba（2019）》之七
下一篇：什么是微服务网关？ | 带你读《Spring Cloud Alibaba（2019）》之九
本文来自于《精通Spring Cloud Alibaba》课程的整理，讲师为余胜军，点击查看视频内容。
本文系志愿者整理，供配合学习中心课程使用，不做商业用途。
基于Nacos集群部署方案
Nacos 核心帮助我们做的事情注册中心、分布式配置中心
注册中心：没有必要将数据持久化到数据库中，可以持久化到本地的硬盘。
分布式配置中心： 默认是将数据持久化到本地嵌入式的数据库改为持久化到myql中
相关集群配置
创建cluster文件夹
---nacos-server-8848
---nacos-server-8849
---nacos-server-8850
cluster.conf
###ip和端口号
127.0.0.1:8848
127.0.0.1:8849
127.0.0.1:8850
Nginx相关配置
客户端连接
spring:
application:
###服务的名称
name: meitemayikt-nacos-client
cloud:
nacos:
discovery:
###nacos注册地址
server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850
enabled: true
config:
###配置中心连接地址
server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850
###分组
group: DEFAULT_GROUP
###类型
file-extension: yaml
注意：
1、Nacos在不同的版本下运行集群是不一样的。
nacos在windows版本下运行默认是单机版本 需要指定startup.cmd -m cluster
2、nacos在linux版本下运行默认是集群版本 如果想连接单机版本 startup.cmd –m standalone
注意事项：集群的ip地址不能采用127.0.0.1，我们需要修改为192.168.18.218。
分布式情况下 集群保证数据的一致性集群的算法
ZAB（Zookeeper）核心原理两阶段是提交协议2PC、Paxos、nacos数九一致性协议raft协议采用心跳形式
Nacos对比Zookeeper、Eureka之间的区别
Nacos与Eureka区别
最大区别：Nacos支持两种模式CP/Ap模式，从Nacos1.0版本开始，注意模式就是Ap模式
注册有哪些？
Eueeka、Nacos、consul、Zookepper
核心：
1、Eureka与Zookeeper实现注册的区别
2、Eureka与Nacos实现注册区别
CAP定律概念：
这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
一致性(C)：在分布式系统中，如果服务器集群，每个节点在同时刻访问必须要保持数据的一致性。
可用性(A)：集群节点中，部分节点出现故障后仍然可以使用 （高可用）
分区容错性(P)：在分布式系统中网络会存在脑裂的问题，部分Server与整个集群失去节点联系，无法组成一个群体。
取舍：只有在CP和AP选择一个平衡点
采用：
Cp情况下 虽然我们服务不能用，但是必须要保证数据的一致性
Ap情况下 可以短暂保证数据不一致性，但是最终可以一致性，不管怎么样，要能够保证我们的服务可用
大多的注册中心都是Ap
Nacos对比Zookeeper、Eureka之间的区别
从相同点、不同点、中心化思想三方面来
三者都可以实现分布式注册中心框架.
不同点：
Zookeeper采用CP保证数据的一致性的问题， 原理采用(ZAP原子广播协议) ， 当我们ZK领导者因为某种情况下部分节点出现了故障，会自动重新实现选举新的领导角色，整个选举的过程中为了保证数据一致性的问题， 客户端暂时无法使用我们的Zookeeper， 那么这意味着整个微服务无法实现通讯（本地有缓存除外）。
注意：可运行的节点必须满足过半机制，整个zk采用使用。
Eureka采用AP设计思想实现分布式注册中心， 完全去中心化、每个节点都是相等， 采用你中有我、我中有你相互注册设计思想，只要最后有一台Eureka节点存在整个微服务就可以实现通讯。
中心化：必须围绕一个领导角色作为核心，选举领导和跟随者角色。
去中心化：每个角色都是均等。
我们在使用注册中心，可用性优先级最高，可以读取数据短暂不一致性，但是至少要能够保证注册中心可用性。
Nacos从1.0版本选择Ap和CP混合形式实现注册中心， 默认情况下采用Ap， CP则采用Raft协议实现保持数据的一致性。
如果选择为Ap模式，注册服务的实例仅支持临时模式，在网络分区的的情况允许注册服务实例，选择CP模式可以支持注册服务的实例为持久模式，在网络分区的产生了抖动情况下不允许注册服务实例。
Nacos的版本更新：
https://github.com/alibaba/nacos/releases
Eureka与Nacos有哪些区别：
1、Eureka采用Ap模式实现注册中心
2、Nacos默认采用AP模式，在1.0版本之后采用ap+cp模式混合实现注册中心。
Eureka与Nacos底层实现集群协议哪些区别
1、去中心化对等。
2、Raft协议实现集群产生领导角色。
分布式系统一致性算法
Raft到底是什么问题即什么是分布式一致性协议的算法
分布式系统一致性算法：应用于系统软件实现集群保持每个节点数据的同步性
保持我们的集群中每个节点的数据的一致性的问题。
专业的术语：分布式一致性的算法。
场景：Redis集群、nacos集群、mongdb集群等
分布式事务一致性框架与分布式系统一致性算法有哪些？
分布式事务一致性框架：核心解决我们在实际系统中产生夸事物导致分布式事务问题。
核心靠的是最终一致性。rocketmq事务消息、rabbitmq补单、lcn、SeaTac等。
分布式系统一致性算法：解决我们系统之间集群之后每个节点保持数据的一致性
有哪些：raft（nacos）、zab（zookeeper）、paxos等。
Zab协议集群原理
我们在分布式系统，存在多个系统之间的集群保持数据一致性，采用CP一致性算法保持数据的一致性问题。
Zookeeper基于ZAP协议实现保持每个节点的数据同步的问题，中心化思想集群模式；
分为领导和跟随者角色。
在程序中如何成为某个节点能力比较强：
对每个节点配置一个myid或者serverid，数值越大表示能力越强；或者根据随机时间判断，随机时间越短，能力越强。
整个集群中为了保持数据的一致性的问题，必须满足大多数情况>n/2+1 可运行的节点环境下才可以使用
ZAP的协议实现原理事通过比较myid myid谁最大谁就是为可能是领导角色，只要满足过半的机制就可以成为领导角色，后来启动的节点不会参与选举的。
Zab协议如何保持数据的一致性问题
所有写的请求统一交给我们的领导角色实现，领导角色写完数据之后，领导角色再将 数据同步给每个节点。
注意：数据之间同步采用2pc两个阶段提交协议。
选举过程：
先去比较zxid，zxid谁最大谁就是为领导角色；
如果zxid相等的情况下，myid谁最大谁就为领导角色；
Ratf整个底层实现原理：
在Raft协议算法中分为角色|名词：
1、状态：分为三种，跟随者、竞选者（候选人）、领导角色。
跟随者：只有投票权限，不能参与竞选。
竞选者（候选人）：被投票，有可能成为领导者的角色。
领导角色：只有唯一的一个。
2、大多数： >n/2+1，n表示集群总数的节点。
3、任期：每次选举一个新的领导角色，任期都会增加。
注意：任何的算法都是来源于生活。
4、竞选者谁的票数最多，谁就成为领导角色。
存在的疑问：
多个竞选者，产生的票数都完全一样，这到底谁是领导角色？
注意当我们的集群节点总数，如果是奇数情况下，就算遇到了该问题也不用担心。
当我们的节点是偶数的情况下，可能会存在该问题，如果两个竞选者获取的票数相等的情况下，开始重置竞选的超时时间，一直到谁的票数最多谁就为领导。
默认情况下选举的过程：
1、默认的情况下每个节点都是跟随者角色
2、每个节点会随机生成一个选举的超时时间，例如大概是100-300ms，在这个超时时间范围内必须要等待。
3、超时时间过后，当前节点的状态由跟随者变为竞选者状态，会给其他的节点发出选举的投票通知，只要该竞选者有超过半数以上即可选为领导角色。
核心的设计原理：谁超时时间最短，谁就有非常大的概率为领导角色。
那么在随机数有可能一样的情况下，如何选举呢？
1、如果所有的节点的超时随机数都是一样的情况下，当前投票全部作废，重新进入随机生成超时时间。
2、如果有多个节点生成的随机数都是一样的情况下，比较谁的票数最多，谁就是领导。如果票数完全一样的情况，直接作废，重新进入随机生成超时时间。
注意：建议集群节点为奇数。偶数节点容易造成死循环。
故障重新实现选举：
1、如果我们跟随者节点不能够及时的收到领导角色消息，那么这时候跟随者就会将当前自己的状态由跟随者变为竞选者状态，会给其他的节点发出选举投票的通知，只要该竞选者有超过半数以上即可选举为领导角色。
数据是如何保持一致性的，类似于ZAP两阶段提交协议。
如何实现日志的复制
1、所有的写的请求都是统一的交给我们的领导角色完成，写入该对应的日志，标记该日志为被提交状态。
2、为了提交该日志，领导角色就会将该日志以心跳的形式发送给其他的跟随者节点，只要满足过半的跟随者节点写入该目志，则直接通知其他的跟随者节点同步该数据，这个过程称为日志复制的过程。
