Load balancing analysis and solutions for PHP development_PHP tutorial

In the past, running a large web application meant running a large web server. Because your application attracts a large number of users, you will have to add more memory and processors to your server.

Today, the 'large server' model is gone, replaced by a large number of small servers using a variety of load balancing technologies. This is a more feasible approach that will keep hardware costs to a minimum.

The advantages of 'more small servers' over the past 'large server' model are reflected in two aspects:

　1. If the server goes down, the load balancing system will stop requesting the downed server and instead distribute the load to other normally running servers.

　2. Scaling your server is easier. All you have to do is add new servers to the load balancing system. No need to interrupt your application.

So, take advantage of this opportunity :). Of course, the price is that it requires a little more complexity in your application development. That’s what this article is going to cover.

At this point you may be saying to yourself: 'But how do I know I'm using load balancing?'. The most honest answer, if you're asking this question, is that you're probably not using a load balancing system and your system doesn't need to consider it. In most cases, when the application grows large enough, load balancing needs to be explicitly proposed and set up. However, I occasionally see web hosting companies doing this load balancing for customer applications, or doing it themselves as described below.

Before continuing below, I would like to point out that this article mainly describes PHP load balancing. I may write about data load balancing in the future, but for now you'll have to wait.

Note that I keep mentioning "web applications" instead of websites. This is to distinguish that 'web applications' are complex sites that often involve server-side programming and databases, rather than websites that only display simple static content.

　1. PHP file

The first question is, if you have a large number of small servers, how do you upload your php files to all servers? There are the following methods for your reference:

1. Upload all files to each server separately. The problem with this method is: imagine that you have 20 servers, then this will easily lead to errors during the upload process, and it is very likely to cause errors during the update. There are different versions of the files on different servers.

　2. Use 'rsync' (or similar software). Such a tool can synchronize files on a local directory and directories on multiple remote hosts.

　3. Use version control software (such as subversion). This is my favorite method. It allows me to maintain my code very well, and when I publish my application, I can run the svn update command on each server to synchronize it. This approach also makes it easier to switch servers to a previous version of the code.

4. Use a file server (you may find that NFS is very suitable for this). This method is to use a file server to store your web application. Of course, if your file server goes down, so all Your site will be unavailable. At this time, you will need to spend more money to restore it.

Which method you choose depends on your needs and the skills you have. If you use a version control system, then you may want to plan a way to update the code on all servers by executing an update command at the same time. However, if you use a file server, you will need to implement some failure recovery mechanism to prevent request failures in the event that the server goes down.

　2. File upload

File uploading is not a problem when there is only one server. But when we have multiple servers, how should the uploaded files be stored? The problem of uploading files is similar to cross-server PHP file storage. Here are several possible solutions:

　1. Store the file in the database. Most data allow binary data to be stored. When you request a file download, access data outputs the binary data and the corresponding file name and type to the user. You should consider how the database will store your files before using this solution. The problem with this approach is that if the database server goes down it will make the files unavailable.

2. Store uploaded files on a file server. As in the previous introduction, you need to install a file server to share with all web servers, and upload all uploaded files here. After uploading, all web servers will Can use it. However, if the file server is down, then image file download interruptions may occur.

3. Design your own upload mechanism to transfer files to each server. This method does not have the disadvantages of a single file server or database solution, but will increase the complexity of your code. For example, if the server goes down while uploading to multiple servers, what should you do?

Using a database to store uploaded files but designing a file caching mechanism is a good solution. When the server receives a file download request, it first checks whether the file exists in the cache system. If found, it downloads it from the cache system. Otherwise, it reads it from the database and caches it in the file system.

　3. Sessions

If you are familiar with PHP’s session processing, you will probably know that by default, it stores session data in temporary files on the server. Moreover, this file is only on the server where you requested it, but subsequent requests may be processed by another server, which will generate a new session on the other server. This causes sessions to be frequently unrecognized, such as logged-in users always being asked to log in again.

My recommended solution is to either re-establish PHP's built-in session processing mechanism to store session data in the database, or implement your own mechanism to ensure that a user's request is sent to the same server.

　4. Configuration

Although this topic is not particularly related to PHP, I feel it is still necessary to mention it. When running clustered servers, it is a good idea to have some way of keeping configuration files in sync between servers. If the configuration files are inconsistent, it can result in some very strange intermittent behavior that can be difficult to troubleshoot.

I recommend using a version control system to manage them individually. This way you can store different php configuration files for different project installations, and also keep all server configuration files in sync.

　5. Logging

Like configuration issues, logging is not just related to PHP. But it's still very important to keep your server running healthy. Without a proper logging system, how would you know if your PHP code starts generating errors (you always turn off the display_errors setting when the system is live, don't you?)

There are several ways you can implement logging:

　1. Record logs on each server. This is the simplest way. Each machine records only one file. The advantage is that it is simple and may require very little configuration. However, as the number of servers increases, monitoring the log files on each server becomes very difficult.

　2. Log to a share This method still has the log files on each server, but they are stored on a central file server through the sharing mechanism, which will make monitoring the logs easier. The problem with this solution is that if the file server is unavailable, a simple log write problem will eventually cause the entire application to crash.

　3. Record logs to a logging server. You can use a logging software, such as syslog, to write all logs to a central server. Although this method requires more configuration, it also provides the most robust solution.