分布式

ETCD 应用场景

ETCD 应用场景

CAP 理论

概述

• 一致性 (Consistency): 分为强/弱/最终一致性
  • 强一致性: 要求更新后的数据能被后续的访问都能看到
  • 弱一致性: 能容忍后续的部分或全部访问不到
  • 最终一致性: 经过过一段时间后能访问到更新后的数据
• 可用性 (Availability): 服务在正常响应时间内一直可用，不出现用户操作失败或访问超时等情况
• 分区容错性 (Partition Tolerance): 分布式系统在遇到某节点或网络分区故障的时候，仍然能对外提供满足一致性或可用性的服务

CAP 只能满足其2，不能全部满足。其中 P 分区在分布式系统中由于网络原因，是始终会存在的，所以通常谈 CAP 都指的是 CA 的取舍。

CP without A: 不要求可用性。相当于在 node 之间要求强一致性，一些传统数据库的分布式事务就是属于这种。 AP without C: 不要求一致性。在分区发生时，节点之间可能失去联系，为了高可用，每个节点只能使用本地数据提供服务，这回导致全局数据的不一致性，目前很多 NoSQL 是属于此类。

分布式系统一致性

• 强一致性: 牺牲可用性，node 之间要求必须同步，如果出现分区的情况，同步操作会一直等待，导致 node 不可用。
• 弱一致性: 允许分区之间数据不一致，分区时继续提供服务，在分区合并后也不要求数据一致
• 最终一致性: 允许分区之间数据不一致，分区时继续提供服务，在分区合并后要求数据一致（同步）

会引申到 CAP 理论

raft 算法细节

动态图

属于强一致性的 CP 系统，牺牲了部分可用性(在分区后的少节点分区中发生)

常见中间件使用的一致性算法

• raft
  • ETCD
  • Consul

最终一致性

RPC 是什么

在分布式系统中，远程过程调用(Remote Procedure Call, RPC) 是一个计算机通信协议，该协议允许运行于一台计算机的程序调用另一个地址空间（通常为一个开放网络的一台计算机）的子程序，而程序员就像调用本地程序一样，无需额外地为这个交互作用编程（不用关注细节）。

RPC 相对于传统 API 优点

服务调度中心的感知与动态上下线

grpc

一种 rpc(远程过程调用) 框架，使客户端和服务端能够透明的通信，使构建连接系统变得更加容易。

基于 HTTP/2 协议标准设计，基于 ProtoBuf(Protocol Buffers) 序列化协议开发，支持很多语言。

thrift

facebook 出品的 rpc 框架，后交给 apache 基金会维护。是基于 tcp 协议实现的通讯协议，也是一种接口描述语言，和 grpc 很类似。