分布式

littleCat
129 阅读5分钟

cap

image.png

image.png

base

image.png

分布式一致性算法

主要有Paxos、Raft、ZAB。

Paxos算法是Leslie Lamport在1990年提出的一种基于消息传递的一致性算法，非常难以理解，基于Paxos协议的数据同步与传统主备方式最大的区别在于：Paxos只需超过半数的副本在线且相互通信正常，就可以保证服务的持续可用，且数据不丢失。

Raft是Paxos的简化版，与Paxos相比，Raft强调的是易理解、易实现，Raft和Paxos一样只要保证超过半数的节点正常就能够提供服务。etcd使用raft算法，Google的Kubernetes也是用了etcd作为他的服务发现框架。

ZAB （ZooKeeper Atomic Broadcast , ZooKeeper原子消息广播协议)，ZAB借鉴Paxos算法，它是一种特别为ZooKeeper专门设计的支持崩溃恢复的原子广播协议。

注册中心选型

juejin.cn/post/706806…

ectd,nacos

Zookeeper不适合作为注册中心

当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

在 CAP 模型中，Zookeeper整体遵循一致性（CP）原则，即在任何时候对 Zookeeper 的访问请求能得到一致的数据结果，但是当机器下线或者宕机时，不能保证服务可用性。

那为什么Zookeeper不使用最终一致性（AP）模型呢？因为这个依赖Zookeeper的核心算法是ZAB，所有设计都是为了强一致性。这个对于分布式协调系统，完全没没有毛病，但是你如果将Zookeeper为分布式协调服务所做的一致性保障，用在注册中心，或者说服务发现场景，这个其实就不合适。

Nacos

image.png

  1. Raft算法：Nacos使用了Raft算法作为分布式一致性算法。Raft算法保证了分布式环境下数据的一致性，并且可以容忍节点故障；
  2. 数据库：Nacos使用MySQL作为存储服务注册和配置信息的数据库；
  3. RPC框架：Nacos使用了gRPC作为远程过程调用框架；

ETCD

etcd是一个Go言编写的分布式、高可用的一致性键值存储系统，用于提供可靠的分布式键值存储、配置共享和服务发现等功能。

image.png

etcd vs zookeeper

dzone.com/articles/ap…

zookeeper Pros

  • Event support through ZooKeeper watches.
  • In a network partition, both minority and majority partitions will start a leader election. Therefore, the minority partition will stop operations.

zookeeper Cons

  • Since ZooKeeper is written in Java, it inherits few drawbacks of Java (i.e. garbage collection pauses).
  • When creating snapshots (where the data is written to disks), ZooKeeper read/write operations are halted temporarily. This only happens if we have enabled snapshots. If not, ZooKeeper operates as an in-memory distributed storage.
  • ZooKeeper opens a new socket connection per each new watch request we make. This has made ZooKeepers like more complex since it has to manage a lot of open socket connections in real time.

etcd pros

  • Incremental snapshots avoid pauses when creating snapshots, which is a problem in ZooKeeper.
  • No garbage collection pauses due to off-heap storage.
  • Watchers are redesigned, replacing the older event model with one that streams and multiplexes events over key intervals. Therefore, there's no socket connection per watch. Instead, it multiplexes events on the same connection.
  • Unlike ZooKeeper, etcd can continuously watch from the current revision. There's no need to place another watch once a watch is triggered.
  • etcd3 holds a sliding window to keep old events so that disconnecting will not cause all events to be lost.

Cons

  • etcd may also abort operations when there is a leader election.
  • Serialized read requests will continue to be served in a network split where the minority partition is the leader at the time of the split.

拜占庭将军问题

在分布式系统领域, 拜占庭将军问题中的角色与计算机世界的对应关系如下:

  • 将军, 对应计算机节点;
  • 忠诚的将军, 对应运行良好的计算机节点;
  • 叛变的将军, 被非法控制的计算机节点;
  • 信使被杀, 通信故障使得消息丢失;
  • 信使被间谍替换, 通信被攻击, 攻击者篡改或伪造信息.

如上文所述, 拜占庭将军问题提供了对分布式共识问题的一种情景化描述, 是分布式系统领域最复杂的模型. 此外, 它也为我们理解和分类现有的众多分布式一致性协议和算法提供了框架. 现有的分布式一致性协议和算法主要可分为两类:

  • 一类是故障容错算法(Crash Fault Tolerance, CFT) , 即非拜占庭容错算法, 解决的是分布式系统中存在故障, 但不存在恶意攻击的场景下的共识问题. 也就是说, 在该场景下可能存在消息丢失, 消息重复, 但不存在消息被篡改或伪造的场景. 一般用于局域网场景下的分布式系统, 如分布式数据库. 属于此类的常见算法有Paxos算法, Raft算法, ZAB协议等.

  • 一类是拜占庭容错算法, 可以解决分布式系统中既存在故障, 又存在恶意攻击场景下的共识问题. 一般用于互联网场景下的分布式系统, 如在数字货币的区块链技术中. 属于此类的常见算法有PBFT算法, PoW算法.

avatar
文章
阅读
粉丝