0
0

分布式系统最重要的基础特性 – 平滑增删节点

ideawu 发表于 2021年07月21日 21:29 | Hits: 343
Tag: 分布式

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

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

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

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

根据之前分析的"可靠通信三原则 - ideawu.net", 客户端遇到请求失败,只能通过重试解决, 没有第二条路 . 所以, 解决增删节点所导致的请求失败问题, 必须要求客户端一起参与解决(也就是重试), 仅仅依赖 server 端是不可行的.

分布式系统是复杂的, 要考虑的东西非常多, 但是, 平滑增删节点这一特性必须优先考虑, 这一特性的有无和好坏, 对系统是一票否决性质的.

如果一个分布式系统一开始就能平滑增删节点, 会带来什么好处呢?

首先, 可以随时进行版本升级. 分布式系统的高复杂度决定了它不可能一蹴而就, 而是持续进化. 线上系统需要不断地发布新版本升级, 甚至可能几天一升级. 如果升级过程不平滑, 那就不敢升级线上系统了.

其次, 可以随时调配服务器资源. 分布式系统的重要特性是能动态的调配资源, 系统的数据和计算需要在机器之间转移流动, 也就是我们常常说的迁移, 或者缩扩容,本质就是增删节点 .

平滑增删节点既是理论问题, 也是实践细节问题. 即使是多副本系统的集大成者如 Raft 协议, 看起来似乎是高可用的, 但是在工程实践上, 例如直接拨 leader 机器的网线, 这时, 客户端(业务)立马就出现大量请求失败告警了. 因为, 这是个实践细节问题, 论文上可不会告诉你这些.

但是, "可靠通信三原则"告诉你, 要么重试直至成功, 要么就返回失败记 error log 报错发告警短信. 你以为用了 Raft/Paxos 就是高可用的? 没有这样的好事, 高可用, 平滑增删节点, 这些特性可不是免费的, 也不是用了某个算法某个库换来的, 而是需要你重试 请求换来的(或者提前预知故障 - ideawu.net).

另一篇文章:分布式数据库系统如何做到平滑缩扩容? - ideawu.net

Related posts:

  1. Raft 选主优化之 PreVote
  2. Raft 为什么不能直接 commit 前任的日志?
  3. Leader based 的集群也可以100%高可用
  4. Paxos和Raft读优化 – Quorum Read 和 Read Index
  5. Raft ReadIndex 有什么神奇之处?

原文链接: https://www.ideawu.net/blog/archives/1188.html

0     0

我要给这篇文章打分:

可以不填写评论, 而只是打分. 如果发表评论, 你可以给的分值是-5到+5, 否则, 你只能评-1, +1两种分数. 你的评论可能需要审核.

评价列表(0)