1. 分布式

1.1. ETCD 应用场景

ETCD 应用场景

1.2. CAP 理论

概述

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

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

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

1.3. 分布式系统一致性

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

会引申到 CAP 理论

1.4. raft 算法细节

动态图

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

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

  • raft
    • ETCD
    • Consul

1.6. 最终一致性

1.7. RPC 是什么

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

1.8. RPC 相对于传统 API 优点

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

1.10. grpc

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

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

1.11. thrift

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

results matching ""

    No results matching ""