Use shared memory to restore player data

It sounds like shared memory and games are not very much, but using shared memory on game servers is not a new thing, and swimming and pixel in the Dragon Eight and the quest for fairy on the implementation of this application (but not necessarily as mentioned below).

Discussed with colleagues earlier how to use shared memory in an existing framework to access unified data between processes, the ideal application scenario is to meet the current segmentation of the logical process in the scene, access to the same memory data means that the scene between the object and the process can be done without passing data, It's natural for a monster to go to another scene with a player, because the object data used between processes is always only one, and the management of redundant units in a seamless world doesn't exist ( The solution for Atlas is to use a central choice server to decide which process to manage redundant units of data in the overlapping logical areas of the world. Another application is the data and logical separation of the scheme, which means that the player data from the database loaded to put a place, the service process who take who to use, such as the chat server needs the player's name to share the access, the auction server needs to operate money to share the access, The mail server handles the extraction of one mail item or the shared memory that is accessed. The processing between functional processes does not result in dirty information due to redundant data, and a functional logic is relatively easy to coordinate between processes, and then a process can be implemented to maintain the shared memory such as timed disk, timing or delay to change a data.

These two programs sound appealing but they don't take shape. The reason for this is simple: shared memory is accessible on a machine, and the purpose of the previously designed process of processing different logic is to allow more machines to share operations, and to use shared memory means that multiple processes must be placed on a single machine. However, the advantages of the sample process is completely inferior to the thread, the thread between the simple memory lock access can solve the problem why do you have to use the shared memory between processes.

Recently added a new tour of the program to introduce their dragon's shared memory only to find in fact there is another simple but indeed has been used in combat scenarios: Player data backup. In the process of processing crashes may result in the player data back to the file, the general is to take the N-minute automatic Save the method, but this method can not be a very high frequency, second, even if the increase in frequency can not guarantee that the player important information not in the disk before the production. Bedo People's program team is difficult to ensure that the program in the late new features on the line can be fast and stable, this time to ensure that the player's information is not frequently back to file as a priority to solve the problem. Shared memory is a great way to solve this problem, only one maintenance process is responsible for preserving this shared memory when the logical process crashes (shared memory requires more than 1 process references to be not reclaimed by the system), ensuring that the disk is processed before the next logical process is started. Tianlong's shared memory strategy the core is to use data redundancy data to ensure backup, the application of shared memory can be simply understood as a process-specific small database, the actual logic process still has a player's data local memory information, Update shared memory data while changing the memory of this process when you need to modify player information logically another maintenance process is responsible for data loading and timing to the data inventory disk, maintenance process and logical process, because to operate the same object information, so access to the shared memory need to unlock operations ( Online can also be found in the design of this package of documents, hehe, this strategy is really simple and easy to use.

Based on the purpose of backup player data, the program suitable for the current project is also clear: the maintenance process just enter the shared memory does not access any data, the logical process started to traverse the existing shared memory area, if there is data to judge data integrity after the save, save the shared area after the end of the disk. This way, access to shared memory is not unlocked. The maintenance process has been pause since it was started. And there's no need to worry about what will happen to the crash; because access is not mutually exclusive, there is no need to operate a local memory to ensure speed, directly manipulate the data in the shared memory line ( The current test results show that the operation of shared memory and operation of local memory efficiency, the same as 16ms 1kw times, and recovery is not special write, the logical process itself has the disk logic. Fortunately, the attribute system used in the existing logic process is also easy to dock with. The original design goal is to use the data that can be cared for by any scene object (this kind of data only includes the object attributes mentioned in the plan, but not the ones that are generated when the program is run, which is also exactly needed to be filed). Unified in a continuous memory management, by attributes registered type and index to access and modify. Because not all objects require a backup of shared memory, the only objects that are relevant to the player, such as players, BUFF, objects, guild, etc., need to provide 2 kinds of allocator when allocating memory in the attribute system; A shared memory pool based on a local memory pool. It's even more fortunate that these allocator aces have been offered to us, and there are more than 2 possibilities for porting Linux. (See the next article for a concrete implementation.) )

The version implemented according to this scheme is now running well, but there is an accident more tangled, if there are 2 different projects generated EXE to operate this block of memory will be read and write error ... For example, the maintenance process and the logical process all access this memory, then the access will be problematic. But there is a same project generated such as multiple logical processes to access this block of memory is not the problem. These 2 engineering settings and the memory alignment pattern are all the same ... At present it seems that the maintenance process is not used to access this block of memory.