A talk on the difference between the local computing and distributed computing

All journal authors, in any form reproduced please contact the author.
Author: tison (from watercress)
Source: https://www.douban.com/note/720831988/

Old paper "A Note on Distributed Computing" describes the main difference four points Distributed Computing (Distributed Computing) and local computing (Local Computing), and criticized the remote method invocation (Remote Method Invocation) to distinguish between different types of calculations weakness It is proposed to be a clear distinction between the local computing and distributed computing point of view.

The paper production time and 1994, when it is RPC and RMI popular. Software developers try to develop a model to unify all of the proposed extension to object-oriented distributed computing environment, making the object access without the need to distinguish between objects is a local object or the remote object. This Slogan first sound tempting, but universal access is different from the Truffle Framework objects of different languages ​​to access the shelter, the semantic difference between local and remote access mechanism is far from objects brought in different languages, as well as more basic the difference, making attempts to shield local method calls and remote method invocation will cover some of the problems inherent in distributed systems.

Its one, calling delay (Latency) problems. This is obvious because the method does not require calling a local walking network, to access a remote object needs for network communication. This makes the method code in two similar call performance analysis may be quite different, and this difference is difficult to reflect in the code level. However, the delay is only a question of representation, we can still expect hardware upgrades can bring progress in performance. Delays and will not lead to more serious procedural correctness issues.

Which of the two is the difference between memory access (Memory Access) is. This is also evident after point out that a local reference transmitted to the distal end of the process, this reference is basically ineffective. A modern example is ActorRef under Akka frame, when the local reference sequence of conversion to a corresponding path, generated by the ActorProvider again depending on the particular environment in ActorSystem path from the distal end of the process. Passing references cited ineffectiveness is because usually, especially the address space associated with the local state. Associated with a local state, local object reference point at the distal end of the process is simply meaningless. This value should be passed first inspired us to information in network communications, but also illustrates the different additional work needs to be at the application level masking references. If the indiscriminate application of such work on local objects and remote objects, then the cost of access to local objects will be unnecessary parts.

Its ter, a partial failure (Partial Failure) is a problem that due to the distributed computing there is no single failure mechanism Explorer (in local environment, can be an operating system), the calculation of the failure is difficult to detect, identify and recovery. A typical scenario is that the process of requesting process B to perform an action, if process A process B received a reply, then it can be known action has been completed. But if the process does not receive a reply A process B, then process A is not know if this is because their information is not sent in the past, or failure of the implementation process B, or B to complete the process of feedback after missing the action. This problem is an objective reality, trying to conceal it, if at all considered local calls, the system will be stuck in the down part or failure occurs; if all considered to be part of a failure of remote calls occur, then for local call is still unavoidable overhead.

Four of which are concurrent (Concurrency) problems. Remote call distributed computing potential is concurrent, same, indiscriminate method calls to local and remote method invocation unified modeling, concurrency if ignored, then a remote method invocation may never return; if all assumed to be potential concurrency, the local method call will bring additional complexity.

In summary, the problem is not the performance degradation or failure of the program, but rather emphasize the need to address local computing and distributed computing on the model differences, to distinguish between different scenarios for an appropriate trade-offs and modeling for different needs.

On the second point, which talked about examples of Akka has also been very clear, also occurred in the same effort gRPC and other framework. For remote method invocation references failures, the most critical point is that the programmer needs to have knowledge of it. I'm working on FLINK-11603 when trying to start a local Gateway directly to a remote serialization, which is actually a bare sending behavior of ActorRef. Later, after the failure of learned references to the problem, instead of the value of the object transfer path name to re-establish a connection and get the Gateway based on the value at the far end.

On the third point, you can refer to the article "Nobody Needs Reliable Messaging" ( https://www.infoq.com/articles/no-reliable-messaging/ ). The long-distance calls [so] considered local calls correctness can lead to serious problems, first is the need to distinguish between local calls and long-distance calls. But for long-distance calls to what extent we choose to provide reliability, it is still worth exploring the issue.

On the fourth point, concurrency is how a new era of software developers are also issues around the past. IO operation of the local call may also be complicated by the need to reduce congestion, and even simple computing operations can be sent to different cores simultaneously to improve performance through parallel computing. Of course, for some simple concurrent calls do not exist, we do not need to be complicated by the introduction of context. This is still a requirement for software developers when it should have an accurate understanding of concurrency.

Guess you like

Origin www.cnblogs.com/tisonkun/p/10959151.html