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

  1. Handle request parameters: THE URL is a request object class wrapped in Dubbo, containing the Map

    attribute numbers, which contains the Actives configuration
    ,>
  2. 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
  3. 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 tag allows you to configure key thread pool parameters, such as thread pool type, blocking queue size, and number of core threads

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 isCPU+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 size200
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()
  1. 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
    ,>
  2. Extracts the executes parameter value, numbers — paramters — default values are returned in order
  3. 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