One: previous reading
In a high concurrency environment, if the producer cannot process the request in time, a large number of request threads are backlogged, which eventually leads to a large number of service crashes. The key point of this paper is to set up a reasonable request rejection policy according to the service characteristics to ensure the normal operation of the service. Of course, it must be different from load balancing, which can only distribute traffic but not limit it
Two: actives on the consumer side
This works only on the consumer side and can only be configured in
or its child tags
or
. The priority policy is the same as described in Dubbo Tuning — TimeOut
2.1 Configuration Example
- Dubbo: The configuration in Consumer applies to all methods for all services
- Dubbo: The configuration in Consumer takes effect for all methods of the service
- dubbo:methodThe configuration takes effect for this method
2.2 Parameter Description
| describe | note |
|---|---|
| role | Consumer maximum number of concurrent requests, exceeding which an exception will be thrown |
| implementation | Filter, the concrete implementation subclass is ActiveLimitFilter |
| The default value | 0 means there is no limit |
| Configure the location | <dubbo: Consumer >, <dubbo: Reference >, <dubbo:method> |
2.3 Source Code Introduction
- Handle request parameters: THE URL is a request object class wrapped in Dubbo, containing the Map
attribute numbers, which contains the Actives configuration
- Request filtering judgment: The RpcStatus class encapsulates the producer call state, and the AtomicInteger active attribute stores the current number of calls. It is judged by comparing it with the corresponding parameter attribute value obtained in THE URL
- Return result: if the request is allowed, the next RPC call is made, if not, the waiting time for the thread timeout parameter is suspended, and if no thread is available, an exception is raised
Three: connections to the consumer end
The familiar HTTP protocol is a short connection, and each request requires multiple handshakes to establish the connection. The default Dubbo protocol belongs to the long connection and adopts NIO asynchronous transmission. By default, each consumer and producer uses a single long connection to communicate. To put it simply, a long connection between each consumer and producer is created by default, shared by all requests
The connections parameter has different effects for the above long and short connections:
- The number of short connections is limited because they are multiple connections
- Long connections are specified because they are single connections
3.1 Configuration Example
The connections parameter takes effect on the consumer side, with Figure 1 showing the configuration on the consumer side and Figure 2 showing the configuration on the producer side. According to our own tests and Github verification, the configuration on the production side does take effect via the registry to the consumer side
3.2 Parameter Description
| describe | note |
|---|---|
| role | Limit the number of short connections and the number of long connections created by consumers |
| implementation | Initialization of connections is controlled by parameters |
| The default value | Long connection by default, long connection is shared by the JVM. Online production and consumption are common. You are not advised to change this parameter |
| Configure the location | <dubbo:consumer> <dubbo:reference> <dubbo:provider> <dubbo:service> |
3.3 Source Code Introduction
The project initializes a connection based on the connections parameter in the getClients() method of the DubboProtocol class. You can see that the array used to store the connection ends up returning two instances of the connection
The delivery of the production end
The consumer can set the number of connections through the connections parameter, but if the producer does not protect itself, the default unrestricted connection policy is adopted. In the case of high concurrency the producer may be crushed by the number of connections, the price accepts the maximum number of connections the producer can accept can be limited by the parameter ACCEPTS
4.1 Configuration Example
Accepts the maximum number of connections for producers to protect their service availability, which can be configured in the tag
. At this point in
set connections to exceed the accepts value to facilitate subsequent source code follow up
4.2 Parameter Description
| describe | note |
|---|---|
| role | Limit the maximum number of connections a producer can accept to protect the producer |
| implementation | When the consumer initializes the create connection and opens the create link, it is judged by the restriction parameter |
| The default value | 0 indicates that there is no limit and the configuration is dangerous |
| Configure the location | <dubbo:protocol> |
4.3 Source Code Guide
The producer starts initialization and you can see that the configuration accepts the parameter when opening the connection, which is shown in the AbstractServer class constructor
Five: Thread pools at the production end
Dubbo provides support for four types of thread pools. The producer
5.1 iothreads, threads
- iothreads: limits the size of the IO thread pool used to process the Dubbo framework’s own business logic. The default value is
CPU+1, you are not advised to change the Settings - threads: specifies the number of threads in the business thread pool described below. This is the number of threads the business needs to care about. The default size
200
5.2 threadpool
The threadpool parameter specifies the type of threadpool to be used. Dubbo’s own implementation provides four thread pools, as shown in the following table. A FixedThreadPool of fixed size is used by default
| Type the name | Queue type | Characteristics of note |
|---|---|---|
| FixedThreadPool | queuesProperty 0 to create a no-capacity blocking queueSynchronousQueueIf,queuesIf the value is less than 0, integer. MAX_VALUE is createdLinkedBlockingQueueBlock queue, created if greater than 0queuesParameter limited capacityLinkedBlockingQueueBlocking queue |
The number of core threads takes the same parameter as the maximum number of threadsthreadsValue, thread idle lifetime 0 |
| CachedThreadPool | Queue creation type rules andFixedThreadPoolconsistent |
The FixedThreadPool thread pool has more parameters than the fixed capacitycorethreadsThe number of core threads can be set to 0 by default. The idle duration of threads is not provided. The default value is 1 minute |
| LimitedThreadPool | Queue creation type rules andFixedThreadPoolconsistent |
The biggest change from CachedThradPool is that the thread lifetime is changed to long.max_value |
| EagerThreadPool | The queue is designed and implemented for DubboTaskQueueQueue, which inherits fromLinkedBlockingQueue. whenqueuesIf the parameter is smaller than or equal to 0, the capacity is 1; if the parameter is greater than 0, the capacity isqueuesThe parameter value |
A dedicated article will examine this thread pool implementation later |
5.3 pay attention to
The Dubbo documentation only describes Fixed /cached, and the default for all four thread pools is Fixed
Vi: The production end executes
A property that can only be configured in the producer, dubbo:service, or its child, Dubbo: Method. The main purpose of this parameter is to limit the number of application threads used at the producer side
6.1 Configuration Example
Limit the number of concurrent requests for each method of this service to 10, with dubboProtocolGetMethod exceeding 2. Method-level configurations take precedence over service configurations
6.2 Parameter Description
| Configure the location | producersdubbo:serviceTag or its child tagdubbo:methodIn the |
|---|---|
| The default value | 0 means there is no limit |
| role | The service provider can only occupy a configured number of threads in the thread pool per method, exceeding which will throw an exception |
| implementation | Filter Filter |
6.3 Source Code Guide
- ExecuteLimitFilter, RpcStatus, URL
- Main methods: getMethodParameter(), beginCount(), getStatus()
- Handles the request parameter, whose URL is a request object class enclosed by Dubbo that contains the Map
property numbers, which contains the executes configuration
- Extracts the executes parameter value, numbers — paramters — default values are returned in order
- Compare the executes value number, the RpcStatus class encapsulates the producer call state, and the AtomicInteger atom type Active property stores the current number of calls