分布式系统原理介绍前端开发文档.pdf

• 一台服务器的性能不足以提供足够的能力服务于所有的网 络请求。 • 我们总是害怕我们的这台服务器停机，造成服务不可用或 是数据丢失。 • 分布式系统的难点在于各种异常处理 • 机器宕机 • 网络故障 • 数据丢失 • 这种异常在跨广域网时尤为突出 三种状态（两种：有返回 没返回） • vs • 成功。返回成功消息。 • 失败。返回出错消息。 • 超时。没有返回。 调用是否成功和 很相似 • RPC TCP • 考虑超时情况： • Client 成功call 了server • Server成功执行，但没有把消息返回给client • 解决方案 • 重试（幂等性） • Server端回滚 • 基本模型 • A 把数据传给B • B 做数据处理，把结果返回A • 异常处理 • A在传送数据的时候，出现故障，B就没有收到。 • A把数据成功传给B，但B没有返回。 • A把数据成功传给B，B也成功处理了，也返回了，但A没有收到。 • 处理原则 • 异常总是会发生的，除非指标允许，否则一定在设计上不能放过 • 有的异常理论上无法解决，工程上可以降低其出现的概率到极小。 有两支军队，准备攻击一座修筑了防御工事的城市。这两支军队分占一座山头。 一道山谷把两座山分隔开来，并且两位将军唯一的通信方式就是派各自的信使来 往于山谷两边。不幸的是，这个山谷已经被那座城市的保卫者占领，并且存在一 种可能，那就是任何被派出的信使通过山谷是会被捕。请注意，虽然两位将军 已经就攻击那座城市达成共识，但在并没有就进攻时间达成共识。两位将军必须 必须互相沟通，以确定一个时间来攻击，并同意就在那时攻击。如果只有一个将 军进行攻击，那么这将是一个灾难性的失败。 • 两将军问题可以扩展成拜占庭将军问题(Byzantine Generals Problem)，其故事背景是这样的： 拜占庭位于现在土耳其的伊斯坦布尔，是东罗马帝国的首都。 由于当时拜占庭罗马帝国国土辽阔，为了防御目的，因此每 个军队都分隔很远，将军与将军之间只能靠信差传消息。在 战争的时候，拜占庭军队内所有将军必需达成一致的共识， 决定是否有赢的机会才去攻打敌人的阵营。但是，军队可能 有叛徒和敌军间谍，这些叛徒将军们会扰乱或左右决策的过 程。这时候，在已知有成员谋反的情况下，其余忠诚的将军 在不受叛徒的影响下如何达成一致的协议，这就是拜占庭将 军问题。 • 对我们的服务器进行扩展，加入更多的机器来分担性能上 的问题，以及来解决单点故障问题。通常，我们会通过两 种手段来扩展我们的数据服务： • 数据分区： • 把数据分块放在不同的服务器上（如：uid % 16 ，一致性哈希等） • 问题：我们无法解决数据丢失的问题，单台服务器出问题时，会有 部分数据丢失。 • 数据镜像： • 让所有的服务器都有相同的数据，提供相当的服务。 数据服务的高可用性只能通过这种方法来完成 数据的冗余存储 • —— • 问题：加入更多的机器，会让我们的数据服务变得很复杂，尤其是 跨服务器的事务处理，也就是跨服务器的数据一致性。 需要 个步骤 • 6 1. 从A帐号中把余额读出来。 2. 对A帐号做减法操作。 3. 把结果写回A帐号中。 4. 从B帐号中把余额读出来。 5. 对B帐号做加法操作。 6. 把结果写回B帐号中。 这 件事，要么都成功做完，要么都不成功，而且这个操 • 6 作的过程中，对 、 帐号的其它访问必需锁死，所谓锁死 A B 就是要排除其它的读写操作，不然会有脏数据的问题，这 就是事务 • 数据分区 如果A帐号和B帐号的数据不在同一台服务器上怎么办？我们