The current trend in website development is to use different load balancing technologies at different stages as the site scales up:
One approach is hardware-based, using expensive commercial load balancers like NetScaler, F5, Radware, and Array. The advantage is having a professional maintenance team to manage these services, but the downside is the high cost, making it unnecessary for smaller-scale web services for now. The other approach is using open-source, free, Linux-based software load balancing strategies like LVS, HAProxy, and Nginx. These operate at the software level, so costs are very low. I personally recommend adopting the second approach to meet your website’s load balancing needs.
Recently, my friend Liu Xin’s (Ziyuhe Xue) project successfully launched, achieving hundreds of millions of daily PVs. The front end uses a dual-machine HAProxy+Keepalived setup as the load balancer/reverse proxy, and the entire website runs very smoothly. This reinforced my belief in the sensible architecture design I once discussed with senior expert Old Boy: using Nginx/HAProxy+Keepalived as the front-end load balancer for the web tier, with a back-end MySQL database architecture featuring one master with multiple slaves for read-write splitting, managed through LVS+Keepalived.
I want to clarify something here: many friends worry about the stability of software-level load balancing under high-concurrency traffic. In reality, we’ve found through many successfully launched websites that their stability is excellent, with negligible chances of downtime. So for my current projects, I hardly consider high availability at the service level anymore. I believe everyone has gained a deep understanding of these software-level load balancers. Below, I will explain their characteristics and applicable scenarios separately.
LVS: Uses cluster technology and the Linux operating system to create a high-performance, high-availability server. It offers excellent scalability, reliability, and manageability. Thanks to Dr. Zhang Wensong for providing such a powerful and practical open-source tool.
Characteristics of LVS:
1. Strong load resistance; it operates at Layer 4 of the network and only handles distribution, generating no traffic itself. This trait ensures it delivers the best performance among load balancing software.
2. Low configurability, which is both a drawback and an advantage. Since there isn’t much to configure, it requires less hands-on management, significantly reducing the chance of human error.
3. Stable operation with built-in complete dual-machine hot-standby solutions, such as LVS+Keepalived and LVS+Heartbeat. However, in our project implementations, we most commonly use LVS/DR+Keepalived.
4. No traffic generation, ensuring that the balancer’s IO performance is not affected by large traffic volumes.
5. Broad application range; it can perform load balancing for all types of applications.
6. The software itself does not support regex processing, so it cannot separate dynamic and static content. This is a notable regret. Many websites today have strong demands in this area, which is where Nginx/HAProxy+Keepalived have an advantage.
7. If the website application is quite large, implementing LVS/DR+Keepalived can become complex, especially if there are Windows Server machines involved. The implementation, configuration, and maintenance processes can get complicated; comparatively, Nginx/HAProxy+Keepalived is much simpler.
Characteristics of Nginx:
1. Works at Layer 7 of the network, allowing it to implement HTTP application-specific traffic distribution strategies, such as those based on domain names or directory structures. Its regex rules are more powerful and flexible than HAProxy’s, which is one reason many users prefer it.
2. Nginx has very low dependency on the network. Theoretically, if you can ping a server, you can load balance it, which is another advantage.
3. Nginx installation and configuration are relatively simple, making it easy to test.
4. It can also handle high load pressures stably, generally supporting tens of thousands of concurrent connections.
5. Nginx can detect backend server failures via port monitoring, such as checking the status codes of processed web pages or timeouts, and it will resubmit failed requests to another node. However, a drawback is it does not support detection based on URLs.
6. Nginx only supports HTTP and Email protocols, which limits its application scope compared to others; this is a weakness.
7. Nginx is not just an excellent load balancer/reverse proxy; it is also a powerful web application server. The LNMP stack is now a very popular web architecture, challenging the previously dominant LAMP stack, and it performs well in high-traffic environments.
8. Nginx is increasingly mature as a web reverse acceleration cache. Many people are already using it in production environments and reporting good results, with speeds faster than traditional Squid servers. Those interested might consider using it as a reverse proxy accelerator.
Characteristics of HAProxy:
1. HAProxy supports virtual hosts. Some previously claimed it did not, so I am correcting that here.
2. It can complement some of Nginx’s weaknesses, such as session persistence and cookie steering.
3. Its support for URL-based detection is very helpful for troubleshooting backend server issues.
4. Like LVS, it is purely a load balancing software. In terms of pure efficiency, HAProxy offers faster load balancing speeds than Nginx and also outperforms Nginx in concurrent handling.
5. HAProxy can load balance MySQL reads, performing health checks and load distribution for backend MySQL nodes. However, when the number of backend MySQL slaves exceeds 10, its performance is not as good as LVS, which is why I recommend LVS+Keepalived for that scenario.
6. HAProxy’s scheduling algorithms are now increasingly diverse, specifically the following 8 types:
鈶?roundrobin, meaning simple round-robin, basic and common to most load balancers;
鈶?static-rr, weight-based round-robin, recommended for attention;
鈶?leastconn, prioritizes the server with the fewest connections, recommended for attention;
鈶?source, hashes based on the request source IP, similar to Nginx’s IP_hash mechanism