PHP development load balancing guide
- 2020-03-31 20:56:59
- OfStack
Today, the 'large server' model has been replaced by a large number of small servers, using a variety of load balancing techniques. This is a more viable approach that will minimize hardware costs.
The advantages of 'more small servers' over the past' large servers' model are reflected in two aspects:
1. If the server goes down, the load balancing system will stop the requests to the down server and distribute the load to other servers that are running normally.
Scaling your server is easier. All you have to do is add a new server to the load balancing system. There is no need to interrupt your application.
So, seize the opportunity :). The trade-off, of course, is that it requires a little more complexity in your application development. That's what this article covers.
You might say to yourself, 'but how do I know I'm using load balancing? '. The honest answer is, if you're asking this question, the answer is that you're probably not using a load balancing system and your system doesn't need to think about it. In most cases, as the application grows large enough, load balancing needs to be explicitly addressed and set up. However, I have occasionally seen web hosting companies do this load balancing for client applications, or do it themselves as described below.
Before moving on, I want to point out that this article mainly describes load balancing for PHP. In the future I might write about data load balancing, but for now you have to wait.
Note that I keep referring to "web applications" instead of websites, to distinguish between "web applications" that are complex sites that tend to involve server-side programming and databases, rather than simply displaying static content.
1. The PHP file
The first question is, if you have a large number of small servers, how do you upload your PHP files to all the servers? There are the following methods for your reference:
1. Upload all the files to each server separately. The problem with this approach is: imagine that you have 20 servers.
2. Use 'rsync '(or similar software). Such a tool can synchronize files on local directories and multiple remote host directories.
Use version control software (such as subversion). This is my favorite method. It is a good way to maintain my code, and when I publish my application, I can run the SVN update command synchronization on each server. This approach also makes it easier to switch server code to a previous version.
4. Use a file server (you may find NFS a great way to do this). This way is to use a file server to host your web applications. At this point, you need to spend more money to restore it.
The choice depends on your needs and the skills you have. If you use a version control system, you may have to plan a way to update all the code on the server by executing an update command at the same time. However, if you use a file server, you need to implement some fail-recovery mechanisms in case the server goes down and the request fails.
2. File upload
When there is only one server, file uploading is not a problem. But when we have multiple servers, how do we store the uploaded files? The problem of uploading files is similar to that of cross-server PHP file storage. Here are a few possible options:
Store files in a database. Most data allow binary data to be stored. When you request a file download, the access data outputs the binary data and the corresponding file name and type to the user. Think about how the database stores your files before using this solution. The problem with this approach is that if the database server goes down, the file becomes unavailable.
2. Store the uploaded files on a file server. As mentioned above, you need to install a file server for all web servers to share. However, if the file server goes down, an image file download outage can occur.
3. Design your own upload mechanism to transfer files to each server. This method does not have the drawbacks of a single file server or database solution, but it will increase the complexity of your code. For example, if you upload to multiple servers and the server goes down, what do you do?
Upload files are stored in a database but designing a file caching mechanism is a good idea. When the server receives a file download request, it first checks to see if the file is in the cache system, and if so, downloads it from the cache system, otherwise reads it from the database and caches it into the file system.
3. The session (Sessions)
If you're familiar with PHP's session handling, you'll probably know that by default it stores session data in a temporary file on the server. Furthermore, the file is only on the server on which your request was processed, but subsequent requests may be processed by another server, which generates a new session on the other server. This results in sessions not being recognized frequently, such as logged in users always asking to log back in.
I recommend either revisiting PHP's built-in session handling mechanism to store session data to a database, or implementing your own mechanism to ensure that a user's request is sent to the same server.
4. The Configuration (Configuration)
Although this topic is not particularly related to PHP, I feel the need to mention it. When running a cluster server, it's a good idea to somehow keep configuration files synchronized between the servers. If the configuration files are inconsistent, it can lead to some very strange intermittent behavior that makes it difficult to troubleshoot these problems.
I recommend using a version control system to manage them separately. This allows you to store different PHP configuration files for different project installations and keep all server configuration files in sync.
5. Log (Logging)
Like configuration issues, logging is not just about PHP. But it's still important to keep the server healthy. Without a proper logging system, how do you know if your PHP code starts to make errors (you always turn off the display_errors setting when the system is running, right?)?
There are several ways you can implement logging:
Log on each server. That's the easiest way to do it. Each machine records only one file. The benefit is simplicity, perhaps with very little configuration. However, as the number of servers increases, it becomes difficult to monitor the log files on each server.
Log to a share this way every server still has this log file, but they are stored on a central file server through the sharing mechanism, which makes it easier to monitor the log. The problem with this scenario is that if the file server is unavailable it will cause a simple log to fail to write and eventually cause the entire application to crash.
You can use a logging tool such as syslog to write all logs to a central server. Although this approach requires more configuration, it also provides the most robust solution.
The advantages of 'more small servers' over the past' large servers' model are reflected in two aspects:
1. If the server goes down, the load balancing system will stop the requests to the down server and distribute the load to other servers that are running normally.
Scaling your server is easier. All you have to do is add a new server to the load balancing system. There is no need to interrupt your application.
So, seize the opportunity :). The trade-off, of course, is that it requires a little more complexity in your application development. That's what this article covers.
You might say to yourself, 'but how do I know I'm using load balancing? '. The honest answer is, if you're asking this question, the answer is that you're probably not using a load balancing system and your system doesn't need to think about it. In most cases, as the application grows large enough, load balancing needs to be explicitly addressed and set up. However, I have occasionally seen web hosting companies do this load balancing for client applications, or do it themselves as described below.
Before moving on, I want to point out that this article mainly describes load balancing for PHP. In the future I might write about data load balancing, but for now you have to wait.
Note that I keep referring to "web applications" instead of websites, to distinguish between "web applications" that are complex sites that tend to involve server-side programming and databases, rather than simply displaying static content.
1. The PHP file
The first question is, if you have a large number of small servers, how do you upload your PHP files to all the servers? There are the following methods for your reference:
1. Upload all the files to each server separately. The problem with this approach is: imagine that you have 20 servers.
2. Use 'rsync '(or similar software). Such a tool can synchronize files on local directories and multiple remote host directories.
Use version control software (such as subversion). This is my favorite method. It is a good way to maintain my code, and when I publish my application, I can run the SVN update command synchronization on each server. This approach also makes it easier to switch server code to a previous version.
4. Use a file server (you may find NFS a great way to do this). This way is to use a file server to host your web applications. At this point, you need to spend more money to restore it.
The choice depends on your needs and the skills you have. If you use a version control system, you may have to plan a way to update all the code on the server by executing an update command at the same time. However, if you use a file server, you need to implement some fail-recovery mechanisms in case the server goes down and the request fails.
2. File upload
When there is only one server, file uploading is not a problem. But when we have multiple servers, how do we store the uploaded files? The problem of uploading files is similar to that of cross-server PHP file storage. Here are a few possible options:
Store files in a database. Most data allow binary data to be stored. When you request a file download, the access data outputs the binary data and the corresponding file name and type to the user. Think about how the database stores your files before using this solution. The problem with this approach is that if the database server goes down, the file becomes unavailable.
2. Store the uploaded files on a file server. As mentioned above, you need to install a file server for all web servers to share. However, if the file server goes down, an image file download outage can occur.
3. Design your own upload mechanism to transfer files to each server. This method does not have the drawbacks of a single file server or database solution, but it will increase the complexity of your code. For example, if you upload to multiple servers and the server goes down, what do you do?
Upload files are stored in a database but designing a file caching mechanism is a good idea. When the server receives a file download request, it first checks to see if the file is in the cache system, and if so, downloads it from the cache system, otherwise reads it from the database and caches it into the file system.
3. The session (Sessions)
If you're familiar with PHP's session handling, you'll probably know that by default it stores session data in a temporary file on the server. Furthermore, the file is only on the server on which your request was processed, but subsequent requests may be processed by another server, which generates a new session on the other server. This results in sessions not being recognized frequently, such as logged in users always asking to log back in.
I recommend either revisiting PHP's built-in session handling mechanism to store session data to a database, or implementing your own mechanism to ensure that a user's request is sent to the same server.
4. The Configuration (Configuration)
Although this topic is not particularly related to PHP, I feel the need to mention it. When running a cluster server, it's a good idea to somehow keep configuration files synchronized between the servers. If the configuration files are inconsistent, it can lead to some very strange intermittent behavior that makes it difficult to troubleshoot these problems.
I recommend using a version control system to manage them separately. This allows you to store different PHP configuration files for different project installations and keep all server configuration files in sync.
5. Log (Logging)
Like configuration issues, logging is not just about PHP. But it's still important to keep the server healthy. Without a proper logging system, how do you know if your PHP code starts to make errors (you always turn off the display_errors setting when the system is running, right?)?
There are several ways you can implement logging:
Log on each server. That's the easiest way to do it. Each machine records only one file. The benefit is simplicity, perhaps with very little configuration. However, as the number of servers increases, it becomes difficult to monitor the log files on each server.
Log to a share this way every server still has this log file, but they are stored on a central file server through the sharing mechanism, which makes it easier to monitor the log. The problem with this scenario is that if the file server is unavailable it will cause a simple log to fail to write and eventually cause the entire application to crash.
You can use a logging tool such as syslog to write all logs to a central server. Although this approach requires more configuration, it also provides the most robust solution.