Original author: Adam Charnock
Original link: The Hitchhikers Guide to PHP Load Balancing
Translation: Koda
used to mean running a large web server when running a large web application. Because your application attracts a large number of users, you will have to add more memory and processors to your server.
Today, the 'big server' model is gone, replaced by a large number of small servers, using a variety of load balancing techniques. This is a more feasible approach that will keep hardware costs to a minimum.
The advantage of 'more small servers' over the past 'large server' model is reflected in two aspects:
if the server goes down, the load balancing system will stop making requests to the downed server and instead distribute the load to other normally running servers. superior.
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 :). The trade-off, of course, 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 load balancing in PHP. 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" rather than 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 files The first question is, if you have a large number of small servers, how do you upload your php files to all servers? There is the following method for your reference:
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 the update time will be very fast. It is possible to have different versions of files on different servers.
Use 'rsync' (or similar software). Such a tool can synchronize files on a local directory and directories on multiple remote hosts.
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.
Use a file server (you may find that NFS is great for this). This approach is to use a file server to host your web application. Of course, if your file server goes down, all of your sites will be unavailable. use. 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 When there is only one server, file upload is not a problem. 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:
Store the file in a 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.
Store uploaded files on a file server. As in the previous introduction, you need to install a file server to be shared by all web servers. Upload all uploaded files here. After uploading, all web servers can use it. However, if the file server is down, image file download interruptions may occur.
Design your own upload mechanism to transfer files to each server. This approach does not have the drawbacks of a single file server or database solution, but will increase the complexity of your code. For example, if the server goes down during uploading to multiple servers, what will 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 handling, 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 specifically related to PHP, I feel it is 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 managing them individually using a version control system. 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 a few ways you can implement logging:
Log on every server. This is the easiest 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.
Logging to a share This approach still has the log files on each server, but they are stored on a central file server via the share mechanism, which makes 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.
Logging 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.
phpv added: Another important point is database management, which may involve a lot of content. Therefore, the author did not write it out.