To recap: What a normal RPC framework needs to do: register, discover, expose services. Service registration includes: call modules (load balancing, fault tolerance, transparency). The RPC protocol includes (serialization, encoding, transmission), transparent remote calls. Format of RPC message: request line, request header and request body. The RPC protocol is more streamlined and requires less transfer than HTTP. Today mainly talk about the transmission, in fact, is the most complex, said this meaning, feel just use dubbo, in fact, the significance of the developer is not very big, we do not need to understand the underlying business transmission, but if you want to design a message server, this is the general developer can fix. You must have some experience with a remote implementation referenced by someone else. Knowing this gives you a deeper understanding of performance tuning and configuration for Dubbo than some of the configurations in the API documentation for Dubbo
Bottom look, the framework is changing, the same is always bottom. Underlying communication services: Push information on Android and ios terminals. Network communication with special equipment.
(1) Dubbo based on Netty network transmission implementation
An RPC protocol implementation consists of communication module, message coding and decoding module and serialization module, among which the communication module is the implementation of RPC network transmission. Its stability and performance directly affect the stability and performance of RPC service. How to ensure the stability and performance of the transmission module?
If you want to solve the stability and performance of the transmission module, you must first understand the composition of RPC protocol, always emphasize the module split, the module split, that is, the module is composed bit by bit, like building blocks.
1. IO model:
The RPC framework must be either NIO or AIO.
- BIO with block (monogamy)
The thread initiates an IO request and blocks from the time the request is initiated until the operation is complete, regardless of whether the kernel is ready for the IO operation. One thread at a time.
- NIO synchronous non-blocking (polygamy)
The thread initiates an I/O request and returns immediately. After the kernel is ready for the IO operation, it calls the registered callback function to tell the thread to do the IO operation, and the thread blocks until the operation is complete. One request per thread.
- AIO asynchronous non-blocking
The thread initiates an I/O request and returns immediately. After the memory is ready for the I/O operation, it performs the I/O operation until the operation completes or fails. The thread is notified to complete or fail the I/O operation by invoking the registered callback function. One valid request is one thread.
2. Connect model
Network transport model: The bottom layer is TCP connections. RPC generally uses long connections.
- A long connection
When the client and server establish a connection, a TCP connection is established. It will not be released after it is used and it will keep it and keep communicating. HTTP is a long connection. Shut it down when it runs out,
How long is HTTP keeplive active disconnect? TCP keeplive is how often to complete the state detection, is to protect the connection. Long connections are not suitable for transferring large fields. The big file stopped everything, and the others came to play.
- Short connection
When the connection is complete, the connection is released.
Large files are suitable for short connections. All IO threads.
3. Thread classification
- IO thread
Although IO is responsible for reading and writing streams, in fact, the most time-consuming is business. Encoding and decoding belong to the IO thread.
- Server-side business threads
The thread that Tomcat or Dubbo sets up the thread pool is actually the business thread being set up.
- The client schedules the thread
Class instantiates remote methods in classes that are done by scheduling threads. But the transfer process is all through the IO thread.
- The client results in exchange threads
The results are sent to the scheduling thread.
- Keep the heartbeat thread alive
Ensure that the connection is always long.
- Reconnection threads
Hang up and reconnect.
4. Thread pool model
All threads involve the concept of thread pools.
- Fixed number of thread pools
- Cache thread pool
- Finite thread pool
(2) Long connection creation and maintenance
Dubbo long connection implementation and configuration
- The initial connection
Reference service | increase provider = = > access connection = = = > if access to Shared connection = = > create a connection client = = > open timing heartbeat detection state examination task = = = > open connection state detection
Source: com. Alibaba. Dubbo.. RPC protocol. The dubbo. DubboProtocol# getClients
- Heartbeat sending
When a connection client is created, a heartbeat client is also created. By default, the client sends a heartbeat every 60 seconds to keep the connection alive, via heartbeat Settings.
Source: com. Alibaba. Dubbo. Remoting. Exchange. Support. The header. HeaderExchangeClient# startHeatbeatTimer
- Break line reconnection
Every time a client connection is created, a scheduled task is initiated to check the current connection status every two seconds. If the connection is disconnected, the connection is automatically reconnected.
Source: com. Alibaba. Dubbo. Remoting. Transport. AbstractClient# initConnectStatusCheckCommand
- Connection destruction:
Server is destroyed after disconnection based on registry notification
Source: com. Alibaba. Dubbo. Remoting. Transport. AbstractClient# close ()
(3) Communication thread cooperation process
- Dubbo transports collaborative threads
1. Client scheduling thread: the thread used to initiate remote method calls. 2. Exchange thread: when the remote method returns a response, this thread fills the ResponseFuture and wakes up the waiting scheduling thread. 3. Client IO thread: implemented by the transmission framework, it is used for sending request message flow, reading and decoding response message flow and other operations. 4. Server IO thread: implemented by the transmission framework, it is used for reading and decoding request message flow and encoding and sending response message flow. 5. Business execution thread: the thread in which the server executes the specific business method
- Client thread collaboration process
1. Schedule threads
- Calling remote methods
- Protocol encoding of request
- Sends a Request message to the IO thread
- Wait for results to be obtained
2. IO thread
- Read the response stream
- The response to decode
- Submitting an Exchange Task
3. The Exchange threads
- Fill in the response value to ResponseFuture
- Wakes up the scheduling thread to notify it of the results
- Server thread collaboration
1. IO thread:
- Read the request flow
- The request to decode
- Submit business processing tasks
2. Business threads:
- Business method execution
- The response to decode
- Write the result back to channel
- The thread pool
1. Fixed: fixed thread pool. When this thread pool is started, it creates a fixed number of threads without scaling. 2. Cached: a pool of cached threads that can scale and be recycled after being idle for a minute. 3.Limited: a thread pool that keeps growing until it reaches its limit and does not shrink.
PS: If the top can figure it out, it is not the great god, but also one foot into the ranks of the great god.