理解分布式系统：关键概念与实践概述

分布式系统

需积分: 10 40 浏览量更新于2024-07-18 1 收藏 806KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

A system model

A key property of distributed systems is distribution. More specifically, programs in a

distributed system:

run concurrently on independent nodes ...

are connected by a network that may introduce nondeterminism and message loss ...

and have no shared memory or shared clock.

There are many implications:

each node executes a program concurrently

knowledge is local: nodes have fast access only to their local state, and any

information about global state is potentially out of date

nodes can fail and recover from failure independently

messages can be delayed or lost (independent of node failure; it is not easy to

distinguish network failure and node failure)

and clocks are not synchronized across nodes (local timestamps do not correspond

to the global real time order, which cannot be easily observed)

A system model enumerates the many assumptions associated with a particular system

design.

System model

a set of assumptions about the environment and facilities on which a distributed system is

implemented

System models vary in their assumptions about the environment and facilities. These

assumptions include:

what capabilities the nodes have and how they may fail

how communication links operate and how they may fail and

properties of the overall system, such as assumptions about time and order

A robust system model is one that makes the weakest assumptions: any algorithm written

for such a system is very tolerant of different environments, since it makes very few and

very weak assumptions.

On the other hand, we can create a system model that is easy to reason about by making

strong assumptions. For example, assuming that nodes do not fail means that our

algorithm does not need to handle node failures. However, such a system model is

unrealistic and hence hard to apply into practice.

Let's look at the properties of nodes, links and time and order in more detail.

Nodes in our system model

Nodes serve as hosts for computation and storage. They have:

the ability to execute a program

the ability to store data into volatile memory (which can be lost upon failure) and into

12/68

stable state (which can be read after a failure)

a clock (which may or may not be assumed to be accurate)

Nodes execute deterministic algorithms: the local computation, the local state after the

computation, and the messages sent are determined uniquely by the message received

and local state when the message was received.

There are many possible failure models which describe the ways in which nodes can fail. In

practice, most systems assume a crash-recovery failure model: that is, nodes can only fail

by crashing, and can (possibly) recover after crashing at some later point.

Another alternative is to assume that nodes can fail by misbehaving in any arbitrary way.

This is known as Byzantine fault tolerance. Byzantine faults are rarely handled in real world

commercial systems, because algorithms resilient to arbitrary faults are more expensive to

run and more complex to implement. I will not discuss them here.

Communication links in our system model

Communication links connect individual nodes to each other, and allow messages to be

sent in either direction. Many books that discuss distributed algorithms assume that there

are individual links between each pair of nodes, that the links provide FIFO (first in, first out)

order for messages, that they can only deliver messages that were sent, and that sent

messages can be lost.

Some algorithms assume that the network is reliable: that messages are never lost and

never delayed indefinitely. This may be a reasonable assumption for some real-world

settings, but in general it is preferable to consider the network to be unreliable and subject

to message loss and delays.

A network partition occurs when the network fails while the nodes themselves remain

operational. When this occurs, messages may be lost or delayed until the network partition

is repaired. Partitioned nodes may be accessible by some clients, and so must be treated

differently from crashed nodes. The diagram below illustrates a node failure vs. a network

partition:

It is rare to make further assumptions about communication links. We could assume that

links only work in one direction, or we could introduce different communication costs (e.g.

latency due to physical distance) for different links. However, these are rarely concerns in

13/68

commercial environments except for long-distance links (WAN latency) and so I will not

discuss them here; a more detailed model of costs and topology allows for better

optimization at the cost of complexity.

Timing / ordering assumptions

One of the consequences of physical distribution is that each node experiences the world

in a unique manner. This is inescapable, because information can only travel at the speed

of light. If nodes are at different distances from each other, then any messages sent from

one node to the others will arrive at a different time and potentially in a different order at the

other nodes.

Timing assumptions are a convenient shorthand for capturing assumptions about the

extent to which we take this reality into account. The two main alternatives are:

Synchronous system model

Processes execute in lock-step; there is a known upper bound on message transmission

delay; each process has an accurate clock

Asynchronous system model

No timing assumptions - e.g. processes execute at independent rates; there is no bound on

message transmission delay; useful clocks do not exist

The synchronous system model imposes many constraints on time and order. It essentially

assumes that the nodes have the same experience: that messages that are sent are

always received within a particular maximum transmission delay, and that processes

execute in lock-step. This is convenient, because it allows you as the system designer to

make assumptions about time and order, while the asynchronous system model doesn't.

Asynchronicity is a non-assumption: it just assumes that you can't rely on timing (or a "time

sensor").

It is easier to solve problems in the synchronous system model, because assumptions

about execution speeds, maximum message transmission delays and clock accuracy all

help in solving problems since you can make inferences based on those assumptions and

rule out inconvenient failure scenarios by assuming they never occur.

Of course, assuming the synchronous system model is not particularly realistic. Real-world

networks are subject to failures and there are no hard bounds on message delay. Real

world systems are at best partially synchronous: they may occasionally work correctly and

provide some upper bounds, but there will be times where messages are delayed

indefinitely and clocks are out of sync. I won't really discuss algorithms for synchronous

systems here, but you will probably run into them in many other introductory books because

they are analytically easier (but unrealistic).

The consensus problem

During the rest of this text, we'll vary the parameters of the system model. Next, we'll look

at how varying two system properties:

whether or not network partitions are included in the failure model, and

14/68

剩余67页未读，继续阅读

gongwayne

粉丝: 1
资源: 19

理解分布式系统：关键概念与实践概述

分布式计算：原理，算法与系统（英文版）

分布式系统——概念和设计 英文版

分布式英文课件比较全面介绍了分布式

分布式计算系统导论——原理与组成 pdf

头歌大数据从入门到实战 - 第2章 分布式文件系统hdfs

大数据从入门到实战 - 第2章 分布式文件系统hdfs

大数据从入门到实战 - 第2章 分布式文件系统HDFS

头歌大数据入门到实战 第二章分布式文件系统hdfs

Zookeeper入门看这篇就够了

监控平台skywalking9入门实践

Redis现分布式事务

最新的springcloud 入门到精通

springcloud快速入门

JAVA微服务入门课程

鸿蒙仓颉编程语言入门

redis 入门到精通 pdf

git 入门文档瞎子啊

zeroc ice权威指南

springcloud框架的学习培训系统

golang后端工程师学习路线

最新资源

分布式系统——概念和设计英文版

头歌大数据从入门到实战 - 第2章分布式文件系统hdfs

大数据从入门到实战 - 第2章分布式文件系统hdfs

大数据从入门到实战 - 第2章分布式文件系统HDFS

头歌大数据入门到实战第二章分布式文件系统hdfs