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

The previous article introduced a simple UDP service framework, but in the face of massive requests, the synchronization framework is obviously a bit inadequate. So when I took over the interface services of the buddy system, I adopted a powerful asynchronous framework-MCP framework.

MCP framework is a multi-process asynchronous framework, supporting UDP, TCP and http, the structure is very flexible, you can according to the needs of the components like building blocks assembled. The following is the most basic process structure of MCP. There are 3 processes: CCD, MCD and DCC.

CCD is a client-oriented process, is the entrance to the service, responsible for processing front-end requests, maintaining connections, sending and receiving data, and forwarding to MCD. It uses thread pools internally to implement listen and accept for TCP requests. The internal processes of the server use flow (actually a number) to represent connections, so CCD is responsible for maintaining the mapping between front-end request handles and flow. CCDs are generally set to multiple according to port and protocol.

DCC is a back-end oriented process responsible for making requests to other services. Similar to CCD implementation method, but oriented to the server. In a coroutined MCP framework, DCC is removed because MCD interacts with the backend through coroutines. The connection between DCC and backend is generally long to avoid frequent creation and release of connections resulting in a large number of TIME_WAITs.

MCD is the core process of the server, responsible for handling business logic, asynchronous through epoll and callback functions.

Processes communicate through MQ, which uses shared memory queues to transmit data and pipes to transmit read and write signals. As shown in the following figure, the process first writes data to the queue, and when the queue reaches a certain length (avoiding reading data for every request), MQ pipes a character. MQ consumers simply listen to pipe handles through epoll to get read and write signals in time.

Understanding the basic principles of MCP, you can customize the process according to the needs of the business. For example, because MCD single processes may have performance bottlenecks, we extended them to multi-MCD process versions. As shown in the figure, multiple SUBMCD processes are derived from the MCD backend, and the SUBMCD process is responsible for processing the real business logic; while the MCD process degenerates into a service distribution program, and is also responsible for some common business logic, such as managing the timeout cleaning of global hash table data (periodically scanning timeout nodes, scanning in times if the table is too large, as long as the scanning position information is kept).

SUBMCD communicates directly with CCD and DCC (MQ between SUBMCD and CCD is omitted in the figure). Through configuration file settings, shared memory MQ is created among various processes that need to communicate when the service is initialized. This prevents MCD from becoming a communication bottleneck.

In addition, a MONITOR process is spawned, which is responsible for collecting and outputting logs, and can also do other time-consuming operations to avoid blocking business processes.

MCP frameworks combine power and performance. I don't remember the specific pressure measurement data. In a packet forwarding service, QPS is also 30W +. In use, there is a certain learning cost, but the application is very wide, it can be said that a framework goes all over the world.

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.