我们在讲分布式系统，我们都在讲些什么 —— 基础概念
date
Jun 13, 2021
slug
distributed-system-01
status
Published
tags
Distributed System
summary
我们在讲分布式系统，我们都在讲些什么
type
Post
有场景有需求我们才会去实现，如果本来单机可以解决的问题，就不需要分布式系统去解决。
引入分布式系统带来的麻烦比单机要庞大的多。
但是有些场景下，单机做不到的事情促使我们将任务分给其他机器，以求提升整体性能和吞吐量。
加一台服务器或者一个进程并不是命令敲一下那么简单，随之而来的是：
- 多台服务器有一台宕机或者物理损坏怎么办？
- 服务器之间网络出现波动甚至不互通怎么办？
- 内网和外网之间断开链接怎么办？
分布式系统引入之后，无论是硬件还是软件，故障的几率大大增加。
所以设计分布式系统，需要着重关注两点：
- 性能
- 容错
在实际操作中，性能指标很容易定量去分析，比如每日的 QPS 曲线。而容错就很模棱两可，有些冗余信息没有及时同步可能不影响用户体验，某些微服务短暂宕机用户也是无法感知，甚至某些数据后面也可以修复。所以在讨论分布式系统的时候，还是先从场景出发，不要上来就追求完美的一致性，很容易陷入过度设计的陷阱给自己挖了深坑。
那么在设计分布式系统的时候，也大致有两个思路：
- 中心化
- 去中心化
中心化是目前我们接触的设计中比较常用的一种，传统思路就是系统中分为两个主要角色：
- Leader
- Worker
Leader 统筹全局，监控指标，分发任务，调度 Worker，发现 Worker 不能工作的时候，会采取一定的策略来保障系统有序运行。
那么我们自然而然想到的就是 Leader 挂了怎么办？
成熟的分布式系统都会考虑这个问题，比较简单的做法是准备一个备胎，平时跟着 Leader 做事，Leader 挂了它就顶上。那备胎也挂了呢？现在一些系统准备了选举方案，从 Worker 或者准备更多的备胎都是可以的。
我们发现把宝全部押在中心化的 Leader 上，Leader 承受了太多的压力，很容易成为系统性能提升的阻碍。比如我们在设计 Load Balance 最理想的是把流量平均打入每一个服务，而不是一个服务干活，其他服务在旁边看着。
所以我们就会去思考，能不能去掉 Leader ，或者每个 Worker 都是 Leader。但是在分布式系统中，每个 Worker 通信本来就存在各种不确定性。如果因为网络故障或者某个小概率 Bug 导致数据冲突，带来的结果可能是灾难性的。
但，思想是可以融合的，两种思想取长补短，比如 Leader 和 Worker 一开始就是平级的，Worker 自发选举出 Leader 就算挂了，也能很快拉出一个来顶替上去。etcd 就采取了这种模式
