The definition that is easiest to understand from the author is several processes that run concurrently, each of which is part of a series of process stages that are related to each other.
The analogy is like this: imagine a process flow for routine database autobackups, where there are many databases to be backed up. For the backup itself we use the go program, not a shell script. Perhaps in outline a series of process stages that will be carried out are as follows.
A. Perform a dump operation on the database, the output is in the form of many files saved to a folder.
B. The dump files are then archived in .zip or .tar .gz format (for example)
C. The archive file is sent to a backup server for example AWS S3.
If you pay attention to the case above, it might be better in terms of performance if the backup process for many databases is done in parallel. and to this the author agrees.
And it would be even better if the processes for each database backup process, A, B and C, were run concurrently, by making the three processes (A, B, C) a concurrent process, then the I/O would be more efficient. Later, between processes A, B and C, the execution will remain sequential (because it must run sequentially. It is not permissible if, for example, B is executed first and then A); However, the goroutine which will be responsible for the execution of process A is complete. we can continue with execution B (which is the next stage of process A) plus execution of other processes (another database); in parallel. So the goroutine that handles A doesn't become idle.
Please pay attention to the following visualization. The column is a representation of goroutines that run simultaneously. But because the three goroutines are a series of processes, the processes are always sequential, while the rows represent a sequence.
In Go, generally the process in the form of a goroutine that is executed is concurrent, but in flow it must be sequential, it is called a pipeline, so for the moment let's just assume that pipeline A is a goroutine for process A, pipeline B is goroutine B and so on.
To make it easier to understand the table, please follow the sequential explanation:
In this example we assume that pipeline A has only one goroutine, pipeline B also has one goroutine, and so does pipeline C. But actually in real world implementation there can be many goroutines for each pipeline (many goroutines for pipeline A, many goroutines for pipeline B , many goroutines for pipeline C).
I hope that my writing can explain. Even if it is not clear, the internet is open with LAN sources.
The above is the detailed content of Pipeline Concept. For more information, please follow other related articles on the PHP Chinese website!