- Assign a unique ID to a role when creating it.
- Each item requires a unique ID when creating an item.
- A unique ID is required when you create a baby or animal
Principles
The principle of the ID generator is to use a global integer variable. After each allocation, the variable increments by 1. Because the global variables are invalid after the server is restarted, the global variables must be saved persistently. Correspondingly, global variables are loaded from the persistence during server startup. The workflow of the ID generator is:
- We recommend that you use a database for persistent storage. This document uses mysql as an example.
- Load global variables from the database at startup as the initial value of allocation
- The global variable is incremented before each id is assigned.
- Update the global variable value in the database after each increment.
- Because the same function module may run on different gameservers, the unique ID uses a 64-bit integer, with 16 digits used to represent the GameServerID
- Because different functions do not affect each other even if the IDs are the same, for example, role IDs and item IDs are independent and do not conflict with each other, global variables can be divided into different types, and different types use different global variables.
Sample Code
sql = (self, db_host_, type_id_ = 0, server_id_ ========== self.db.sync_query( % len(ret.result) == self.db.sync_query( %== int(ret.result[0][1 self.runing_flag !=+= 10000 % == %+= 1= self.auto_inc_id & 0xFFFF= (self.auto_inc_id >> 16) << 32 high | (self.server_id << 16)|= id_ & 0xFFFF= id_ >> 32 high << 16 | True ==== self.saving_flag = now_val < %
Summary
- If the GameServer of different blocks uses different IDs, the old IDS can still work even if the blocks are merged.
- Update the database immediately after the global variable increments to ensure consistency between the db and the memory as much as possible, but ensure that only one db operation is executed at the same time. After the db update callback is performed, check if the database is modified again, execute db update again. For example, 100 IDs are allocated at a time to avoid db update in the "surprise group.
- Because db update is executed immediately after the incremental id, the db and memory are almost consistent. If the database goes down during the running period, the db and memory may be inconsistent. You can create an enhanced version based on this, that is, add a field running to each row of the database, set the value to 0 for each db update, and set the value to 1 when the server is shut down normally. When the server is started to load the global variable, if this value is 0, it is increased by 10000. This ensures that all IDs are unique.
