In the course of software development, we are increasingly exposed to the concept of “distributive systems”。
However, many people are not familiar with their specific concepts, leading to confusion in learning。
Now that @knowledge has asked questions, we will use this paper to present the basic concepts of the distributed system and the problems it addresses and the problems it raises。
What is a distributed system
First, in academia, the definition of distributed systems is not uniform。
For example, some scholars define distributed systems as “a system where hardware or software components are distributed on a networked computer, where communication and action are coordinated between components by transmitting messages”; others define distributed systems as “a collection of independent computers, which are like individual related systems for users”。
It is clear that all of these definitions can cover distributed systems, but they are too broad and vague, far from the concept of distributed systems that is discussed daily by software developers。
In engineering, the concept of distributed systems is also vague。
For example, we would say that zookeeper is a distributed system and that micro-services are distributed systems. Clearly, the two types of systems differ considerably。
What about the distribution system? What are we talking about when we talk about distribution systems
In fact, we can start with the simplest single-body application system, divide it into a lot of small categories, and then give the boundaries of the distributed system. However, this will take a great deal of space. And here we will not divide, and we will come to conclusions。
So how do we define the distributed system in the project? The criteria are:
Whether the system uses several consistent information pools。
Here's an explanation of the concept:
If the system uses several consistent information pools, it is a distributed system; otherwise it is not。
It may be somewhat incomprehensible, but we are reassured that we will then help to understand this definition through examples。
It should also be clarified that, in the above definition, we do not need to care whether nodes are homogenous or heterogene. That is, the nodes in the distributed system can run exactly the same programs or different programs. This is not the key to distinguishing distributional systems。
Next, we give examples of satisfying and dissatisfied distribution systems that are common in the project。
1. 1 several examples of dissatisfaction
For example, sometimes we deploy nodes codes to multiple machines and then connect them to the same database to form nodes clusters. Such systems are described below。
This nodal cluster has the advantage of being simple and able to cope with some service nodes。
However, such systems are not distributive and can only be considered nodal clusters. Because it only exists in the only information pool. This is also the weakness of the information pool and the system。
For example, sometimes we allocate different service nodes to different users. Each node has an independent information pool that keeps the user's information. If the node fails, the user cannot be served。
The typical feature of this cluster is the complete isolation of the nodes. These nodes operate the same code, with the same configuration, but maintain context information for different users, each serving its own users。
Nor is it a distributed system, as the information pools are not consistent. When data on one node change, the other does not need to be accompanied by changes, and information on each node is independent。
So many of the systems that we usually say end with “clusters” are not necessarily distributed systems。
1. 2 several examples of satisfaction
As we said above, “zookeeper is a distributed system, and micro-services is a distributed system”. Yes, both are distributed systems。
The zookeeper cluster is a distributed system with identical programs and configurations for each node (leader, fololower, learner's role division is only an intermediate variable in the running of the program), so the nodes in zookeeper are homogenous nodes. Furthermore, each node maintains znode data using memory as an information pool, and data for each node changes when the data stored on zookeeper changes. Thus, the zookeeper cluster is a distributed system of homogenous nodes。
Electrician applications containing order services, inventory services and payment services are distributed systems. The system can also continue to be subdivided, if all services can only be combined as part of the application, which is a distributed application, and if each service can be provided either independently or jointly. But they are all distributed systems. The nodes in the distributed system may be heterogene (order service nodes and inventory service nodes have different codes, configurations, etc.)。
So systems like micro-services, which we usually call them, are generally distributed systems。
2 what is the problem with distributed systems
The configuration of distributed systems is not simple and involves a great deal of knowledge in the fields of theory, practice and engineering. However, it is still being used very widely because of its advantages。
2. 1 reducing application costs
The ability to reduce the cost of implementation of applications is the initial driver for the generation and development of distributed systems。
For monomer applications, the application requirements for hardware are gradually increasing as the application load function, carry-over and data volume are gradually increasing. At this time, only the hardware facilities for application can be upgraded, using computers with greater computing, storage and io capabilities, often referred to as large machines. However, the purchase and maintenance of large aircraft is costly。
The emergence of distributed systems allows for single-body applications to be split into small applications to be deployed on small server clusters to achieve high interactivity, large data and multifunctionality. This has significantly reduced the cost of implementation of applications。
2. 2 enhanced availability of applications
There is a risk of single-point failure in monomer applications. An anomaly in the operation of the application node means that the entire application is not available. The distribution system avoids this problem。
The distributed system is serviced externally by a large number of nodes, one of which is divided among the other nodes in case of failure. At the same time, applications can significantly increase their availability by adding or deleting nodes depending on the load situation during the operation。
2. 3 upgrading applications
Single-body applications have a limited capacity and number of simultaneous rounds, creating performance bottlenecks when the amount of data is excessive. Distributive systems can contribute to enhancing the performance of the entire application by sharing the volume pressure and co-pressure through numerous nodes。
2. 4 reduced development and maintenance difficulties
The monomer application combines numerous functional modules, which are called and woven together and form a large and complex whole. Upgrading of any functional module may affect other modules. This makes development and maintenance more difficult。
In the distributed system, all functional modules are separated and exist as stand-alone application nodes and are modularized. This reduces the connection between functional modules, so long as we maintain the original external interface of the application nodes, we can safely add new interfaces or optimize internal realization。
The realization of modularization also increases the likelihood of the module being reused. Moreover, the development of the modules can be undertaken in parallel, increasing their efficiency。
In the case of upgrade deployment, single-body applications require reissuance of the entire application, while distributed systems require only reissuance of modified modular applications, reducing the risk of failure in upgrade deployment and increasing the speed of application upgrade deployment。
3 problems with distributed systems
Of course, the implementation of distributed systems also faces many problems. Here are some very typical questions。
3. 1 coherence issues
The issue of distributive consistency is the most prominent one facing the distributive system。
In monomer applications, the application itself has only one node, and any external change request is dealt with directly by that node, with an updated result to be given。
In distributed systems, applications include multiple nodes. External requests for change will fall to any of the nodes of application, and then external requests for reading may fall to other nodes. In this way, an external result may be read prior to a change. That is, there is a disparity in reading and writing。
To avoid inconsistent reading and writing, distributed systems need to reflect changes in one node in a timely manner to all nodes, i. E., to achieve consistency in distributed systems. However, achieving consistency in distributed systems is a very complex process involving theory and practice, with minor inaccuracies affecting the performance of applications。
3. 2 node discovery
The monomer application has only one node and the address of this node is the service address of the entire application. The address where the services are provided is therefore static。
The distributed system contains numerous nodes, each of which can provide external services. Also, the application of nodes in clusters is subject to additions or deletions, which result in a pool of dynamic changes in the availability of services. This makes it necessary to design a mechanism to help callers find available nodes in distributed systems, i. E., to solve the problem of nodes。
3. 3 node call issues
Inter-module calls for monomer applications, which occur within the application, are high-frequency but are also low-cost and efficient。
There will also be calls between applications, often based on interfaces. Such transfers are relatively low-frequency and at the same time costly and inefficient。
There will also be calls between nodes within the distributed system. This call is based on the evolution of inter-module calls for monomer applications, which are relatively frequent. However, calls between them are no longer achievable through applied internal transfers, while interface-based calls are too costly and inefficient. This requires a relatively low-cost and efficient way to address the issue of nodal transfers, as shown in the figure below。
3. 4 node collaboration
All resources for a single application are mobilized by a single node and do not require collaboration. However, the situation is complicated in the distributed system。
For example, in a distributed system consisting of homogenous nodes, a task of periodic aggregation will only be performed by a single node of application. However, if no special mechanism is adopted, the nodes of the distributed system will operate at the same time as the assigned time, resulting in multiple aggregations。
Similar problems can be encountered in distributed systems consisting of heterogeneity nodes. For example, part of the nodes in distributed systems are producers and part of the nodes are consumers. Only two nodes work together to ensure that the process of production and consumption of applications is smooth。
Collaboration between the nodes of the distributed system is a problem faced by the distributed system。
