SpringCloudAlibaba基础分享（五）

最了
121 阅读6分钟

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第13天，点击查看活动详情

image.png

nacos：

注册中心 没必要将数据持久化到数据库中，可以持久化到硬盘

分布式注册中心  默认是将数据持久化到本地嵌入式的数据库。0.7版本支持持久化到mysql中

注意事项：

nacos在不同的版本运行集群是不一样的

  1. nacos在windows版本下运行默认是单机版本 需要指定startup.cmd -m cluster

  2. nacos在linux版本下运行默认是集群版本 如果想连接单机版本 startup.cmd –m  standalone

集群ip地址不能使用127.0.0.1

nacos与eureka的区别？

最大区别：nacos支持两种模式CP/AP模式，从nacos1.0版本开始，支持AP和CP混合模式集群（可以自己调接口切换），默认AP

CP情况下：虽然服务不能用，但是必须保持数据的一致性。

AP情况下：可以短暂保持数据不一致性，但最终可以一致性，必须要保证服务可用。

eureka与nacos实注册的区别？

Eureka采用AP设计思想实现分布式注册中心，完全去中心化、每个节点都是相等，采用你中有我、我中有你相互注册设计思想， 只要最后有一台Eureka节点存在整个微服务就可以实现通讯。

Nacos从1.0版本选择Ap和CP混合形式实现注册中心，默认情况下采用Ap，CP则采用Raft

协议实现保持数据的一致性。

如果选择为Ap模式，注册服务的实例仅支持临时模式，在网络分区的的情况允许注册服务实例，选择CP模式可以支持注册服务的实例为持久模式，在网络分区的产生了抖动情况下不允许注册服务实例。

切换cp、ap接口

'$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

CAP定律概念（集群情况下）

一致性（C）：在分布式系统中，如果服务器是集群情况下，每个节点时刻保证查询数据的一致性问题

可用性（A）：集群节点中，部分的节点出现了故障后任然可以继续使用

分区容错性（P）：在分布式系统中网络存在脑裂的问题，部分的server与整个集群失去联系无法形成一个群体。

eureka与nacos底层实现集群协议有哪些区别？

1、eureka：去中心化对等

2、nacos：raft协议实现集群产生领导角色

raft分布式系统一致性算法

分布式系统一致性算法，应用于系统软件实现集群保持没每个节点数据同步性。

场景：reids集群、nacos集群、mongdb集群等

分布式事务一致性框架和分布式系统一致性算法？

分布式事务一致性框架：核心解决实际系统中产生跨事务导致分布式事务问题，核心是最终一致性。

有哪些：rocketmq事务消息、rabbitmq补单、lcn、seata。

分布式系统一致性算法：解决系统软件实现集群保持每个节点数据同步性。

有哪些：raft（nacos）、zab（zookeeper）

zookeeper基于ZAP协议实现保持每个节点的数据同步，中心化思想集群

zookeeper通过myid设置值，哪个myid越大表示能力越强，或者随机时间，越短能力越大。

整个集群中为了保持数据一致性的问题，必须满足大多数情况，>=N/2+1，可运行环境才能使用

ZAP的协议实现原理是通过比较myid,myid谁最大谁可能是领导者，只要满足过半的机制就可以成为领导角色，后来启动的节点不会参与选举。

如何保持数据的一致性问题？

所有的写的请求统一交给我们的领导角色实现，领导角色写完数据之后，领导角色在将数据同步给每个节点。

image.png

如果myid=2的节点断电，myid1的zxid更新成100，myid3数据还没有更新，zxid还是0，会先去比较zxid，myid1成为新的leader

选举过程：

先去比较zxid zxid 谁最大谁就是为领导角色；

如果zxid相等的情况下， myid谁最大谁就为领导角色；

Ratf整个底层实现原理：

在Raft协议中分为的角色

1.状态：分为三种 跟随者、竞选者、领导

2.大多数：  >=n/2+1

3.任期：每次选举一个新的领导角色 任期都会增加。

选举的过程是怎么样的？

  1. 默认的情况下每个节点都是为跟随者

  2. 每个节点会随机的生成一个选举的超时时间，例如大概是100-300ms

在这个超时的时间范围类必须要等待。

  1. 超时时间过后，当前的节点的状态可能由跟随者变为竞选者状态，

会给其他的节点发出选举的投票通知，只要该竞选者有超过半数以上即可选为领导角色。

核心设计的原理：谁超时时间最短谁左右大概率的为领导角色。

那么如何随机数有可能一样的情况下

  1. 如果所有的节点的超时随机数都是一样的情况下， 当前投票全部作废，重新进入随机生成超时时间。

  2. 如果有多个节点生成的随机都是一样的情况下，比较谁的票数最多，谁就是为领导。

如果票数完全一样的情况，直接作废 ，重新进入随机生成超时时间。

建议集群节点为奇数。

故障重新实现选举

  1. 如果我们跟随者节点不能及时的收到领导角色的消息的，那么这时候跟随者状态就会变为竞选者状态，发给其他的节点发出选举投票通知，只要该竞选者有超过半数以上即可选举为领导角色。

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

  1. 所有的写的请求都是统一交给我们的领导角色完成，会写入该对应的日志 ，标记该状态是为提交状态。

  2. 为了提交该日志，领导角色就会将该日志心跳的形式发送其他的跟随者，只要满足过半的跟随者可以写入该数据，则为直接通知其他节点同步该数据，这个称作为日志复制。

avatar
文章
阅读
粉丝