idea's blog

对于一个多节点的分布式系统集群, 我们分析一下经常会遇到哪些问题:

1. 因为出现网络分区或者节点关机, 客户端访问到了宕机节点
2. 因为网络分区得到恢复或者节点启动, 客户端没有访问正确的节点
3. 集群扩容/缩容(也就是增删节点)过程中, 客户端访问了错误的节点

在分布式系统环境中, 客户端访问到错误的节点的情况一定会出现, 直接的后果就是请求失败, 所以, 这个问题是分布式系统高可用的核心障碍之一. 如果不解决这个问题, 一个系统一定不是高可用的.

这3个问题, 其实是一个问题, 就是一个分布式系统, 能否支持平滑增删节点的问题. 在设计开发一个分布式系统时, 平滑增删节点必须作为一个必不可少的基础特性.

Continue reading »

学习分布式一致性协议的程序员, 或早或晚都会面临所谓的"Paxos 日志幽灵复现"的问题. 就跟学习 TCP 总会遇到所谓的"拆包粘包"问题一样. 这类问题非常之经典, 人们对它们抱有非常顽固的似是而非的误解, 有时这些误解是对的, 但本质其实是错的. 原因就在于, 它们超过了人们的日常理解, 是一种违反常理的东西.

比如 "TCP 粘包"问题, 你能说它不存在吗? 现象确实是这个现象, 但问题本质不是字面上的原因. "TCP 粘包"问题的本质, 是 TCP 对上层提供的是"流", 根本就没有"包"这个概念. 但是, 上层的常理认为, "TCP 应该提供报文服务". 常理如此强烈和普遍, 但 TCP 又拒绝满足常理需求, 所以造成了经典的误解.

Paxos 所谓的"幽灵复现", 有多篇较流行的文章: 1, 2, 3.

假设某个集群, 集群节点是 A, B, C, 用户在不同时刻访问不同的节点. 用上帝视角观察, 其内部日志序列是这样变化的:

Continue reading »

Paxos 所谓的日志空洞, 在讨论 Paxos 和 Raft 对比时出现的频率非常高, 非常显眼. Paxos 的日志空洞是什么? "日志空洞"对线性一致性有什么影响? 我认为大多数人都对 Paxos 日志空洞有误解, 包括我之前也是.

很多人认为 Multi Paxos 可以允许空洞, 但是 Paxos 论文提到:

To guarantee that all servers execute the same sequence of state machine commands, we implement a sequence of separate instances of the Paxos consensus algorithm, the value chosen by the ith instance being the ith state machine command in the sequence.

状态机必须严格按顺序执行(apply)命令, 所以, Multi Paxos 并不允许 apply 时出现所谓的日志空洞. 虽然会乱序 chosen(也即所谓的空洞), 但是, apply 一定是严格按顺序进行的. Apply 的时候, 如果不是严格按顺序的, 就不是日志复制状态机.

但是, 因为必须严格按顺序执行日志序列, 所以, 即使 Multi Paxos 乱序 chosen 日志, 也不会影响外部一致性.

Continue reading »

正如之前文章"分布式系统核心三要素"所提到的, 多分区(Sharding) 是分布式系统必不可少的核心特性, 无 Sharding 不分布式. Sharding 之后, 必然会遇到服务发现的问题, 也即服务寻址, 或者路由表.

客户端在访问系统的服务之前, 需要拉取路由表, 根据路由表找到访问点的地址, 然后直接请求节点. 根据"Single Source of Truth"原理, 路由表的信息并不是 Truth, 不可能实时反映集群的 Sharding 分布, 因此, 客户端有可能访问到错误的节点. 这是无法避免的.

因此, 当某个节点收到了在其服务范围之外的请求时, 它有两种策略选择:

1. 返回 Redirect, 让客户端重新寻址
2. 作为 Proxy, 向正确的节点转发请求, 并在收到响应后返回给客户端

这两个策略各有优劣.

Redirect 可以简化服务节点的结构, 同时, 可以促使客户端及时更新路由表, 避免再次出现寻址错误. 但是, Redirect 会增加客户端的复杂度, 同时增加请求的 RT(Response Time), 因为客户端需要更换节点访问, 多了一次网络来回时间(RTT).

Proxy 会增加服务节点的复杂度, 但同时简化客户端的结构. 而且, 采取 Proxy 方式, 将无法让客户端及时地认识到自己的路由表信息错误, 除非通过带外数据的方式, 改变响应的结构, 增加额外的信息.

流行的多副本 KV 数据库 etcd(根据"分布式系统核心三要素", 因为其没有 Sharding 能力, 所以不算是分布式, 但可以称为"伪"分布式), 采取 Proxy 策略, 所以, follower 节点对外表现为可以处理写请求.

很多初学者错误地认为, 像 Raft 这样的 leader based 的分布式协议不是 100% 高可用的, 因为"Raft 在选主的过程中, 不能提供服务". 初学者之所以存在这种错误认知, 完全是因为他们没有理论结合实践, 只略懂一点理论皮毛, 就胡乱引申导致的. 本文将在理论和实践结合的层面上, 分析这种错误认知.

首先, Raft 的选举过程并没有特殊的成本, 在局域网条件下, 一般只需要 5ms 的时间. 5 毫秒对于实用的分布式集群, 是微不足道的时间长度, 因为客户端对时间长度的认知是百毫秒级别的, 只要客户端在 5 毫秒之后重试[可靠通信三原则], 或者服务器先 Hold 住请求, 过 5 毫秒之后再处理, 对于客户端来说, 完全没有感受到服务不可用, 因此, 服务是 100% 高可用.

我认为, leader based 的集群, 最大的问题在于"何时发起选举?". 也就是, 如何能快速地发现当前集群失去了有效的 leader.

客户端可能发现集群无主, 但是, 我们不会把这个权限赋予客户端, 因为在 CS 理论中, 客户端是不可信的. 所以, 只能交由集群成员去发现集群是否需要发起选举.

Continue reading »

曾经有一次, 某个技术人员向我介绍了他们自研的"分布式存储系统", 他提到, 他们使用了开源的 Raft 库做数据同步, 使用了开源的 B+Tree 存储引擎存储数据到硬盘上. 由于使用的都是非常成熟的开源组件, 技术选型非常正确, 系统结构也简单合理, 这样的系统, 不可否认, 能存储几 TB 的数据, 被广泛应用起来完全没有问题.

但是, 对于他自称这是一个"分布式数据库"或者"分布式存储系统", 我无法认同, 我无法认同以如此功能如此结构的系统, 竟能挂以"分布式"之名. 但是, 我又没有理论支持说"你们这个系统不是分布式系统!".

虽然诡辩术广泛存在, 同时每个人的视角不同, 但是, 根据我的实际经验, 和我对分布式系统的理解, 我想总结出分布式系统的核心三要素, 只具备部分要素的系统, 要谨慎挂以"分布式"之名.

分布式系统核心三要素:

• 要素一: 多副本(Replication), 系统包含多个完全相同(一致)的节点
• 要素二: 多分区(Sharding), 系统被拆分成多个完全独立的节点组
• 要素三: 协作(Cooperation), 节点组之间有协作, 共同完成某项工作

Continue reading »