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

原文转载自 「idea's blog」 ( https://www.ideawu.net/blog/archives/1188.html ) By ideawu

预计阅读时间 0 分钟(共 0 个字, 0 张图片, 0 个链接)

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

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

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

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

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

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

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

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

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

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

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

Related posts:

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