• Highly Available: It can restore operations, permitting it to resume providing services even when some components
have failed.
• Recoverable: Failed components can restart themselves and rejoin the system, after the cause of failure has been
repaired.
• Consistent: The system can coordinate actions by multiple components often in the presence of concurrency and
failure. This underlies the ability of a distributed system to act like a non-distributed system.
• Scalable: It can operate correctly even as some aspect of the system is scaled to a larger size. For example, we
might increase the size of the network on which the system is running. This increases the frequency of network
outages and could degrade a "non-scalable" system. Similarly, we might increase the number of users or servers, or
overall load on the system. In a scalable system, this should not have a significant effect.
• Predictable Performance: The ability to provide desired responsiveness in a timely manner.
• Secure: The system authenticates access to data and services [1]
These are high standards, which are challenging to achieve. Probably the most difficult challenge is a distributed system
must be able to continue operating correctly even when components fail. This issue is discussed in the following excerpt
of an interview with Ken Arnold. Ken is a research scientist at Sun and is one of the original architects of Jini, and was a
member of the architectural team that designed CORBA.
Failure is the defining difference between distributed and local programming, so you have to design distributed systems
with the expectation of failure. Imagine asking people, "If the probability of something happening is one in 10
13
, how often
would it happen?" Common sense would be to answer, "Never." That is an infinitely large number in human terms. But if
you ask a physicist, she would say, "All the time. In a cubic foot of air, those things happen all the time."
When you design distributed systems, you have to say, "Failure happens all the time." So when you design, you design
for failure. It is your number one concern. What does designing for failure mean? One classic problem is partial failure. If I
send a message to you and then a network failure occurs, there are two possible outcomes. One is that the message got
to you, and then the network broke, and I just didn't get the response. The other is the message never got to you because
the network broke before it arrived.
So if I never receive a response, how do I know which of those two results happened? I cannot determine that without
eventually finding you. The network has to be repaired or you have to come up, because maybe what happened was not
评论0