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

How does server-side multiplexing solve the problem of high concurrency of connections? in view of this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Shopping on Taobao, such as double 11 seconds to kill a product, is a test for the backstage. When a website system receives a large number of requests in a very short period of time, stability is very important, and users do not like to see their app always turn to chrysanthemums. The specific background is detailed in the previous article: the vernacular describes the evolution of Taobao server distributed architecture-a series of vernacular distributed systems.

Let's not talk about strategic things here, but talk about the concurrency problem under multiple connections at the socket level. First, let's take a look at the iCando operation. Call read to read data from the stream, and call write to write data to the stream. What if read is called but there is no data in the stream? You can only use blocking IBO. In the case of multiple connections on the server side, if one descriptor FD is blocked, the other descriptor fd cannot be processed even if the data is received. In this case, a special method must be adopted to deal with it.

One way is to use multiple processes, which causes each process to perform blocking read, but signal synchronization between processes is cumbersome.

Another way is to use a process to execute the program and use non-blocking Iripple O to read data. Use polling to read whether all sockets can receive data. The deficiency of this method is the waste of CPU computing resources.

What I'm going to talk about here is poll O multiplexing, that is, calls to poll, epoll, pselect, and select. You can take a look at the process of receiving data from the network card through the Ethernet driver:

After receiving the data packet, the MAC Nic writes to the memory convention address through DMA (here, if the data in memory is cached in cache, there will be data inconsistency between DMA and Cache, but this is not the focus of this article), and then trigger the hardware interrupt to notify CPU,CPU to call the interrupt program to read the data in memory.

Next, you can see how the operating system can read and write multiple socket through select. I talked about several ways of process scheduling earlier: process scheduling and fork, which roughly means that the operating system maintains a queue (assuming the task priority is the same), and the task scheduler fetches the task execution on the queue sequentially:

When Task A creates a socket, the operating system creates a socket object (all descriptors are files). This socket object contains members such as send and receive buffer, task waiting queue, and so on. Refer to the implementation of lwip:

Create a socket:

When process An executes read, process A changes from running state to blocking state because there is no data to read. The operating system will hang process A under the waiting queue of socket and remove it from the work queue. At this time, only processes B and C occupy CPU resources.

Note here that instead of directly attaching process A to the waiting queue, the mailbox recvbox of process An is hung up:

When the data is received, the task scheduler sets process A to the ready state and hangs it in the work queue to reschedule the task.

So, the server needs to manage multiple connections, and a read/recv can only block one socket, so select is used here. Instead of putting the code here, we will directly use the diagram to illustrate:

Process A monitors all socket. After any connection receives data, the interrupter wakes up the process on the waiting queue, and then only the process that actually receives the data runs, and the rest of the process continues to block. This is the "surprise group" phenomenon of the server.

Is there a more appropriate way to monitor events? The answer is epoll.

The APIs of epoll are as follows:

Int epoll_create (int size); / / create a handle to epoll. Size is the number of int epoll_ctl (int epfd, int op, int fd,struct epoll_event* event); int epoll_wait (int epfd, struct epoll_event* events, int maxevents, int timeout)

The disadvantage of select is that the process does not know which sock received the data, so it can only traverse all the sock. Epoll maintains a ready list that references the socket that receives the data to avoid traversing:

When a process calls epoll_create, an eventpoll object is created. Eventpoll objects are similar to socket objects in that they also have wait arrays. The process can then use epoll_ctl to add the socket you want to listen to, and the kernel adds eventpoll to the waiting queue of socket.

When the socket receives the data, the interrupt program adds the socket sequence number of the event to the ready list of the eventpoll. For example, if the data is received on the sock2, it writes 2 into the rdlist array of the eventpoll:

When a process executes epoll_wait, if there is socket in the rdlist, the epoll_wait returns directly, otherwise the blocked process is suspended under the waiting queue of eventpoll. As shown in the figure below, process An and process F are blocked:

When the data is received, the interrupt program writes the corresponding socket sequence number to rdlist, wakes up the process in the eventpoll waiting queue, and processes An and F enter the running state.

This is the answer to the problem of server-side multiplexing how to solve the problem of high concurrency of connections. I hope the above content can be of some help to you, if you still have a lot of doubts to be solved. You can follow the industry information channel for more related knowledge.

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.