Shulou(Shulou.com)06/03 Report--

This article mainly introduces "detailed explanation of nginx load balancing". In daily operation, I believe many people have doubts about the detailed explanation of nginx load balancing. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts of "detailed explanation of nginx load balancing"! Next, please follow the editor to study!

Core function

In the brief definition above, we can roughly see two things: the distribution of requests, the operation unit; in fact, the controller + actuator mode, Master+Worker mode, and so on, are you familiar with? of course, a mature load balancer has not only these two core functions, but also some other functions. Let's take a look at the core functions:

Operation unit configuration the operation unit here is actually the upstream server, which is really the executor of the business, which needs to be configurable (preferably to support dynamic configuration) to facilitate users to add and delete operation units; these operation units are the objects that the load balancer distributes messages.

Since the load balancing algorithm needs to be distributed, how to distribute the message to the configured executor requires relevant distribution algorithms, such as our common polling, random, consistent hash, and so on.

Failure retry since multiple execution units are configured, the downtime of a server is a high probability event, so when we distribute the request to a server that is already down, we need to have the function of failure retry to redistribute the request to the normal executor.

The failed retry in the health check is to know that the server is down only when it is actually forwarded, which is a lazy strategy. Health check is to eliminate the machine that is down in advance, such as checking whether the executor is still alive by heartbeat.

With the above core functions, a load balancer is roughly formed. These principles can be used in many places to form different middleware or embedded in various middleware, such as LVS,F5,Nginx in the access layer, various RPC frameworks in the service layer, message queues RocketMQ, Kafka, distributed cache Redis, memcached, database middleware shardingsphere, mycat, and so on. This divide-and-conquer idea is widely used in all kinds of middleware. Here is an analysis of how some common middleware do load balancing. Generally speaking, they can be divided into stateless and stateless types.

Stateless

The execution unit itself has no state, in fact, it is easier to do load balancing. Every execution unit is the same. Common stateless middleware include Nginx,RPC framework, distributed scheduling and so on.

Access layer

Nginx can be said to be our most common access layer middleware, providing four to seven layers of load balancing, high-performance forwarding, and support for the above core functions.

Operation unit configuration Nginx provides a simple static operation unit configuration, as follows:

Upstream tomcatTest {server 127.0.0.1 tomcat-8081 server 8081; # tomcat-8082} location / {proxy_pass http://tomcatTest;}

The above configuration is static. If you need to add or delete it, you need to restart Nginx, which is very inconvenient. Of course, it also provides dynamic unit configuration, which requires the help of a third-party service registry, such as Consul,etcd. The principle is roughly as follows:

When the operation unit starts, it will be registered in the Consul, and the same downtime will be removed from the Consul; the Nginx side will start a Consul-template listener to listen for changes to the operation unit on the Consul, and then update the upstream of the Nginx, preferably reloading the upstream.

Common load balancing algorithms such as: ip_hash,round-robin,hash; configuration is also very simple:

Upstream tomcatTest {ip_hash / / according to ip load balancer, that is, ip binds server 127.0.0.1 server 8081; # tomcat-8081 server 127.0.0.1 ip 8082; # tomcat-8082}

Failed to retry

Upstream tomcatTest {server 127.0.0.1:8081 max_fails=2 fail_timeout=20s;} location / {proxy_pass http://tomcatTest; proxy_next_upstream error timeout http_500;}

When there are max_fails failures in fail_timeout, the execution unit is not available. Through proxy_next_upstream configuration, when a configuration error occurs, the next execution unit will be retried.

Health check Nginx performs health check by integrating nginx_upstream_check_module module; supports TCP heartbeat and Http heartbeat detection

Upstream tomcatTest {server 127.0.0.1 virtual 8081; check interval=3000 rise=2 fall=5 timeout=5000 type=tcp;}

Interval: detection interval; rise: after how many times the test is successful, the operation unit is identified as available; fall: after how many times the test fails, the operation unit is identified as unavailable; timeout: detection request timeout; type: detection type includes tcp,http

Service layer

The main service layer is the micro-service framework such as Dubbo,Spring Cloud, which integrates the load balancing strategy and is very convenient to use.

The operation unit configuration RPC framework generally depends on the registry components, in fact, it is the same as Nginx to dynamically change the operation unit through the registry. The RPC framework already depends on the registry by default. When the service starts, the service is registered to the center, the service is not available, it is removed, and it is automatically synchronized to the consumer side. The user is completely unaware. What the consumer side needs to do is according to the list of services provided by the registry. Then use the distribution algorithm for load balancing

Load balancing algorithm Spring Cloud provides Ribbon components to achieve load balancing, while Dubbo has built-in balancing strategy directly. Common algorithms include: polling, random, minimum number of active calls, consistent Hash, etc., such as dubbo configuration polling algorithm:

Ribbon configure random rules:

@ Beanpublic IRule loadBalancer () {return new RandomRule ();}

Failure retry is actually a fault-tolerant mechanism for RPC framework. For example, Dubbo has built-in fault-tolerant mechanisms including: Failover, Failfast, Failsafe, Failback, Forking and Broadcast;. The default fault-tolerant mechanism is Failover automatic switching when failure occurs, and retry other servers in case of failure. Configuring fault-tolerant mechanism is also very simple:

Health check registries generally have a health check function, which detects whether the server is available in real time, removes it if it is not available, and pushes the update to the consumer; it is completely unaware of the user.

Distributed scheduling separates the scheduler from the actuator, and the executor is also provided to the scheduler through the registry, and then the load balancing operation is carried out by the scheduler. The process is basically similar and will not be described here. It can be found that stateless load balancing is more often than not in the registry, which dynamically increases or decreases the execution unit through the registry, so it is very convenient to expand and reduce the capacity.

Have a state

Stateful execution units are more difficult than stateless ones, because the state of each node is a part of the whole system, not nodes that can be added or subtracted at will. Common stateful middleware are: message queuing, distributed cache, database middleware, etc.

Message queue

Nowadays, high-throughput and high-performance message queues are becoming more and more mainstream, such as RocketMQ,Kafka, which has strong horizontal scalability. Message Queue mechanism is introduced into RocketMQ, and Kafka is introduced into partition (Partition). One Topic corresponds to multiple partitions, using the idea of divide and conquer to improve throughput and performance. You can see a simple diagram of RocketMQ:

Operation unit configuration the operation unit in the message queue is actually the partition or Message Queue here. For example, RocketMQ can dynamically modify the number of read and write queues. RocketMQ also provides the rocketmq-console console, which can be modified directly.

The message queue of load balancing algorithm generally has the production side and the consumer side, and the production side takes turns to send messages to each MessageQueue by default, of course, the custom sending strategy can be realized through MessageQueueSelector; the consumer side allocation strategy includes: paging mode (random allocation mode), manual configuration mode, designated computer room mode, nearest computer room mode, unified hash mode, ring mode.

Failure retry for stateful execution units, it does not mean that downtime can be removed directly, but data integrity needs to be guaranteed. Normally, active and standby processing is usually done, and the host hangs up the standby machine to take over; take RocketMQ as an example, each partition has its own backup, and the strategy adopted by RocketMQ is that the backup area is only to ensure the integrity of the data, and consumers can message the data of the backup area, but will not receive the data again.

The health check message queue also has a core component, which can be understood as a coordinator or a registry. Kafka uses zookeeper,RocketMQ and NameServer, which actually stores relevant corresponding information such as Topic corresponding to Message Queue. If a broker is found to be unavailable, it will inform the producer in a manner similar to that of the registry.

Distributed cache

The common distributed caches are redis and memcached. In order to accommodate more data, they generally do sharding processing, and there are also a variety of sharding methods. Take redis as an example, client-side sharding, proxy-based sharding, and official Cluster solutions are available.

Although the operation unit configuration cache is stateful, it has its particularity. It pays more attention to the hit rate. In fact, it can tolerate data loss, such as the proxy-based sharding middleware codis, which can add or subtract redis instances when it is completely transparent to the client and does not affect the service.

On the premise of ensuring the hit rate, the load balancing algorithm based on proxy slicing generally uses the consistent hash algorithm, while the Cluster scheme officially provided by redis, because it has 16384 virtual slots built in, directly uses modularization to complete the slicing.

Stateful shards that fail to retry generally have a backup area. After the main area is down, the backup area takes over to achieve failover, such as the Sentinel mode of redis or the built-in function of middleware such as codis. There is no need to switch other partitions, which is completely imperceptible to the user.

Health check takes redis as an example. In Sentinel mode, sentinel monitors nodes in real time by heartbeat and performs fault migration through objective offline. It can be found that health check is basically detected by heartbeat.

Database layer

Balancing in the database layer should be said to be the most complex, first of all, it is stateful, and secondly, the security of the data is very important. common database middleware include: mycat,shardingjdbc and so on.

The operation unit configuration takes the sub-table as an example. The operation unit here is actually a fragment data table, and the amount of data is often beyond our expectations. Generally speaking, it is rare to say how many fragments are allocated to it. It is best to generate the data table automatically through the load algorithm, and it is best to evaluate a certain load algorithm in advance, otherwise it will be very difficult to change it later.

Load balancing algorithm takes mycat as an example to provide a variety of load algorithms: range convention, modularization, slicing by date, hash, consistent hash, sharding enumeration, and so on. For example, the following daily partition configuration:

Create_time sharding-by-date yyyy-MM-dd 2021-01-01 2051-01-01 10

Specify the start time, the end time, and the number of days of the partition; because the data is continuous with time, the scalability of this method is very good; if it is a modular method, it is necessary to consider the number of shards. Later, it is very troublesome if you want to change the number of shards, unlike the cache which can use consistent hash to ensure the hit rate.

If you fail to retry a stateful node, the standby database is indispensable. For example, mycat provides master-slave switching function for failure, and master downtime switching to slave switching is basically this routine. Data cannot be lost.

Health examination is also necessary for the same active detection, which is generally based on the heartbeat statement to detect regularly, and then do the fault master-slave switch.

At this point, the study on "detailed explanation of nginx load balancing" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.