In the past, when running a large web application, it was necessary to run 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 has passed, replacing it with a large number of small servers, using a variety of load balancing technologies.
In the past, when running a large web application, it was necessary to run 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 has passed, replacing it with a large number of small servers, using a variety of load balancing technologies. The advantages of "more small servers" over the "large servers" pattern in the past are embodied in two aspects: 1. if the server goes down, the server load balancer system stops requests to the server that goes down and distributes the load to other normal servers. 2. it is easier to expand your server. All you have to do is add a new server to the server load balancer system. You do not need to interrupt the running of your application. Therefore, seize this opportunity. Of course, the cost is that this requires a little more complexity during application development. This is the content to be covered in this article. Then you may say to yourself, "but how do I know I am using server load balancer ?". The most honest answer is that if you are asking this question, most of you are not using the server load balancer system and your system does not need to consider this question. In most cases, server load balancer needs to be explicitly proposed and set up when the application grows to a large enough scale. However, I also occasionally see virtual host companies doing load balancing for their applications, or as described below. Note: I have always mentioned "web applications" instead of "website". this is to distinguish "web applications" from complicated websites that often involve server-side programming and databases, instead of displaying simple static content like website. 1. The first problem with PHP files is that 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: ◆ upload all files to each server separately. The problem is: Imagine that you have 20 servers, during the upload process, this will easily lead to errors, and updating will most likely lead to different versions of files on different servers. ◆ Use 'rsync' (or similar software). This tool can synchronize files in the local directory and multiple remote host directories. ◆ Use version control software (such as subversion). This is my favorite method. It can well maintain my code. when I publish my application, I can run svn update command synchronization on every server. This method also makes it easier to switch the server code to a previous version. ◆ Use a file server (you may find NFS is very suitable for doing this ). this method uses a file server to store your web applications. of course, if your file server goes down, so many of your sites will not be available. In this case, you need to spend more money to recover it. The method you choose depends on your needs and skills. If you use a version control system, you may have to plan a method if you execute an update command to update the code on all servers at the same time. However, if you use a file server, you need to implement some failure recovery mechanisms to prevent requests from failing in case of server downtime. 2. when there is only one server for file upload, file upload is not a problem. But when we have multiple servers, how should we store the uploaded files? The problem of file uploading is similar to that of cross-server PHP file storage. The following are several possible solutions: ◆ store files in the database. Most data can be stored in binary data. When you request a file to be downloaded, the access data outputs the binary data and the corresponding file name and type to the user. Before using this solution, you should consider how the database stores your files. The problem with this method is that if the database server goes down, the file will be unavailable. ◆ Store uploaded files on a file server. as described above, you need to install a file server to share all web servers, upload all uploaded files here, and all uploaded web servers can use it. However, if the file server goes down, the image file download may be interrupted. ◆ Design your own Upload mechanism to transfer files to every server. this method does not have any defect in a single file server or database solution, but will increase the complexity of your code. For example, if the server goes down while uploading data to multiple servers, what should you do? It is a good solution to store and upload files in a database but design a File Cache mechanism. When the server receives a file download request, it first checks whether the file exists in the cache system. If yes, it downloads the file from the cache system. Otherwise, it reads the file from the database and caches it to the file system. 3. session (Sessions) if you are familiar with php session processing, you may know that by default, session data is stored in a temporary file on the server. In addition, this file is only on the server where your request is processed, but the next request may be processed by another server, which will generate a new session on the other server. As a result, the session is frequently not identified. for example, a logon user always needs to log on again. The recommended solution is to either re-store session data to the database through the php built-in session processing mechanism, or implement your own mechanism to ensure that one user's request is sent to the same server. 4. Configuration although this topic is not particularly related to php, I feel it is necessary to mention it. When running a cluster server, it is a good idea to use some method to synchronize configuration files between servers. If the configuration files are inconsistent, it may lead to some very strange intermittent behavior, which makes it difficult to troubleshoot these problems. I recommend that you use the version control system to manage them separately. In this way, you can install and store different php configuration files for different projects, or synchronize all server configuration files. 5. As with configuration problems, Logging is not only related to php. But it is still very important to keep the server healthy. Without the correct logging system, how do you know that if PHP code starts to generate errors (you always disable display_errors settings when the system is running, aren't you ?) There are several ways to implement logging: 1. log on each server. This is the simplest method. Each machine records only one file. The advantage is that it is simple and may only require few configurations. However, as the number of servers increases, it is very difficult to monitor log files on each server. 2. record logs to a shared method. every server still has this log file, but they are stored on a central file server through the sharing mechanism, which makes monitoring logs easier. The problem with this solution is that if the file server is unavailable, a simple log cannot be written and the entire application crashes. 3. log recording to the logging server you can use a logging software, such as syslog, to write all the logs to a central server. Although this method requires more configurations, it also provides the most robust solution.
