In the past, when running a large Web application, it 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 has been replaced by a large number of small servers, using a variety of load balancing techniques. This is a more feasible approach that minimizes the cost of hardware. The advantages of ' more small servers ' outweigh the past ' large server ' patterns in two ways:
If the server goes down, the load-balancing system stops requests to the server that is down and distributes the load to other healthy servers.
It's much easier to extend your server. All you have to do is add the new server to the load balancer system. No need to interrupt your app to run.
So, take this opportunity:). The price, of course, is to add a bit of complexity to your application development. This is what the article will cover.
Then you might say to yourself, ' but how do I know I'm using load balancing? ' The most honest answer is that 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, when the application grows large enough, load balancing needs to be explicitly presented and set up. However, I also occasionally see a virtual hosting company doing this load balancing for customers ' applications, or doing it themselves as described below.
Before proceeding with the following, I would like to point out that this article mainly describes load balancing for PHP. In the future I might write text about data load balancing, but now you have to wait.
Note that I've been mentioning "web apps" instead of website, which is to differentiate ' web apps ' that are complex sites that tend to involve server-side programming and databases, rather than website just showing 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 the servers? Here's how you can refer to the following:
Upload all the files to each server separately, this method brings the problem is: Imagine you have 20 servers, then the upload process this will easily lead to errors, and the update is very likely to lead to different versions of the file on the server.
Use ' rsync ' (or similar software). Such a tool can synchronize files on the local directory and on multiple remote host directories.
Use version control software (such as subversion). This is my favorite method. It's good to maintain my code, and when I publish my app, I can run the SVN Update command synchronization on every server. This approach also makes it easier to switch the server to a previous version of the Code.
Use a file server (you may find NFS very well suited to do this thing). This is the way to use a file server to store your Web app. Of course, if your file server goes down, then more of all your sites will not be available. At this point, you need to spend more money to recover it.
Choose which method depends on your needs and the skills you have mastered. If you use a version control system, you may have to plan a method to update the code on all servers if you execute an update command at the same time. However, if you are using a file server, you will implement some failure recovery mechanisms to prevent requests from failing in the event of server downtime.
2. File Upload
File uploads are not an issue when there is only one server. But when we have more than one server, how should the uploaded files be stored? The issue of uploading files is similar to the file store for PHP files across servers. Here are a few possible scenarios:
Store the files in the database. Most data allows for the storage of binary data. When you request a file download, the Access data outputs the binary data and the corresponding file name and type to the user. Before using this scenario, you should consider how the database stores your files. The problem with this approach is that if the database server goes down it will make the file unusable.
Store uploaded files on a file server. As with the previous introduction, you will install a file server for all Web servers to share, upload all uploaded files here, upload all the Web server can use it. However, if the file server goes down, an image file download may be interrupted.
Design your own upload mechanism to transfer files to the server to each server. This method does not have a single file server or database schema flaw, but will increase the complexity of your code. For example, what do you do if the server goes down while uploading to multiple servers?
Uploading files with database storage but designing a file caching mechanism is a good solution. When the server receives a file download request, it first checks to see if the file is in the cache system, and if it is found to be downloaded from the cache system, it is read from the database and cached to the file system.
3. Session (Sessions)
If you are familiar with PHP session processing, you will probably know by default that it stores session data in the server's temp file. Also, this file is only on the server you requested to process, but the next request may be processed by another server, which will generate a new session on the other server. This causes the session to be frequently unrecognized, such as the logged-on user always requires a re-login. My recommendation is to either re-create PHP's built-in session processing mechanism to store session data to the database, or implement your own mechanism to ensure that a user's request is sent to the same server.
4. Configuration (config)
Although this topic is not specifically related to PHP, I feel it is necessary to mention. When running a clustered server, it is a good idea to keep profile synchronization between servers in some way. If the configuration file is inconsistent, it can cause some very strange intermittent behavior that makes it difficult to troubleshoot these issues.
I recommend using the version control system to manage them separately. This allows you to store different PHP configuration files for different project installations, or to keep all server configuration files synchronized.
5. Log (Logging)
Like configuration problems, logging is not just about PHP. But it is still very important to keep the server running healthily. Without the right logging system, how do you know if PHP code starts to generate errors (you always turn off the display_errors setting when the system is officially running, don't you?)
There are several ways you can implement logging:
Logs are logged on each server. This is the simplest method. Each machine only records one file. The benefits are simple, possibly as long as there are few configurations. However, as the number of servers increases, it becomes very difficult to monitor log files on each server. Material
Log logs to a shared this method each server still has this log file, but they are stored on a central file server through the sharing mechanism, which makes the monitoring log easier. The problem with this scenario is that if the file server is unavailable, a simple log cannot be written to the problem that eventually causes the entire application to crash.
Logging to logging server you can use a logging software, such as a syslog, to write all the logs to a central server. Although this method requires more configuration, he also provides the most robust solution.
http://www.bkjia.com/PHPjc/371488.html www.bkjia.com true http://www.bkjia.com/PHPjc/371488.html techarticle in the past, when running a large Web application, it meant running a large Web server. Because your application attracts a large number of users, you will have to add more in your server ...
