0
分布式系统最重要的基础特性 – 平滑增删节点
对于一个多节点的分布式系统集群, 我们分析一下经常会遇到哪些问题:
- 因为出现网络分区或者节点关机, 客户端访问到了宕机节点
- 因为网络分区得到恢复或者节点启动, 客户端没有访问正确的节点
- 集群扩容/缩容(也就是增删节点)过程中, 客户端访问了错误的节点
在分布式系统环境中, 客户端访问到错误的节点的情况一定会出现, 直接的后果就是请求失败, 所以, 这个问题是分布式系统高可用的核心障碍之一. 如果不解决这个问题, 一个系统一定不是高可用的.
这3个问题, 其实是一个问题, 就是一个分布式系统, 能否支持平滑增删节点的问题. 在设计开发一个分布式系统时, 平滑增删节点必须作为一个必不可少的基础特性.
根据之前分析的"可靠通信三原则 - ideawu.net", 客户端遇到请求失败,只能通过重试解决, 没有第二条路 . 所以, 解决增删节点所导致的请求失败问题, 必须要求客户端一起参与解决(也就是重试), 仅仅依赖 server 端是不可行的.
分布式系统是复杂的, 要考虑的东西非常多, 但是, 平滑增删节点这一特性必须优先考虑, 这一特性的有无和好坏, 对系统是一票否决性质的.
如果一个分布式系统一开始就能平滑增删节点, 会带来什么好处呢?
首先, 可以随时进行版本升级. 分布式系统的高复杂度决定了它不可能一蹴而就, 而是持续进化. 线上系统需要不断地发布新版本升级, 甚至可能几天一升级. 如果升级过程不平滑, 那就不敢升级线上系统了.
其次, 可以随时调配服务器资源. 分布式系统的重要特性是能动态的调配资源, 系统的数据和计算需要在机器之间转移流动, 也就是我们常常说的迁移, 或者缩扩容,本质就是增删节点 .
平滑增删节点既是理论问题, 也是实践细节问题. 即使是多副本系统的集大成者如 Raft 协议, 看起来似乎是高可用的, 但是在工程实践上, 例如直接拨 leader 机器的网线, 这时, 客户端(业务)立马就出现大量请求失败告警了. 因为, 这是个实践细节问题, 论文上可不会告诉你这些.
但是, "可靠通信三原则"告诉你, 要么重试直至成功, 要么就返回失败记 error log 报错发告警短信. 你以为用了 Raft/Paxos 就是高可用的? 没有这样的好事, 高可用, 平滑增删节点, 这些特性可不是免费的, 也不是用了某个算法某个库换来的, 而是需要你重试 请求换来的(或者提前预知故障 - ideawu.net).
另一篇文章:分布式数据库系统如何做到平滑缩扩容? - ideawu.net
