分布式系统的挑战
date
Dec 24, 2021
slug
distributed-system-troubles
status
Published
tags
DDIA
summary
DDIA第8章读书笔记
type
Post
哈尔滨今天好冷啊
分布式系统的挑战
这一章主要列举了分布式系统环境下可能出现的几种挑战
一些思想
- 对于单机系统而言，系统会以一种确定性的方式运行（要么完全正确，要么完全失效）
- 对于分布式系统而言，会有很多不确定的因素来干扰，还有部分失效等问题，需要基于不可靠的组件构建可靠的系统，并且，单节点不能根据自己的信息来判断自己的状态
对于大规模计算系统的两个思路：
- 超算
- 云计算
不可靠的网络
这里最关键的一个问题在于，分布式系统某个节点和其他节点之间进行通讯，只能通过网络访问，当超时未响应的时候并不能判断究竟是网络延迟还是节点失效还是响应丢失。
倒是可以采用电路交换这种方式来降低延迟，但是带宽限制太大，所以还是会用可能会带来拥塞的分组交换的形式。
但是如果超时是故障检测的唯一可行的方法，那么超时应该设置为多少呢？太长了就会有长时间的等待，太短的话可能出现误判甚至可能会出现级联失效
比较好的做法是，不要把超时设置成一个常量，而是持续测量响应时间及其变化（抖动），然后根据最新的响应时间分布来自动调整。（类似与TCP的超时重传）
不可靠的时钟
- 墙上时钟：可以理解为绝对时间
- 单调时钟：可以理解为相对时间
时钟同步可能会出现很多很多问题，而且墙上时钟最后的结果准确的讲应当是一个带有置信范围的时间区间。
真相
真相由多数决定，单节点不能根据自己的信息来判断自己的状态
👆举例（第五章的读写quorum）
若是主从复制想要只有一个主节点呢？
可以给这个节点加锁
但是其中又有特例，加了锁之后，这个节点可能被暂停了，外界认为他死了，又把锁给了别人，他又复活了但是他不知道自己被宣判了死亡，依旧认为自己是主节点去执行的话，就会出错。
所以这里有一个蛮有意思的解决方式
Fencing令牌
分配锁的时候同时分配一个唯一的递增的令牌，当旧的主节点醒过来拿着旧的令牌去访问的时候，外界早就更新了新的令牌，自然就会被拒绝，从而减少错误
这里还带了一嘴拜占庭将军问题，这个应该会在第九章一致性问题里面详细说明
最后
算法的正确性：
- 安全：（没有发生意外）
- 活性：（一般都是最终怎么怎么样）
正确的算法可能在工业届并不work
但是将实际中的复杂问题抽象出来一个模型是有很大价值的
In distributed systems,suspicion,pessimism,and paranoia pay off.