A snapshot-based ranking list data query method and device

Abstract

The application discloses a snapshot-based ranking list data query method and device. When a preset trigger condition is detected, current ranking list data is copied to generate a snapshot and is archived. A ranking list data update operation is performed, a unique identifier is allocated to an updated ranking list, and a binding relationship between the identifier and a historical snapshot is established. When a homepage query request is received, updated homepage content of the ranking list is read and a unique identifier is returned synchronously. When a subsequent page query request is received, an archived snapshot corresponding to the unique identifier is called according to the unique identifier, and corresponding page data is read from the snapshot and returned. The application isolates a homepage data source and a page data source through snapshots, and the consistency of historical page data is not affected by ranking list updating, so that the problem of data disorder and content change in page query is avoided, and the page browsing experience of the ranking list is improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and apparatus for querying ranking data based on a snapshot approach. Background Technology

[0002] With the rapid development of digital technology, leaderboard functions are widely used in various information systems such as live streaming popularity and student grades. Among related technologies, Redis Sorted Sets are used to store real-time dynamic data, and a paginated query mechanism is employed for data display. This involves key aspects such as data writing, sorting updates, and paginated reading, constructing a leaderboard query system based on an in-memory database.

[0003] However, existing ranking pagination query methods directly read data from a constantly changing ordered set, without considering the dynamic updating characteristics of the data during the query process. Specifically, when a user flips through pages, the real-time changes in data ranking can lead to the same data appearing repeatedly on both pages or being omitted, causing data inconsistencies. This not only severely impacts user experience and system reliability but also increases the query pressure and resource consumption on the database, making it difficult to meet the requirements for data consistency and real-time performance in high-concurrency scenarios. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] Therefore, the first objective of this invention is to propose a ranking data query method based on snapshots.

[0006] Another objective of this invention is to provide a ranking data query device based on a snapshot method.

[0007] The third objective of this invention is to provide a computer device.

[0008] A fourth objective of this invention is to provide a non-transitory computer-readable storage medium.

[0009] To achieve the above objectives, a first aspect of the present invention proposes a ranking data query method based on a snapshot approach, comprising: S1, in response to a preset trigger condition, performs a snapshot copy of the current leaderboard data, generates snapshot data, and archives and stores it. S2, update the current ranking data, generate a unique identifier for the updated ranking data, and establish an association between the unique identifier and the snapshot data; S3, in response to the homepage query request, retrieves homepage data from the updated ranking data and returns the unique identifier; S4, in response to a subsequent page query request, find the corresponding snapshot data based on the unique identifier, and obtain the subsequent page data from the snapshot data.

[0010] In one embodiment of the present invention, S1 includes: Listen for changes to the ordered set of leaderboard data. When an update operation is detected, check whether the interval between the current time and the last snapshot generation time exceeds the preset minimum snapshot interval threshold. If it does, trigger the snapshot process immediately. Meanwhile, the sorted set of the leaderboard is polled at fixed intervals, and its current state is compared with the state at the previous snapshot time. If the score of any member or the set of members is detected to have changed more than the preset change ratio threshold, the snapshot process is triggered. When the snapshot process is triggered, the current Unix timestamp is obtained as the unique identifier of the snapshot. A new sorted set is created as the snapshot using the Redis ZUNIONSTORE command, and the snapshot replication operation is performed in the Redis MULTI / EXEC transaction. Store the ordered collection of snapshots in Redis's archive space and create a multi-level index structure consisting of time index, leaderboard index, and snapshot metadata. Also, set an expiration time for the snapshots.

[0011] In one embodiment of the present invention, it further includes: Using Redis's SortedSet structure, a global snapshot timeline index is built with the snapshot timestamp as the score and the snapshot key as the member. Using Redis's hash structure, with the leaderboard identifier as the field and the corresponding latest snapshot key as the value, a leaderboard-snapshot mapping index is built; Using Redis's hash structure, metadata information including snapshot creation time, total number of members, and data version number is stored for each snapshot.

[0012] In one embodiment of the present invention, S2 includes: The update operation is performed on the original sorted set of the leaderboard. Before the update, the version of the original sorted set of the leaderboard is monitored by the WATCH command of Redis. If it is detected that the set has been modified by other clients during the WATCH period, the transaction will fail and be automatically retried. The maximum number of retries is set to 3. If all 3 retries fail, the update will be downgraded to using a distributed lock for exclusive update. A universally unique identifier is generated for the updated leaderboard data. The universally unique identifier is associated with the updated leaderboard data and stored using a Redis hash table. The hash table also stores the snapshot timestamp and leaderboard version number corresponding to the universally unique identifier.

[0013] In one embodiment of the present invention, S3 includes: Retrieve the first page of data from the latest sorted leaderboard using the Redis ZREVRANGE or ZRANGE command; Retrieve the universally unique identifier and version information corresponding to the current leaderboard data from the hash table, and encapsulate the universally unique identifier and the first page data together into response data and return it. Set up a short-term cache for homepage data in the front-end or API gateway layer. During the cache validity period, homepage requests for the same ranking list will directly return the cached data.

[0014] In one embodiment of the present invention, S4 includes: The HGET command reads the snapshot sorted set key name and snapshot timestamp corresponding to the universally unique identifier from the hash table. Calculate the index range of subsequent page data in the snapshot ordered set based on the offset, and retrieve the data within the specified range from the snapshot ordered set using the ZREVRANGE command or the ZRANGE command; When the universally unique identifier carried in the session does not exist in the hash table, the nearest available snapshot in time is searched first to complete the subsequent page query. If no nearby snapshot is available, the subsequent page data is directly queried from the latest ordered set of the leaderboard, and data status prompt information is appended to the returned results.

[0015] In one embodiment of the present invention, it further includes: In response to a request to re-query the homepage, retrieve the first page data from the latest ordered set of leaderboards, generate a new universally unique identifier and return it, thus invalidating the snapshot session associated with the old universally unique identifier previously held by the client; Periodically clean up expired snapshots that are no longer referenced by any active sessions. Cleanup strategies include automatic expiration when the time-to-live (TTL) expires, proactive cleanup when the active session count is zero, and scheduled batch cleanup.

[0016] To achieve the above objectives, a second aspect of the present invention provides a ranking data query device based on a snapshot method, comprising: The leaderboard snapshot archiving module is used to take a snapshot copy of the current leaderboard data in response to preset trigger conditions, generate snapshot data, and archive and store it. The ranking update association module is used to update the current ranking data, generate a unique identifier for the updated ranking data, and establish an association between the unique identifier and the snapshot data; The homepage data return module is used to respond to the homepage query request, retrieve homepage data from the updated ranking data, and return the unique identifier; The snapshot pagination query module is used to respond to subsequent page query requests by finding the corresponding snapshot data based on the unique identifier and obtaining subsequent page data from the snapshot data.

[0017] The present invention provides a snapshot-based ranking data query method and apparatus, which can effectively solve the problem of disordered paginated query data caused by real-time changes in ranking data, improve the accuracy and consistency of query results, and enhance the query efficiency of the system in high-concurrency scenarios.

[0018] To achieve the above objectives, a third aspect of this application provides a computer device, including a processor and a memory; wherein the processor runs a program corresponding to the executable program code by reading executable program code stored in the memory, for implementing the method described in the first aspect embodiment.

[0019] To achieve the above objectives, a fourth aspect of this application provides a non-transitory computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described in the first aspect.

[0020] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0021] Figure 1 This is a flowchart of a ranking data query method based on a snapshot method according to an embodiment of the present invention; Figure 2 This is a structural diagram of a leaderboard data query device based on a snapshot method according to an embodiment of the present invention; Figure 3 It is a computer device according to an embodiment of the present invention. Detailed Implementation

[0022] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0024] The following description, with reference to the accompanying drawings, describes a snapshot-based ranking data query method and apparatus according to an embodiment of the present invention.

[0025] Figure 1 This is a flowchart of a ranking data query method based on a snapshot method according to an embodiment of the present invention, such as... Figure 1 As shown, it includes: S1, in response to a preset trigger condition, performs a snapshot copy of the current leaderboard data, generates snapshot data, and archives and stores it. S2, update the current ranking data, generate a unique identifier for the updated ranking data, and establish an association between the unique identifier and the snapshot data; S3, in response to the homepage query request, retrieves homepage data from the updated ranking data and returns the unique identifier; S4, in response to a subsequent page query request, find the corresponding snapshot data based on the unique identifier, and obtain the subsequent page data from the snapshot data.

[0026] Furthermore, this embodiment of the invention proposes another ranking data query method based on snapshots, the specific steps of which are as follows: The data snapshot replication and archiving system employs a hybrid triggering mechanism combining event-driven and timed polling. On one hand, the system monitors change events (such as write operations like ZADD, ZINCRBY, and ZREM) on the ordered set R of the leaderboard data. When an update operation is detected, it checks if the interval between the current time and the last snapshot generation time exceeds a preset minimum snapshot interval threshold T_min (default value is 1 second). If it does, the snapshot process is triggered immediately. On the other hand, the system maintains a timer that polls the ordered set R of the leaderboard at a fixed period T_period (default value is 60 seconds), comparing its current state with the state at the time of the previous snapshot. If a change in the score of any member or the set of members is detected to exceed a preset change percentage threshold p (default value is 5%), the snapshot process is triggered. Furthermore, the system supports custom triggering rules based on business events. Specific business operations (such as leaderboard settlement, event end, etc.) can be configured as snapshot trigger conditions to ensure that data at key time points is completely archived. This hybrid triggering mechanism ensures timely snapshots in high-frequency update scenarios while avoiding unnecessary impacts on Redis performance caused by excessively frequent snapshot operations.

[0027] Furthermore, regarding data replication, in Redis, leaderboard data is stored as a sorted set. When a data snapshot replication is triggered, the system first obtains the current Unix timestamp t as a unique identifier for the snapshot, and then creates a new sorted set St as the snapshot using the Redis ZUNIONSTORE command. The specific command is: ZUNIONSTORESt:rank_snapshot:{t} 1 R WEIGHTS 1, which completely copies all members and their scores from the original sorted set R of the leaderboard to the new set St. Let the original sorted set of the leaderboard be R, then the snapshot replication process can be represented as: St={(mi,si) | (mi,si) in R}, where mi is the member identifier and si is the score corresponding to that member. To ensure data consistency, the entire snapshot replication operation is executed within a Redis MULTI / EXEC transaction. That is, a transaction is first started with MULTI, the ZUNIONSTORE command is executed, and then the transaction is committed with EXEC, ensuring the atomicity of the snapshot creation process and avoiding data inconsistency caused by other concurrent writes during snapshot creation.

[0028] Furthermore, for archive storage, after the ordered set of snapshots *St* is created, the system stores it in the Redis archive space and establishes a multi-level index structure to support efficient retrieval. Specifically, this includes: a time index: using Redis's SortedSet structure, with the snapshot timestamp *t* as the score and the snapshot key *member*, a global snapshot timeline index named *snapshot:index:timeline* is built, supporting fast snapshot location by time range; a leaderboard index: using Redis's Hash structure, with the leaderboard identifier as the field and the corresponding latest snapshot key *value*, a leaderboard-snapshot mapping index is built, named *snapshot:index:ranklist_latest*; and snapshot metadata: using Redis's Hash structure, metadata information is stored for each snapshot, including snapshot creation time, total number of members, data version number, etc., named *snapshot:meta:{t}*. Simultaneously, the system sets a reasonable expiration time for snapshots (default value is 86400 seconds, i.e., 24 hours), implemented through the Redis EXPIRE command, automatically cleaning up after expiration to prevent archived data from growing indefinitely and consuming storage space. For critical snapshots that need to be retained permanently (such as daily settlement snapshots), the system can skip automatic expiration by marking them as persistent snapshots.

[0029] Further, after data updates and numbering, and data snapshot replication, the system performs data update operations on the original ordered set R of the leaderboard. Update operations include, but are not limited to: updating member scores (ZADD command), adding member scores (ZINCRBY command), adding new members (ZADD command), and deleting members (ZREM command). The updated ordered set of the leaderboard is denoted as R'. To ensure data consistency in high-concurrency scenarios, the system uses Redis's WATCH command to implement an optimistic locking mechanism: before updating R, the version of R is monitored via the WATCH command; during the update operation, if R is detected to have been modified by another client during the WATCH period, the transaction fails, and the system automatically retryes, with a maximum of 3 retries. If all 3 retries fail, the system downgrades to using a distributed lock (implemented via SETNX) for exclusive updates. This hierarchical concurrency control mechanism ensures data consistency while minimizing the impact of lock contention on system throughput.

[0030] Furthermore, a unique identifier (UUID) is generated for the updated leaderboard data, denoted as u. The UUID generation uses UUID version 4 (random UUID) algorithm, generating a 128-bit random value based on a high-quality random number generator. The format is a standard 36-character hexadecimal string (e.g., 550e8400-e29b-41d4-a716-446655440000), ensuring global uniqueness in a distributed environment. The UUID is then associated with the updated leaderboard data and stored using a Redis hash table H. The association operation can be represented as: H(u) = R', specifically implemented using the HSET command: HSET rank:uuid_map u ranklist_key:R'. In addition, the system stores both the snapshot timestamp t and the leaderboard version number corresponding to the UUID in the hash table H, i.e., H(u)={ranklist_key: R', snapshot_ts: t, version: v}, so that the validity of the UUID and the version consistency of the data can be verified during subsequent queries. The validity period of the UUID-hash mapping relationship is consistent with the expiration time of the corresponding snapshot, which is set via the EXPIRE command.

[0031] Further, for paginated query processing and homepage queries, when a user requests the first page of data, the system retrieves the data from the latest ordered set R' of the leaderboard. Assuming each page displays n data items, the range of data retrieved is determined using Redis's ZREVRANGE command (sorted from highest to lowest score) or ZRANGE command (sorted from lowest to highest score), depending on the leaderboard's sorting direction (ascending / descending). The first page of data, D1, can be represented as: D1 = Q(R', 0, n-1), meaning starting from index 0, n consecutive data items are retrieved. The specific commands are: ZREVRANGE R' 0 n-1 WITHSCORES (descending order) or ZRANGE R' 0 n-1 WITHSCORES (ascending order). Simultaneously, the system retrieves the UUID u and version information corresponding to the current leaderboard data from the hash table H, encapsulating u and D1 together as response data and returning it to the user. To reduce redundant reads from Redis, the system sets up a short-term cache for homepage data at the front-end or API gateway layer (default cache duration is 5 seconds). The cache key is the leaderboard identifier, and the cache value is the latest homepage data and its UUID. During the cache's validity period, homepage requests for the same leaderboard directly return the cached data, avoiding frequent Redis queries. When the cache expires or a leaderboard update event is detected, the cache becomes invalid, and a new query is performed.

[0032] Furthermore, for subsequent page queries, when a user requests data for page p (p>1), the UUID returned from the first page must be included. The system searches for the corresponding leaderboard snapshot key name from the hash table H based on u. The specific process is as follows: (1) Read the snapshot information corresponding to UUID from the hash table H using the HGET command: HGET rank:uuid_map u, to obtain the snapshot ordered set key name St and the snapshot timestamp t; (2) Calculate the index range of the data for page p in snapshot St based on the offset, which is [(p-1)*n, p*n-1]. Obtain the data within the specified range from snapshot St using the ZREVRANGE or ZRANGE command, specifically: ZREVRANGE St(p-1)*np*n-1 WITHSCORES; (3) Return the query results to the user. When the UUID u carried in the session does not exist in the hash table H (i.e., the snapshot has expired), the system initiates a degradation strategy: it first searches for the available snapshot that is closest to u in time (by querying the snapshot timeline index snapshot:index:timeline). If found, the snapshot is used to complete the subsequent page query and the user is prompted that "the data may have been updated"; if no available snapshot is available, the data of page p is directly queried from the latest ordered set R' of the leaderboard. However, since the data may have changed, the returned result must include a prompt message that "the data is inconsistent with the homepage" to ensure that the user is aware of the data status.

[0033] Furthermore, if a user re-queries the homepage while browsing the leaderboard (e.g., refreshing the page, clicking the "Home" button), the system retrieves the first page data from the latest ordered set R' of the leaderboard, following the same query process as the homepage query. The system generates a new UUID and returns the latest UUID and data, while simultaneously invalidating the snapshot session associated with the old UUID previously held by the client. After receiving the new UUID, subsequent page-turning operations will be based on the snapshot associated with the new UUID. The system periodically cleans up expired snapshots that are no longer referenced by any active sessions. Cleanup strategies include: automatic expiration upon exceeding TTL, proactive cleanup when the active session count reaches zero, and scheduled batch cleanup (executed once per hour) to ensure efficient utilization of archive space.

[0034] The embodiments of this invention also have the following technical effects: Solving the problem of data corruption: Through advanced data snapshot technology and UUID numbering mechanism, this invention fundamentally solves the problem of data corruption in paginated queries caused by real-time changes in leaderboard data, ensuring that users can accurately obtain the required data during paginated queries, avoiding duplicate queries and omissions, and greatly improving the accuracy and consistency of query results. Enhancing user experience: Stable and accurate query results provide users with a high-quality user experience. Users do not need to worry about data corruption when using the leaderboard function, and can browse leaderboard information more smoothly, enhancing user trust and satisfaction with the system. Improving system performance: Utilizing Redis's high-performance data storage and query capabilities, combined with intelligent query algorithms, this invention can quickly complete data snapshot copying, updating, and query operations, meeting user needs in high-concurrency scenarios. At the same time, the multi-level index structure and optimized data storage method further improve the system's query efficiency.

[0035] To achieve the above embodiments, such as Figure 2 As shown, this embodiment also provides a leaderboard data query device 10 based on a snapshot method, including: The leaderboard snapshot archiving module 100 is used to take a snapshot of the current leaderboard data in response to a preset trigger condition, generate snapshot data, and archive and store it. The ranking update association module 200 is used to update the current ranking data, generate a unique identifier for the updated ranking data, and establish an association between the unique identifier and the snapshot data; The homepage data return module 300 is used to respond to the homepage query request, obtain homepage data from the updated ranking data, and return the unique identifier; The snapshot pagination query module 400 is used to respond to subsequent page query requests by finding the corresponding snapshot data based on the unique identifier and obtaining subsequent page data from the snapshot data.

[0036] This invention provides a snapshot-based leaderboard data query device that effectively solves the problem of disordered paginated query data caused by real-time changes in leaderboard data, improves the accuracy and consistency of query results, and enhances the system's query efficiency in high-concurrency scenarios.

[0037] To implement the methods of the above embodiments, the present invention also provides a computer device, such as... Figure 3 As shown, the computer device 600 includes a memory 601 and a processor 602; wherein, the processor 602 reads executable program code stored in the memory 601 to run a program corresponding to the executable program code, so as to implement the various steps of the method described above.

[0038] To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the foregoing embodiments.

[0039] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0040] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

Claims

1. A method for querying ranking data based on snapshots, characterized in that, include: S1, in response to a preset trigger condition, performs a snapshot copy of the current leaderboard data, generates snapshot data, and archives and stores it. S2, update the current ranking data, generate a unique identifier for the updated ranking data, and establish an association between the unique identifier and the snapshot data; S3, in response to the homepage query request, retrieves homepage data from the updated ranking data and returns the unique identifier; S4, in response to a subsequent page query request, find the corresponding snapshot data based on the unique identifier, and obtain the subsequent page data from the snapshot data.

2. The method as described in claim 1, characterized in that, S1 includes: Listen for changes to the ordered set of leaderboard data. When an update operation is detected, check whether the interval between the current time and the last snapshot generation time exceeds the preset minimum snapshot interval threshold. If it does, trigger the snapshot process immediately. Meanwhile, the sorted set of the leaderboard is polled at fixed intervals, and its current state is compared with the state at the previous snapshot time. If the score of any member or the set of members is detected to have changed more than the preset change ratio threshold, the snapshot process is triggered. When the snapshot process is triggered, the current Unix timestamp is obtained as the unique identifier of the snapshot. A new sorted set is created as the snapshot using the Redis ZUNIONSTORE command, and the snapshot replication operation is performed in the Redis MULTI / EXEC transaction. Store the ordered collection of snapshots in Redis's archive space and create a multi-level index structure consisting of time index, leaderboard index, and snapshot metadata. Also, set an expiration time for the snapshots.

3. The method as described in claim 2, characterized in that, The method further includes: Using Redis's SortedSet structure, a global snapshot timeline index is built with the snapshot timestamp as the score and the snapshot key as the member. Using Redis's hash structure, with the leaderboard identifier as the field and the corresponding latest snapshot key as the value, a leaderboard-snapshot mapping index is built; Using Redis's hash structure, metadata information including snapshot creation time, total number of members, and data version number is stored for each snapshot.

4. The method as described in claim 1, characterized in that, The S2 includes: The update operation is performed on the original sorted set of the leaderboard. Before the update, the version of the original sorted set of the leaderboard is monitored by the WATCH command of Redis. If it is detected that the set has been modified by other clients during the WATCH period, the transaction will fail and be automatically retried. The maximum number of retries is set to 3. If all 3 retries fail, the update will be downgraded to using a distributed lock for exclusive update. A universally unique identifier is generated for the updated leaderboard data. The universally unique identifier is associated with the updated leaderboard data and stored using a Redis hash table. The hash table also stores the snapshot timestamp and leaderboard version number corresponding to the universally unique identifier.

5. The method as described in claim 1, characterized in that, The S3 includes: Retrieve the first page of data from the latest sorted leaderboard using the Redis ZREVRANGE or ZRANGE command; Retrieve the universally unique identifier and version information corresponding to the current leaderboard data from the hash table, and encapsulate the universally unique identifier and the first page data together into response data and return it. Set up a short-term cache for homepage data in the front-end or API gateway layer. During the cache validity period, homepage requests for the same ranking list will directly return the cached data.

6. The method as described in claim 1, characterized in that, The S4 includes: The HGET command reads the snapshot sorted set key name and snapshot timestamp corresponding to the universally unique identifier from the hash table. Calculate the index range of subsequent page data in the snapshot ordered set based on the offset, and retrieve the data within the specified range from the snapshot ordered set using the ZREVRANGE command or the ZRANGE command; When the universally unique identifier carried in the session does not exist in the hash table, the nearest available snapshot in time is searched first to complete the subsequent page query. If no nearby snapshot is available, the subsequent page data is directly queried from the latest ordered set of the leaderboard, and data status prompt information is appended to the returned results.

7. The method as described in claim 1, characterized in that, The method further includes: In response to a request to re-query the homepage, retrieve the first page data from the latest ordered set of leaderboards, generate a new universally unique identifier and return it, thus invalidating the snapshot session associated with the old universally unique identifier previously held by the client; Periodically clean up expired snapshots that are no longer referenced by any active sessions. Cleanup strategies include automatic expiration when the time-to-live (TTL) expires, proactive cleanup when the active session count is zero, and scheduled batch cleanup.

8. A ranking data query device based on snapshot method, characterized in that, include: The leaderboard snapshot archiving module is used to take a snapshot copy of the current leaderboard data in response to preset trigger conditions, generate snapshot data, and archive and store it. The ranking update association module is used to update the current ranking data, generate a unique identifier for the updated ranking data, and establish an association between the unique identifier and the snapshot data; The homepage data return module is used to respond to the homepage query request, retrieve homepage data from the updated ranking data, and return the unique identifier; The snapshot pagination query module is used to respond to subsequent page query requests by finding the corresponding snapshot data based on the unique identifier and obtaining subsequent page data from the snapshot data.

9. A computer device, characterized in that, Including processor and memory; The processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the method as described in any one of claims 1-7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

Images