这是我参与2022首次更文挑战的第27天，活动详情查看：2022首次更文挑战
如何判断实际情况与修复
在上文我们看到有很多原因可以导致分布式系统出现问题，但是很难确认具体是什么原因导致的，因此我们要自己探索什么是真相什么是谎言
- 通过假设的方式验证某一些算法的正确性
真相由大多数决定
由严重到轻微有三种情况
- 该节点运行良好，可以正常接收其他节点发送的消息，但是其发出的消息由于网路问题被丢弃或者延期超时
- 该节点能意识到自己的网络并不好
- 该节点因为GC等原因暂停服务，让其他节点以为该节点挂了，但是一段时间后其又可以正常进行工作了
每个节点都有可能会出现各种状况，分布式系统决策需要去中心化
-
许多使用的是投票机制，由多数决定该节点是否有效，如果大部分节点觉得其已经失效，即使该节点没有失效，我们都认为其已经下线了，可以运用在其他的场景\
-
-
在某一些场景下，需要选举出某一个特殊节点（如数据库的主节点）或者说唯一一个实例（如ID、锁）\
-
- 限制只能有一个节点在使用，如果采用简单的过期机制，可能也会出现误判节点问题，导致数据出错
- 需要保证过期的、下线的节点不会影响其他节点，使用fencing技术，每次进行租用唯一实例的时候，会产生一个递增的令牌，在对唯一实例进行操作的时候，需要带上该令牌，防止下线节点的影响
- 在更为极端的情况下，节点本身尝试破坏（节点不可信），如何保证唯一实例的安全性
-
拜占庭故障
实际上分布式系统的问题主题要有三种：
- 网络的不可靠
- 节点的不可靠
- 节点不诚实，即故意出现错误或者破坏性行为，而对外声称自己是正常的（如自己本没有收到消息，却向外声称自己收到了）
第三种被称为拜占庭故障，指在不信任环境下达成共识的问题，如果在该环境下可以正常运行，我们称为拜占庭式容错系统
在本书中暂且不讨论相关问题，在大多数服务器端数据系统中，部署拜占庭容错系统基本不太可行
分布式模型及其前提
分布式系统已经有许多不错的算法，但是都建立在一定的硬件、软件前提之上
实际上这些前提都可以在系统功能上有明确的、统一的表现，在这里进行形式化的描述
在时间计算方面：
-
同步模型\
-
- 所有的延迟、误差等都是有上界的
\
-
部分同步模型\
-
- 大多数情况下与同步模型无异，但是有时会超出上界
\
-
异步模型\
-
- 与时机没有任何关系，甚至根本没有时钟
在节点失效处理上：
-
崩溃-中止模型\
-
- 节点只会发生一种故障，且发生后节点将无法恢复
\
-
崩溃-恢复模型\
-
- 节点失效后会在一段时间后恢复，永久性存储中的数据并不会丢失
\
- 任意失效模型
在大部分情况下是崩溃恢复+部分同步模型
在现实生活中并不是一直这么理想的，硬件可能会损坏、数据记录可能会丢失等等
