In “Why is Message Ordering So Hard?” , introduced a method of “ID serialization” to ensure that “all the group messages displayed by all the group members are consistent” : all the messages of the same group GID are processed on the same server.

How does ID serialization work?

The common layered architecture of Internet high availability

Client, reverse proxy layer, access layer, service layer, storage layer, this is the common high availability layer architecture of the Internet.

Voice-over: This diagram has been used many times.

The “service layer” here is crucial, and ID serialization ensures that messages from the same group GID land on the same service.

Voice-over: There are many nodes in a service cluster. If you can land on the same service node, you can use this service node to serialize messages.

Service layer upstream and downstream details

The service is generally implemented by RPC framework. The upstream caller is a multi-threaded program, which accesses the service through rPC-client, and the internal rPC-Client accesses the service through connection pool.

Voice-over: To ensure high availability, connection pooling establishes connections to every service in the cluster.



As shown above:

(1) Upstream is business application;

(2) Downstream is a service cluster;

(3) Business application, which is divided into the following parts:

– The upper layer is the task queue (pink);

– In the middle are worker threads (blue), each of which performs actual business tasks, typically RPC calls through the service connection pool;

– The bottom layer is the service connection pool (green), through which all RPC calls are executed by sending requests to downstream services;

Voice-over: Orange is a connection in the connection pool.

A typical workflow for a worker thread looks like this:

void work_thread_routine(){

// Get the task

Task t = TaskQueue.pop();

// The task logic is processed to form a network packet

Packet p = MakePacket(t); __

// Get a Service connection from the Service connection pool

ServiceConnection c = CPool.GetConnection();

// Send a packet over a Service connection to execute an RPC request

c.Send(p);

// Put the Service connection back into the Service connection pool

CPool.PutConnection(c);

}

How do YOU ensure that messages from the same group GID land on the same service?

Make a few changes to the connection pool to get a connection:

CPool.GetConnection()

Voice-over: Returns any available service connection.

Upgrade to

CPool.GetConnection(long id)

Voice-over: Returns the service connection associated with the id of the module.

Passing in a group GID ensures that requests from the same group get the same connection, thus landing on the same service.

Note that the connection pool does not care what the business meaning of the passed long ID is:

(1) The group GID is passed in, and the request with the same GID falls on the same service;

(2) The user UID is passed in, and the request with the UID falls on the same service;

(3) Any business XID passed in falls on the same service as the request of the business XID;

ID serial access to the service, the same ID access the same service, when the service is down, will the service availability be affected?

No, when a downstream service fails, the connection pool can detect the availability of the connection and remove the service connections that are not available.

Will the load balancing of connection requests be affected by the access to the service?

No, as long as the data access ids are balanced, the probability of obtaining all connections from the id module is equal globally, that is, the load is balanced.

Get the connection, ID take the module, I hope you have a harvest.

The Architect’s Path – Share practical technical articles