In the game ecology, it mainly includes the game R & D side and operation distributor. The operation of a game is divided into two stages: research and development and operation. The main body of R & D includes individuals, independent studios, game R & D companies, etc;
The main body of game research and development focuses on the research and development of game content. The lack of investment in human and financial resources in the distribution and operation of the game often leads to the emergence of game distribution and operation business, resulting in an independent operation distributor. At present, many large game manufacturers package their own distribution and operation capabilities to the operation distributors. In addition, some game distribution channels, relying on their own traffic advantages, also provide joint operation services only for this channel.
The interaction part in the above figure:
L the control and interaction of the game itself is conducted between the game client and the game server, and most of them will communicate by using the socket long link.
L the interaction between the game client and the game publisher platform, including login, payment, etc., which are requested by game players on their own initiative, will be linked and communicated in the way of HTTP.
The interactive selection of these two parts is relatively fixed.
However, in the operation distributor, such as the operation news and advertising push scenarios, such as various server operation and maintenance upgrade information; account kick off line information; suspension window advertising; ordinary message push and other services are more actively pushed by the game’s operation distributor. In the case of millions of game customers, how to choose a more suitable interaction mode is a headache.
In this chapter, we discuss how to better choose the technical implementation of operational distribution message.
The characteristics and requirements of the push of the operation distributor
1. Reach more users: the total number of customers of a successful game often exceeds one million million million. At the same time, the online number is high.
2. The timeliness of messages is different: some messages are effective within a certain period of time (such as the main game service operation and maintenance Upgrade Notice). No matter whether the customer’s current status is online or not, if the current customer is online, it will be received immediately, and the offline customer will also receive the corresponding message the next time they enter the game. Some messages are meaningful only for the current online customers (such as account kick-off information).
3. Accurate mass appeal: push messages are broadcast to customers with certain characteristics (for example, different advertisements correspond to different levels of game players)
4. Lightweight consumption of connection: compared with the control of the game itself, the frequency of such data interaction is relatively low, so the amount of client running resources occupied by the game client and advertising operation data push is as small as possible.
5. The SDK relies on simple resources: in the game field, the R & D team will generate the game master package, and the operation distributor will embed the SDK package needed for operation on the basis of the master package, such as payment function and data push function. Then, the smaller the resource package the push function depends on, the better.
Analysis of alternative technical solutions
1. HTTP polling scheme:
The game client relies least and is easy to implement.
High proportion of invalid polling: multiple clients, multiple types of polling, in view of the low frequency of this type of message, then most of the polling is meaningless.
The operator side implementation is complex: additional code logic is needed to maintain the read state.
High resource utilization: the surrounding supporting call chain, log information, and concurrent processing capacity push up the resource utilization.
2. Socket scheme:
The game client relies less and is easy to implement.
Connection maintenance: the operator will have different types of application division (for example, advertising may be a separate application, and system management will also be a separate application). If all of them need to be pushed, then different sockets must be connected to different types of applications. In this way, the connection of game clients will increase and occupy more resources.
The implementation of the operator side is complex: additional code logic is needed to maintain the subscription push type. In the push process, the code is required to filter and deliver to the target group accurately; In order to ensure the quality of the push (whether it arrives or not), it is necessary to record the push status additionally; for the timeliness of the push data, additional control is needed, such as some expired messages (such as service operation and maintenance time notice).
3. Kafka scheme:
Simple access: mature message middleware, supporting various implementation languages. It only needs to connect the Kafka node itself, and does not need to connect with the application of the publisher directly, so it can be uncoupled naturally.
Powerful: the status maintenance and storage of push data can be provided by Kafka.
The number of client connections is not enough to support a large number of gamers (clients) through a simple cluster.
4. Mqtt scheme:
Access is simple, mqtt protocol is very simple, support a variety of implementation languages.
Support various subscription relationships.
Support P2P message.
Support QoS quality of various message reach.
The connection of the client can be observed.
Support millions of connections.
Mqtt technology is not as popular as other solutions at the present stage.
Mqtt technical solution
By comparison, the mqtt scheme is very suitable for the interactive scenario of pushing data between the game publisher and the game client. So let’s look at the design principles of this technology.
1. Lightweight and efficient micro message, simple mqtt protocol and simple header;
2. Based on the pub / sub communication mode, two-way communication can be carried out;
3. Support topic for message storage and disk dropping;
4. It supports subscription relationship setting, P2P mode and broadcast mode;
5. Support million level connected devices;
6. Provide quality management of message service;
7. It is suitable for low bandwidth, high delay and unstable network;
Here, let’s compare Alibaba cloud’s product micro message queue mqtt with open source mqtt.
In the game publishing and operation platform, the use of Alibaba cloud micro message queue mqtt product can meet the data push service scenario between the operation platform and the game client, that is, it can not only ensure million level connection, but also achieve less resource occupation, as well as various complex message data distribution and subscription control.
Link to original text
This article is the original content of Alibaba cloud and can not be reproduced without permission.