Index update methods, apparatus, media and computing devices

Abstract

This disclosure provides an index update method, apparatus, medium, and computing device. The method includes: real-time monitoring of resource permission information; in response to detecting a change in the permission information, determining a corresponding target resource within the resource based on the new permission information; and updating the permission information recorded in the index of the target resource to the new permission information. This method can shorten the time delay of the index update process and effectively enhance the timeliness of resource maintenance.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of data storage technology, and more specifically, the embodiments of this disclosure relate to an index update method, apparatus, medium, and computing device. Background Technology

[0002] This section is intended to provide background or context for the embodiments of this disclosure as set forth in the claims. The description herein is not intended to be a prior art simply because it is included in this section.

[0003] Currently, resource management platforms can maintain resources in various formats, including text, music, images, and videos. To achieve efficient management and use of resources, these platforms typically set management permissions and access permissions for users and maintain corresponding permission information. Furthermore, to facilitate resource searching, they record the permission information for each resource in the resource index. As the platform operates, the permission information for resources may change, thus requiring updates to the resource index—that is, updating the permission information recorded in the resource index accordingly.

[0004] In related technologies, it is common practice to dump data tables from a database and dump data such as permission information to an offline Hive database on a regular daily basis. Then, the changed permission information is queried from the offline Hive database and the index is updated accordingly. Summary of the Invention

[0005] However, the index update process in the aforementioned technologies has a T+1 delay. For example, if a resource originally belonging to one user is changed to belong to another user today, the corresponding permission information for that resource will not be updated until tomorrow. Clearly, this method of index update has a significant delay and is difficult to effectively handle resource maintenance scenarios with high time sensitivity.

[0006] Therefore, there is a great need for an improved index update method to shorten the time delay in the permission information update process and enhance the timeliness of resource maintenance.

[0007] In this context, embodiments of the present disclosure are intended to provide an index update method, apparatus, medium, and computing device.

[0008] In a first aspect of this disclosure, an index update method is provided, the method comprising:

[0009] Monitor resource permission information in real time;

[0010] In response to the detection of a change in the permission information, the corresponding target resource is determined in the resource based on the new permission information.

[0011] Update the permission information recorded in the index of the target resource to the new permission information.

[0012] In a second aspect of this disclosure, an index updating apparatus is provided, the apparatus comprising:

[0013] The real-time monitoring module is used to monitor resource permission information in real time.

[0014] The resource determination module is used to respond to the detection of a change in the permission information and determine the corresponding target resource in the resource according to the new permission information after the change.

[0015] The information update module is used to update the permission information recorded in the index of the target resource to the new permission information.

[0016] In a third aspect of this disclosure, a medium is provided having a computer program stored thereon, which, when executed by a processor, implements the index update method described in any of the embodiments of the first aspect above.

[0017] In a fourth aspect of this disclosure, a computing device is provided, comprising:

[0018] processor;

[0019] Memory used to store processor-executable instructions;

[0020] The processor implements the index update method described in any of the embodiments of the first aspect by running the executable instructions.

[0021] According to the index update method of this disclosure, the server monitors the permission information of resources in real time, and in response to the monitoring of a change in the permission information, determines the corresponding target resource in the resource according to the new permission information after the change, and then updates the permission information recorded in the index of the target resource to the new permission information after the change.

[0022] In this approach, the server can immediately update the permission information (the old permission information before the change) recorded in the index of the corresponding target resource upon real-time monitoring of permission information changes, thereby achieving real-time synchronization of the resource index. It is understandable that even if the changed permission information corresponds to multiple target resources, the time delay of the server's update process for the corresponding target index can be controlled within milliseconds or even microseconds. Therefore, compared to related technologies, this solution significantly shortens the time delay of the index update process and effectively enhances the timeliness of resource maintenance. Attached Figure Description

[0023] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which:

[0024] Figure 1 A schematic diagram of the structure of a resource management platform according to an embodiment of the present disclosure is shown.

[0025] Figure 2 A flowchart illustrating an index update method according to an embodiment of the present disclosure is shown schematically;

[0026] Figure 3 A schematic diagram illustrating an authorization information storage method according to an embodiment of the present disclosure is shown.

[0027] Figure 4 A schematic diagram illustrating a message processing method according to an embodiment of the present disclosure is shown.

[0028] Figure 5 A schematic diagram illustrating a message queue interaction relationship according to an embodiment of the present disclosure is shown.

[0029] Figure 6 A schematic diagram illustrating another message queue interaction relationship according to an embodiment of the present disclosure is shown.

[0030] Figure 7 A flowchart illustrating an index update method in a scenario of ownership information change according to an embodiment of this disclosure is shown schematically.

[0031] Figure 8 A schematic diagram of a medium according to an embodiment of the present disclosure is shown;

[0032] Figure 9 A block diagram of an index updating apparatus according to an embodiment of the present disclosure is shown schematically;

[0033] Figure 10 A schematic diagram of a computing device according to an embodiment of the present disclosure is shown.

[0034] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0035] The principles and spirit of this disclosure will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement this disclosure, and are not intended to limit the scope of this disclosure in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0036] Those skilled in the art will recognize that embodiments of this disclosure can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0037] According to embodiments of this disclosure, an index update method, apparatus, medium, and computing device are proposed.

[0038] In this document, any number of elements in the accompanying figures is for illustrative purposes and not for limitation, and any naming is for distinction only and has no limiting meaning.

[0039] The principles and spirit of this disclosure will be explained in detail below with reference to several representative embodiments. Invention Overview

[0041] The inventors discovered that in related technical solutions for updating indexes through timed dumps, the index update process has a T+1 delay, which makes it difficult to effectively cope with resource maintenance scenarios with high time sensitivity.

[0042] To address the aforementioned issues, this disclosure provides an index updating method, apparatus, medium, and computing device. Using this solution, the server can immediately update the permission information (the old permission information before the change) recorded in the index of the corresponding target resource upon real-time monitoring of permission information changes, thereby achieving real-time synchronization of the resource index.

[0043] It is understandable that even if the changed permission information corresponds to multiple target resources, the time delay of the server's update process for the corresponding target index can be controlled at the millisecond or even microsecond level. Therefore, compared with related technologies, this solution significantly shortens the time delay of the index update process and effectively enhances the timeliness of resource maintenance.

[0044] After introducing the basic principles of this disclosure, various non-limiting embodiments of this disclosure will be described in detail below.

[0045] Application Scenarios Overview

[0046] It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this disclosure, and the implementation of this disclosure is not limited in any way. On the contrary, the implementation of this disclosure can be applied to any applicable scenario.

[0047] Figure 1 This is a schematic diagram of the architecture of a resource management platform provided in an exemplary embodiment. For example... Figure 1 As shown, the platform may include a network 10, a server 11, a database 12, and several electronic devices, such as mobile phones 13, 14, and 15.

[0048] Mobile phones 13-15 are merely examples of one type of electronic device that a user can use. In reality, users can obviously also use electronic devices such as tablets, laptops, PDAs (Personal Digital Assistants), wearable devices (such as smart glasses, smartwatches, etc.), etc., and one or more embodiments in this specification do not limit this. During operation, the electronic device can run a client-side program of an application (hereinafter referred to as "client") to implement the relevant business functions of the application. For example, when the electronic device runs an application for a resource management platform, it can act as a client for that resource management platform. For instance, mobile phone 15 can act as a resource production client by running the corresponding application, and mobile phones 13 and 14 can act as resource consumption clients by running the corresponding applications. As for network 10, it can include various types of wired or wireless networks.

[0049] It should be noted that the client of the resource management platform can be pre-installed on electronic devices, so that the client can be launched and run on the electronic device; of course, when using online "clients" such as HTML5 technology, there is no need to install the corresponding application on the electronic device to obtain and run the client.

[0050] Server 11 can be a physical server containing an independent host, or it can be a virtual server, cloud server, or other server hosted in a host cluster. During operation, server 11 can run a server-side application of a certain application to realize the relevant business functions of the application. For example, server 11 can be implemented as the server of a resource management platform by running an application of the resource management platform.

[0051] In the resource management platform, a server 11 running a corresponding server-side component can cooperate with mobile phones 13-15 running corresponding clients to implement resource management and consumption schemes. For example, if the resource is music, users can manage or consume the music maintained by the platform (such as listening to audio, viewing lyrics, watching music videos, etc.). In one or more embodiments of the technical solutions in this specification, the server-side component running on server 11 can implement an index update scheme for the managed resources.

[0052] In this embodiment, the resource management platform can not only implement the index update function, but also serve as an integrated functional platform for many other functions, such as real-time monitoring of permission information changes, determining the target index corresponding to the target resource, producing and consuming queue messages, querying or updating the version number in the cache, etc. One or more embodiments in this specification do not limit this.

[0053] According to the index update method of this disclosure, the server can immediately update the permission information (the old permission information before the change) recorded in the index of the corresponding target resource when it detects a change in permission information in real time, thereby achieving real-time synchronization of the resource index. Specifically, the server can cooperate with the database that stores the index to implement the index update scheme.

[0054] Exemplary methods

[0055] It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this disclosure, and the implementation of this disclosure is not limited in any way. On the contrary, the implementation of this disclosure can be applied to any applicable scenario.

[0056] refer to Figure 2 , Figure 2 A flowchart illustrating an index update method according to an embodiment of the present disclosure is shown schematically. The index update method may include the following steps:

[0057] Step S201: Monitor resource permission information in real time.

[0058] First, it should be noted that the resources described in this disclosure can take many forms, such as text, music, pictures, videos, etc. In addition, the users described in this disclosure can be the producers of the resources maintained by the resource management platform (such as singers, artists, UP masters, etc.), the consumers of the resources (such as users who read articles, listen to music, watch videos, etc.), or the backend administrators of the resource management platform, etc. This disclosure does not limit them.

[0059] The raw data of the various resources maintained by the resource management platform is typically large in volume, thus requiring significant storage space. For example, the raw data for song resources can be the audio files, while the raw data for video resources can be both video and audio files. This raw data can be stored locally on the server. Alternatively, to save server storage space, the server can store the raw data of these resources in a database it connects to, and the server can have access permissions to that database.

[0060] To manage and consume resources with corresponding permissions, the server needs to provide users with query functions for these resources. Different users may have different permissions for resources maintained by the resource management platform. To achieve permission management for resources, the resource management platform can maintain permission information for each resource separately. The permission information for any resource can represent at least one permission for that resource, such as query permission, access permission, consumption permission, and / or management permission. Furthermore, to ensure query efficiency and minimize direct database access, the database can maintain basic information for each resource (the amount of basic information for the same resource is usually smaller than the amount of original data) and the correspondence between user permissions and corresponding resources. This allows the database to return basic information about the resource to the requester for initial viewing in response to query requests.

[0061] Specifically, at the data storage level, the server can store the aforementioned basic information and permission information in different data tables. Taking a song as an example, see [link to relevant documentation]. Figure 3 The permission information storage method shown. For example... Figure 3As shown, the server maintains three data tables: a song information table, an authorization table, and a relationship table. The song ID recorded in the song information table can serve as the primary key. The song ID can be a unique identifier for the song within the resource management platform, which can be a unique number assigned to the song by the resource management platform, or a hash or other digital digest of the basic information (i.e., the information in the song information table excluding the song ID). The basic information of any song can include the song name, artist name, release date, genre, number of plays, and interaction volume (such as number of favorites, likes, shares, and comments), etc., which will not be elaborated further. The authorization ID recorded in the authorization table can serve as the primary key of the authorization table. Similarly, the authorization ID can be an authorization number assigned by the resource management platform or a digital digest of the authorization information (the information in the authorization table excluding the authorization ID), which will not be elaborated further. The authorization information recorded in any authorization table can include ownership information, the creation time of the authorization table, creator information, and data signatures of relevant authorized parties, etc., which will not be elaborated further. The aforementioned attribution information is used to characterize the channel to which the song corresponding to the authorization letter belongs, such as which user, department, or organization it belongs to. For example, if the attribution information recorded in an authorization letter corresponds to user U1, then user U1 can have search permissions for the song corresponding to that authorization letter; or, if the attribution information recorded in an authorization letter corresponds to department D1, then all users in department A1 can have search permissions for the song corresponding to that authorization letter.

[0062] It is understandable that, because the primary key of the aforementioned song information table is the song ID, any song information table is only used to record the basic information of one song (i.e., the song corresponding to the song ID). For multiple songs maintained by the resource management platform, the server can maintain separate data information tables corresponding to each song. Of course, any song information table can also record the basic information of multiple songs simultaneously. In this case, to avoid errors in query results, the song ID should not be used as the primary key of the song information table; instead, a primary key that does not uniquely correspond to any single song should be assigned to the song information table. The primary key of the authorization letter is similar and will not be elaborated further below. Figure 3 The scenario shown is used as an example for illustration.

[0063] Typically, a song can belong to multiple channels simultaneously, and a channel can contain multiple songs. Therefore, the relationship between the song information table and the authorization letter is usually many-to-many. The server can maintain the association table to record the correspondence between the song information table and the authorization letter. Each entry in the association table (such as any row) records a set of song IDs and their corresponding authorization letter IDs. Considering the typically many-to-many relationship between the song information table and the authorization letter, the server can use various methods to record the correspondence between song IDs and authorization letter IDs. For example, any row can record one song ID and multiple authorization letter IDs to represent the correspondence between the same song and the multiple channels to which it belongs. In this case, one song can correspond to one row in the association table. Alternatively, any row can record multiple song IDs and one authorization letter ID to represent the correspondence between multiple songs belonging to the same channel and that channel. In this case, one channel can correspond to one row in the association table. For example, any row can also record a song ID and an authorization ID, which are used to represent the correspondence between a song and the channel to which the song belongs. In this case, a song can correspond to at least one row in the association table, and the same channel can also correspond to at least one row in the association table, which will not be elaborated further.

[0064] In addition, the server can maintain indexes for each resource, which can be used to query the corresponding resource in response to user queries. Each resource's index records its resource identifier and permission information, allowing the server to determine whether the resource can be queried, managed, or consumed by the user based on this permission information.

[0065] To ensure accurate retrieval of relevant resources in response to query requests and to implement access control for each resource, the permission information recorded in the index maintained by the server must be consistent with the aforementioned permission information stored in the database (or locally on the server). However, during the implementation of the resource management platform's functions on the server side, the aforementioned permission information stored locally on the server or in the database may change. Therefore, the server needs to promptly update the corresponding permission information recorded in the index after such changes occur. The index update scheme described in this disclosure is used to achieve this purpose.

[0066] The server can deploy a data monitoring component (hereinafter referred to as the monitoring tool) locally. This allows the server to monitor in real-time whether the aforementioned permission information stored locally or in the database has changed. Alternatively, if the permission information is stored in the database, the server can also call the database's own monitoring tool to monitor for changes. Taking the permission information stored in a MySQL database as an example, the monitoring tool can monitor changes to the database's binary log files in real-time and determine the relevant data before and after the change based on the detected changes, such as the table where the changed data is located, the data row, the data type, the data before the change, and the data after the change. Through this method, the server can monitor permission information changes in real-time (i.e., detect permission information change events) and accordingly determine the old permission information before the change and the new permission information after the change. The monitoring tool can be Canal, Maxwell, Mysql_streamer, etc., which will not be elaborated further.

[0067] Step S202: In response to the detected change in the permission information, determine the corresponding target resource in the resource according to the new permission information.

[0068] Step S203: Update the permission information recorded in the index of the target resource to the new permission information.

[0069] As mentioned earlier, the permission information of the resources maintained by the server may include the permission identifier corresponding to the resource identifier. Each permission identifier may correspond to the corresponding ownership information. In this scenario, the permission identifier corresponding to any resource identifier may change, or the ownership information corresponding to any permission identifier may also change.

[0070] like Figure 3As shown, a song ID recorded in the association table corresponds to a corresponding authorization letter ID, and the authorization letter corresponding to any authorization letter ID records the corresponding ownership information. The authorization letter ID corresponding to any song ID in the association table may change—in this case, the server needs to determine the target song corresponding to that song ID and update the old permission information recorded in the song's index, that is, update the old authorization letter ID recorded in the song's index to the new authorization letter ID. Alternatively, the ownership information recorded in any authorization letter ID may also change—in this case, the server needs to determine all target songs corresponding to that authorization letter ID and update the old permission information recorded in the index of each target song, that is, update the old ownership information recorded in the index of each song to the new ownership information. The number of resources corresponding to the above two permission information change scenarios is usually different. The server can use different index update methods to update the permission information recorded in the corresponding indexes respectively. The following describes the two index update methods with reference to the attached diagram:

[0071] 1. Change of permission identifier corresponding to any resource identifier

[0072] As mentioned above, the permission information of a resource may include the permission identifier corresponding to the resource, wherein any permission identifier corresponds to the corresponding ownership information. In this scenario, in response to detecting a change in the permission identifier corresponding to any resource identifier, the server can identify the resource corresponding to that resource identifier as the target resource; furthermore, it can determine the target index of the target resource in the index of the resource based on the resource identifier, and update the ownership information recorded in the target index to the new ownership information corresponding to the new permission identifier.

[0073] Specifically, detecting a change in the permission identifier corresponding to any resource identifier can be achieved by detecting a change in the permission identifier corresponding to any resource identifier recorded in the first relationship table. This first relationship table can be used to record the correspondence between resource identifiers and permission identifiers. Figure 3 For example, the first relation table can be Figure 3 The association table shown records the correspondence between song IDs and authorization IDs. Therefore, when the server detects a change in the authorization ID corresponding to any song ID in this association table, it can identify the song corresponding to that song ID as the target song. In this way, the server can accurately and quickly determine the target resource whose permission identifier has changed using the pre-recorded correspondence in the first association table, thereby maximizing index update efficiency.

[0074] In one embodiment, the server can, in response to detecting a change in the permission identifier corresponding to any resource identifier recorded in the first relation table, generate a first change message containing the resource identifier and the new permission identifier. Then, in response to the first change message, the server can query the new ownership information corresponding to the new permission identifier in a second relation table. The second relation table records the correspondence between permission identifiers and ownership information. The server can monitor these changes in real time using tools such as Canal, Maxwell, and Mysql_streamer. Specific monitoring methods can be found in related technical documents and will not be elaborated here.

[0075] by Figure 3 For example, the first relationship table and the second relationship table can be the association table and the authorization certificate, respectively. When the server detects a change in the authorization certificate ID corresponding to any song ID in the association table in real time, it can generate a first change message based on the detected song ID and the new authorization certificate ID. Then, in response to this message, it can query the ownership information recorded in the authorization certificate corresponding to the new authorization certificate ID and use the queried ownership information as the new ownership information corresponding to the new authorization certificate ID.

[0076] In another embodiment, the server can, in response to detecting a change in the permission identifier corresponding to any resource identifier recorded in the first relationship table, generate a second change message containing that resource identifier. Then, in response to the second change message, the server can query the first relationship table for the new permission identifier corresponding to the changed resource identifier, and query the second relationship table for the new ownership information corresponding to the new permission identifier. Still using... Figure 3 For example, if the server detects a change in the authorization letter ID corresponding to any song ID in the association table in real time, it can generate a second change message based on the detected song ID. Then, in response to the message, it can query the association table for the new authorization letter ID corresponding to the song ID after the change, and then query the ownership information recorded in the authorization letter corresponding to the new authorization letter ID. The queried ownership information is then used as the new ownership information corresponding to the new authorization letter ID.

[0077] Furthermore, after retrieving new ownership information corresponding to any resource identifier through the methods described in the above embodiments, the server can generate a first update message based on the resource identifier and the retrieved new ownership information. This message can be used to trigger the updating of the old ownership information recorded in the target index to the new ownership information. For example, the server can respond to this message by updating the old ownership information recorded in the target index to the new ownership information.

[0078] Based on the quantitative relationship between the first and second relationship tables, the server can query the new attribution information corresponding to any of the permission identifiers using different methods. For example, if the first relationship table corresponds to one second relationship table, the server can query the new attribution information corresponding to any of the permission identifiers in that second relationship table. As another example, if the first relationship table corresponds to multiple second relationship tables, the server can determine the corresponding second relationship table based on any of the permission identifiers and identify the attribution information recorded in the determined second relationship table as the new attribution information.

[0079] The server may detect one or more permission information changes (i.e., data changes) within a short period. Each permission change requires identifying at least one target resource, meaning at least one target resource's index needs to be updated. To ensure orderly and efficient index updates, the server can use a message queue. Figure 4 For example, when the monitoring tool detects any change in permission information in real time, it can generate a permission update message based on the detected change and send the message to the corresponding message queue. Then, the message consumption component deployed on the server can obtain the message, process it accordingly, and update the index of the target resource based on the obtained new permission information. For both of the aforementioned permission information change methods, the server can use message queues for index updates. The message queues differ depending on the permission information change method. Here, we will first describe the message queue and corresponding message processing method for the first permission information change method (the corresponding method for the second permission information change method can be found in the subsequent embodiments, and will not be elaborated here).

[0080] For example, corresponding functional components can be pre-deployed on the server side to act as producers and consumers of the first change message, second change message, and first update message, respectively. Thus, for any one of these messages, the producer can send the generated message to a preset message queue; correspondingly, the consumer can retrieve and consume the message from the preset message queue. Any of these message queues can be Kafka, Nydus, RocketMQ, RabbitMQ, ActiveMQ, ZeroMQ, MetaMQ, etc. Furthermore, if the permission information is stored in a MySQL database, the message queue can also be a message queue implemented by the database itself, which will not be elaborated further.

[0081] like Figure 5 The message queues shown can be used as Figure 4 The specific implementation of the "message queue" shown is illustrated. Combined with... Figure 4 and Figure 5 As can be seen, the monitoring tool, acting as the producer of permission change messages, can send these messages to the permission identifier change message queue. The message consumer can then respond to the received message by generating a first or second change message, thus acting as the producer of the first or second change message. Furthermore, the producer can send the generated first or second change message to the change message queue. After retrieving the corresponding message from this queue, the consumer of the first or second change message can respond to the message by generating a first update message and sending it to the update message queue. The consumer of this message then responds to the first update message retrieved from this queue by generating a new permission message to update the index; this will not be elaborated further.

[0082] Since the server can respond to multiple permission information change events corresponding to different resources simultaneously, each of the above message queues can record multiple messages at the same time. For example, the permission identifier change message queue can record multiple permission change messages simultaneously, the change message queue can record multiple first change messages and / or multiple second change messages simultaneously, and the update message queue can record multiple first update messages simultaneously. Updating the index through the above message queues allows for asynchronous index updates because the producers and consumers of each message are independent of each other, thereby improving index update efficiency.

[0083] Furthermore, to further improve the index update message performance, the various functional components acting as the producers and consumers mentioned above can be deployed separately in different processes on the server. For example, a running server can launch multiple processes in its local memory, with each process running the program code of its respective functional component, thus deploying the functional components in different processes. It is understood that, in implementing its function, a functional component deployed in any process can use the storage, network, and / or computing resources corresponding to that process, without using the resources of other processes. This resource isolation between processes achieves isolation between the functional components.

[0084] For any of the resource identifiers whose corresponding permission information has changed, after the server determines the resource identifier and its corresponding new ownership information through the above embodiments, the server can query the corresponding target index (i.e., the index of the target resource corresponding to the resource identifier) ​​in the resource's index according to the resource identifier, and update the old ownership information recorded in the index to the new ownership information. This concludes the description of the index update process in the scenario of a change in the permission identifier corresponding to any resource identifier.

[0085] 2. Change of ownership information corresponding to any permission identifier

[0086] As mentioned above, the permission information of the resource includes the ownership information corresponding to the resource, and each ownership information corresponds to a corresponding permission identifier. In this scenario, in response to detecting a change in the ownership information corresponding to any permission identifier, the server can determine at least one resource corresponding to that permission identifier as the target resource; furthermore, it can determine at least one target index corresponding to the target resource from the index of the above resources, and update the ownership information recorded in each target index to the changed new ownership information.

[0087] The monitoring of any change in ownership information corresponding to any permission identifier can be defined as monitoring a change in ownership information corresponding to any permission identifier recorded in a second relationship table. As mentioned earlier, this second relationship table can be used to record the correspondence between permission identifiers and ownership information. Figure 3 For example, this second relation table can be Figure 3 The authorization document shown records the correspondence between authorization document IDs and ownership information. Therefore, when the server detects a change in ownership information recorded in any authorization document in real time, it can first determine the authorization document ID, then identify the songs corresponding to each song ID as target songs, and then determine the target index corresponding to each target song from the index based on the song ID of each target song. The old ownership information recorded in each target index is then updated to the new ownership information recorded in the authorization document. In this way, the server can accurately and quickly determine the target resource corresponding to the permission identifier whose ownership information has changed, using the pre-recorded correspondence in the second relationship table, thereby maximizing index update efficiency.

[0088] In one embodiment, in response to detecting a change in ownership information corresponding to any permission identifier recorded in the second relation table, the server can generate a third change message containing the detected permission identifier. Further, the server can determine at least one resource identifier corresponding to the permission identifier and the changed ownership information through various methods.

[0089] For example, as an exemplary embodiment, the server can respond to the aforementioned third change message by querying at least one resource identifier corresponding to any of the permission identifiers in a first relation table, and generating a first permission message containing the permission identifier and the queried at least one resource identifier. Then, in response to this message, it can query the changed new ownership information corresponding to any of the aforementioned permission identifiers in a second relation table, wherein the first relation table is used to record the correspondence between resource identifiers and permission identifiers. In this way, the resource identifier of each target resource can be determined by the consumer of the first permission message. Figure 3For example, the first relationship table and the second relationship table can be the association table and the authorization letter, respectively. When the server detects a change in the ownership information recorded in any authorization letter in real time, it can query the association table for each song ID corresponding to the authorization letter ID based on the authorization letter ID, generate a first permission message containing the authorization letter ID and the queried song IDs, and then query the new ownership information recorded in the authorization letter based on the message.

[0090] For example, as another exemplary embodiment, the server can also query the corresponding new ownership information in the second relationship table in response to the third change message, and generate a second permission message containing any of the permission identifiers and the queried new ownership information. Then, in response to this message, it can query at least one resource identifier corresponding to the aforementioned permission identifier in the first relationship table. In this way, the resource identifier of each target resource can be determined by the consumer of the third permission message. Still using... Figure 3 For example, if the server detects a change in the ownership information recorded in any authorization letter in real time, it can query the new ownership information recorded in the authorization letter based on the authorization letter ID, and generate a second permission message containing the authorization letter ID and the queried new ownership information. Then, in response to the message, it can query the song IDs corresponding to the aforementioned authorization letter ID in the association table.

[0091] Through the above method, the server can determine the new ownership information and at least one corresponding resource identifier (i.e., the resource identifier of each target resource). Further, the server can generate a second update message containing the new ownership information and the at least one resource identifier. This message can be used to trigger the updating of the ownership information recorded in each target index to the new ownership information. For example, the server can generate a second update message containing the aforementioned authorization letter ID and the queried song IDs, and then, in response to this message, update the index of the song corresponding to each song ID, that is, update the old ownership information recorded in the index of each song to the new ownership information recorded in the message.

[0092] like Figure 6 The message queues shown can be used as Figure 4 The specific implementation of the "message queue" shown is illustrated. Combined with... Figure 4 and Figure 6As can be seen, the monitoring tool, acting as the producer of permission change messages, can send these messages to the permission information change message queue. The consumer of these messages can then respond to the received message by generating either a first permission message or a second permission message, thus acting as the producer of either message. Furthermore, the producer can send the generated first or second permission message to the permission message queue, so that the consumer can respond by generating a second update message and sending it to the update message queue. The consumer of the update message can then respond by generating a new permission message to update the index. This process will not be elaborated further.

[0093] Based on the quantitative relationship between the first and second relationship tables, the server can query the new ownership information corresponding to any of the permission identifiers using different methods. For example, if the first relationship table corresponds to a second relationship table, the server can query the new ownership information corresponding to the permission identifier in the second relationship table. Figure 3 As shown, when the same association table corresponds to an authorization letter, the server can query the ownership information corresponding to the monitored authorization letter ID within that authorization letter and determine this ownership information as the new ownership information. For example, when the first relationship table corresponds to multiple second relationship tables, the server can determine the corresponding second relationship table based on any of the permission identifiers and determine the ownership information recorded in the determined second relationship table as the new ownership information. Figure 3 As shown, when multiple authorization letters correspond to the same association table, the server can determine the authorization letter whose ownership information has changed based on the monitored authorization letter ID, and determine the ownership information recorded in the authorization letter as the new ownership information.

[0094] Furthermore, based on the quantitative relationship between song IDs and authorization letter IDs recorded in the association table, the server can determine the target song corresponding to any given authorization letter ID using different methods. For example, if any authorization letter ID corresponds to one song ID, the server can use the song corresponding to that song ID as the target song; or, if any authorization letter ID corresponds to multiple song IDs, the server can use the songs corresponding to each song ID as target songs. In this way, the server can update the index of each target song corresponding to any authorization letter if the ownership information recorded in any authorization letter changes.

[0095] The above method enables real-time updates of the index corresponding to the target resource. Since the same attribution information often corresponds to multiple resource identifiers, the process of updating the index in response to real-time monitored permission information change events may take a considerable amount of time. For example, if there are tens of thousands of songs under the same attribution channel, even if the update time for the index corresponding to each song is in milliseconds, the processing time required to update all songs after the attribution channel changes could be in seconds or even minutes.

[0096] In response, the inventors further discovered that when the same ownership information changes frequently, updating the index using a message queue generates and consumes a large number of messages during the update process. However, due to the time-consuming nature of this process, some of these messages are meaningless and do not require generation or consumption. For example, if the ownership information for 100,000 songs changes simultaneously, 100,000 permission change messages might be generated that need to be processed by the server. However, if the ownership information changes again after processing 20,000 of these messages, the remaining 80,000 permission change messages become meaningless and do not need to be processed. In this case, only the new 100,000 permission change messages corresponding to the latest change are meaningful messages that need to be processed.

[0097] Based on the above analysis, to minimize the number of meaningless messages processed during index updates and thus improve index update efficiency, a message versioning mechanism can be added to the existing message queue mechanism. This allows for the discarding of older versions of messages corresponding to historical changes when ownership information changes frequently, processing only the latest version of messages corresponding to the most recent change. This significantly reduces the actual number of messages that need to be processed in this scenario. The mechanism is explained in detail below:

[0098] In one embodiment, in response to detecting a change in ownership information corresponding to any permission identifier recorded in the second relation table, the server can determine the permission version number corresponding to that permission identifier. This determined permission version number is used to be included in the generated third change message and second update message, and also in the generated first permission message or second permission message. In other words, when the server generates the third change message, first permission message, and second update message in response to the same detected permission information change, the permission version number is included in each of these messages; or, when the server generates the third change message, second permission message, and second update message in response to the same detected permission information change, the permission version number can be included in each of these messages. In this way, the same permission version number can be set for all messages generated during the index update process in response to the same permission information change—obviously, for multiple different messages, if they contain the same permission version number, then each message is used to respond to the index update process for the same permission information change event.

[0099] Accordingly, if any of the third change message, first permission message, second permission message, and second update message has been generated, the server can determine the latest version number corresponding to the permission identifier recorded in the message at the current moment. If the determined latest version number matches the permission version number contained in the message, the server sends the message to the corresponding message queue so that subsequent consumers can respond to the message and perform appropriate processing. Therefore, the permission version number contained in any generated message is the same as the permission version number corresponding to any permission identifier determined before the message was generated. Considering that the process of generating messages takes time, after any message is generated, the consistency between the permission version number contained in the message and the latest version number corresponding to the permission identifier contained in the message can be used to determine whether the generated message is the latest message (i.e., whether the permission information corresponding to the message has been changed). If the two are consistent (i.e., the permission version number and the latest version number are the same), it indicates that the message is the latest message, and the message can be sent. Otherwise, if the two are inconsistent (i.e., the permission version number and the latest version number are different), it indicates that the message is not the latest message (i.e., the message has expired), and the message can be rejected to avoid sending meaningless messages to downstream message consumers, thereby reducing the message processing pressure and improving efficiency downstream.

[0100] The server can record the permission version number corresponding to each monitored permission information change event in a cache. For example, the permission version number can be recorded in the cache in the form of key-value pairs, where the key can be the permission identifier, such as the aforementioned authorization ID; and the value can be the permission version number. Furthermore, the cache can be a local cache on the server, a distributed cache such as Redis, or a local cache of the database that records the permission information; this embodiment does not limit this to any particular type.

[0101] Based on the aforementioned caching, before generating the third change message, the server can determine the permission version number corresponding to any of the permission identifiers in various ways. For example, the server can first query the cache for the permission version number corresponding to the permission identifier, and then process the query results accordingly: if the cache does not record a historical version number corresponding to any of the permission identifiers, the server can determine a first preset value as the permission version number corresponding to the permission identifier. Thus, the first preset value is the initial value of the permission version number of the permission information corresponding to the permission identifier. Alternatively, the server can also record this first preset value in the cache, such as storing the permission identifier and the first preset value in a key-value pair format, which will not be elaborated further. Conversely, if the cache records a historical version number corresponding to any of the permission identifiers, the server can determine the permission version number corresponding to any of the permission identifiers based on that historical version number. For example, if the historical version number exceeds the preset version number range, the server can determine the second preset value as the permission version number corresponding to any permission identifier; while if the historical version number does not exceed the preset version number range, the server can determine a version number that does not exceed the preset version number range based on the historical version number, and use it as the version number corresponding to any permission identifier.

[0102] by Figure 3 For example, before generating a corresponding third change message in response to a change in ownership information of any authorization certificate record, the server can query the cache for the historical version number corresponding to the authorization certificate ID. If no historical version number exists in the cache, it indicates that the ownership information may be changing for the first time. In this case, for example, 0 can be determined as the permission version number corresponding to the authorization certificate ID. Thus, on the one hand, a third change message containing the authorization certificate ID and the permission version number can be generated; on the other hand, the permission version number can be recorded in the cache as the historical version number corresponding to the authorization certificate ID. Conversely, if a historical version number exists in the cache, it indicates that the ownership information has changed. In this case, 1 can be added to the historical version number to obtain the permission version number corresponding to the authorization certificate ID, and the historical version number in the cache can be updated according to the permission version number (i.e., the historical version number is also added by 1).

[0103] Of course, the version number after adding 1 should not exceed the preset version range. If the version number after adding 1 exceeds the preset version range, the second preset value can be determined as the permission version number corresponding to any of the permission identifiers. For example, if the historical version number is recorded as a 32-bit integer, the corresponding preset version number range can be [0, +2147483647]. If the historical version number queried by the server is less than +2147483647, the version number after adding 1 to the historical version number can be used as the permission version number corresponding to any of the permission identifiers. If the historical version number queried by the server is equal to +2147483647, then the version number after adding 1 to the historical version number, +2147483648, exceeds the above-mentioned preset version number range. In this case, 1 can be used as the permission version number corresponding to any of the permission identifiers. Of course, 0 can also be used as the permission version number corresponding to any of the permission identifiers, that is, the first preset value and the second preset value can be equal, which will not be elaborated further.

[0104] It should be noted that the permission version number corresponding to any of the permission identifiers determined in the above manner will be included in the generated third change message. When the server consumes this message to generate subsequent messages (first permission message, second permission message, or second update message), it can directly use the permission version number contained in the message without querying it again. For example, when generating a first permission message in response to a third change message, the server (specifically, the producer of the first permission message) can first determine the permission version number contained in the second change message and generate a first permission message containing that permission version number; similarly, when generating a second update message in response to a first permission message, the server (specifically, the producer of the second update message) can first determine the permission version number contained in the first permission message and generate a second update message containing that permission version number.

[0105] As can be seen from the above process, all subsequent messages corresponding to the same third change message contain the same permission version number. In fact, because the permission identifier determined in response to the same permission information change event is the same, the permission version number determined based on that permission identifier is also the same. Consequently, the permission version numbers contained in each third change message generated for each target resource are also the same (i.e., the permission version number corresponding to that permission identifier). This ensures that each third change message generated in response to the same permission information change event for each target resource, and all its corresponding messages, contain the same permission version number, which helps reduce the production and consumption of meaningless messages.

[0106] As can be seen, the historical version number corresponding to any permission identifier stored in the cache is always the latest version number corresponding to that permission identifier. Through the aforementioned comparison and update process of version numbers, it can be seen that even if any permission identifier changes multiple times, the historical version number corresponding to that permission identifier will also be updated accordingly, thus effectively ensuring the smooth operation of the version mechanism.

[0107] Similar to the process of generating the third change message described above, when the server receives any of the third change message, the first permission message, the second permission message, and the second update message, it can first determine whether the message is the latest message and perform corresponding processing. For example, when receiving any of the above messages corresponding to any permission identifier, the server can determine the permission version number contained in the message and the latest version number corresponding to the permission identifier recorded in the cache. If the permission version number and the latest version number are inconsistent, it can be determined that the message is not the latest message corresponding to any of the above permission identifiers, and the message can be discarded to avoid subsequent meaningless responses to the message. Conversely, if the permission version number and the latest version number are consistent, it can be determined that the message is indeed the latest message corresponding to any of the above permission identifiers, and the message can be responded to normally.

[0108] In addition, upon receiving the aforementioned second update message, the server can determine the permission version number contained in the message and the latest version number corresponding to the permission identifier recorded in the cache. Furthermore, if the permission version number is consistent with the latest version number, the ownership information recorded in each target index can be updated to the new ownership information, thereby updating the target index.

[0109] As mentioned earlier, the resource index records resource identifiers and corresponding permission information. In this scenario, the index of any resource can record the resource identifier and the corresponding ownership information. Specifically, the server can update the ownership information recorded in the index of each target resource based on the resource identifiers of each target resource determined in the above embodiments and the changed new ownership information. For example, for any target resource, the server can query the target index of the target resource from the resource index based on its resource identifier, and then update the old ownership information recorded in the target index to the new ownership information. It can be understood that the process of updating the old ownership information is the process of writing the new ownership information into the corresponding storage space to replace (or overwrite) the old ownership information, which will not be elaborated further. Thus, the process of updating the index of each target resource corresponding to any permission identifier in response to real-time monitoring of a change in the ownership information corresponding to any permission identifier is completed.

[0110] Based on the index updated through any of the above embodiments, the server can respond to a received resource query request, query the corresponding resource, and return it to the requester. Taking any user as an example, the server can determine the user's identity information (such as the organization to which the user belongs) and the resource identifier of the resource to be obtained contained in the resource query request. Then, it can query the permission information of the resource to be obtained in the index based on the resource identifier, and then determine whether the user's identity information matches the permission information of the resource to be obtained: if the two match, such as the organization identifier of the user's organization recorded in the permission information, it indicates that the user has the query permission for the resource, and the resource information of the resource to be obtained (such as the aforementioned basic information) can be returned to the user; otherwise, if the two do not match, it indicates that the user does not have the query permission for the resource, and a prompt message can be returned to the user, and the resource information of the resource to be obtained can be refused to be returned to the user, so as to realize the permission management of the resource. Of course, the permission information recorded in the above index can also correspond to access permissions, consumption permissions, and / or management permissions for the resource, etc., which will not be elaborated further.

[0111] Through the aforementioned embodiments, the server can immediately update the permission information (the old permission information before the change) recorded in the index of the corresponding target resource upon real-time monitoring of permission information changes, thereby achieving real-time synchronization of the resource index. It is understood that even if the changed permission information corresponds to multiple target resources, the time delay of the server's update process for the corresponding target index can be controlled within milliseconds or even microseconds. Therefore, compared to related technologies, this solution significantly shortens the time delay of the index update process and effectively enhances the timeliness of resource maintenance.

[0112] For scenarios where changes in ownership information corresponding to any permission identifier are detected in real time, the following example... Figure 3 The resources shown are songs, Figure 7 The following example illustrates the index update process using a message queue. Figure 7 The index update scheme shown can be applied to the server side of a resource management platform. Each step can be completed by corresponding functional components deployed on the server side. The listening tools, message producers, and consumers involved in the following process can all be considered as functional components deployed on the server side. This process includes the following steps:

[0113] Step S701: The ownership information recorded in any authorization document stored locally on the server or in the database changes.

[0114] As the resource management platform operates, the permission information corresponding to resources may change. Changes to the ownership information recorded in any authorization certificate may be initiated by a user with management authority over that authorization certificate, or they may be related changes caused by the resource management platform's server performing other business operations. This disclosed embodiment does not limit the scope of such changes.

[0115] In step S702, the monitoring tool, upon detecting the aforementioned change, generates an authorization limit change message and sends it to the permission information change message queue.

[0116] The monitoring tool can determine the relevant data before and after the change based on the changes monitored in real time, such as the data table where the changed data is located, the data row, the data type, the data before the change, and the data after the change, etc., which will not be elaborated further. Based on this, the server can determine the old ownership information before the change and the new ownership information after the change. The permission change message generated by the monitoring tool (corresponding to the third change message in the aforementioned embodiment) may contain the aforementioned relevant data.

[0117] Furthermore, the process by which the monitoring tool sends the authorization limit change message to the permission information change message queue is equivalent to writing the message to that message queue; correspondingly, the process by which the message consumer retrieves the authorization limit change message from the permission information change message queue is equivalent to reading the message from that message queue. The specific processes of writing and reading described above can be found in relevant technical documents and will not be repeated here. The processes of writing any message to the corresponding message queue and reading any message from the message queue in the following steps are similar and will not be repeated here.

[0118] Step S703: The consumer of the permission change message determines the authorization ID of any of the authorization documents that has been changed.

[0119] Based on the relevant data before and after the above changes, consumers of permission change messages can determine the authorization ID of any of the authorization documents that have been changed (i.e., the authorization document where the changed ownership information is located).

[0120] Alternatively, the authorization ID can be determined by the aforementioned monitoring tool and included in the generated permission change message, in which case step S703 can be omitted.

[0121] In step S704, the consumer receiving the permission change message queries the historical version number in the cache based on the authorization ID.

[0122] To further differentiate the timeliness of subsequent messages using version numbers, consumers of permission change messages can query historical version numbers in the cache based on the retrieved authorization letter ID (or the authorization letter ID contained in the permission change message). The ownership information recorded in the authorization letter corresponding to the authorization letter ID may be the first change or not; therefore, the cache may or may not contain historical version numbers corresponding to that authorization letter ID.

[0123] Step S705: The consumer of the permission change message checks whether the historical version number corresponding to the authorization ID exists in the cache.

[0124] In step S706, if the historical version number corresponding to the authorization ID does not exist in the cache, the consumer of the permission change message determines that the permission version number is 0 and records the permission version number in the cache.

[0125] If the cache does not contain a historical version number corresponding to the authorization certificate ID, it indicates that the ownership information recorded in the authorization certificate corresponding to the authorization certificate ID may be changing for the first time. In this case, the permission version number can be determined to be the preset value of 0. Alternatively, 0 can be recorded in the cache as the historical version number corresponding to the authorization certificate ID.

[0126] Step S707: If the historical version number corresponding to the authorization ID exists in the cache, the consumer of the permission change message determines that the permission version number is the historical version number plus 1, and uses the permission version number to update the historical version number in the cache.

[0127] The presence of a historical version number corresponding to the authorization ID in the cache indicates that the ownership information recorded in the authorization document corresponding to the authorization ID is not the first change. In this case, the permission version number can be determined to be the historical version number plus 1. Similarly, the historical version number recorded in the cache can be updated using this historical version number plus 1.

[0128] In step S708, the consumer of the permission change message generates an authorization message based on the determined authorization ID and permission version number, and sends the message to the authorization message queue.

[0129] Step S709: The consumer of the authorization message queries the song ID of the target song in the association table in batches based on the authorization ID.

[0130] In step S710, the consumer of the authorization letter message generates a song message based on the song ID, authorization letter ID, and message version number.

[0131] After reading the authorization message from the authorization message queue, the server can extract the authorization ID and permission version number from the message. Then, based on the authorization ID, it can batch query the song IDs of the target songs in the association table, and thus generate a song message containing the song ID, authorization ID, and message version number.

[0132] The song IDs retrieved in the batch query can be the song IDs of all target songs corresponding to the authorization letter ID. Based on this, any song message generated by the consumer can include the authorization letter ID, the message version number, and the song IDs of multiple target songs. In this case, the song message corresponds to multiple target songs simultaneously, and subsequent steps can complete the index update for all multiple target songs at once by processing this message. Alternatively, each song message generated by the consumer can also include the authorization letter ID, the message version number, and the song ID of one target song respectively. In this case, each song message uniquely corresponds to one target song, and subsequent steps can complete the index update for that target song by processing this message.

[0133] In step S711, the consumer of the authorization message determines whether the latest version number recorded in the cache is consistent with the permission version number recorded in the message.

[0134] For any song message obtained, the consumer of the message can determine the permission version number contained in the message, and query the corresponding latest version number in the cache according to the authorization ID recorded in the message; and then determine whether the latest version number is consistent with the permission version number.

[0135] Normally, during the period from when the server generates the aforementioned authorization message to when it queries the latest version number, if the ownership information recorded in the authorization letter corresponding to the authorization letter ID has not changed again, the latest version number recorded in the cache should be consistent with the permission version number contained in the authorization letter message. Otherwise, if the ownership information recorded in the authorization letter corresponding to the authorization letter ID has changed during the aforementioned period, the latest version number recorded in the cache should be inconsistent with the permission version number contained in the authorization letter message, such as latest version number = authorization version number + i (where i can be the number of changes that have occurred during this period).

[0136] Based on the above analysis, if the latest version number and the permission version number are inconsistent, it indicates that the ownership information recorded in the authorization letter corresponding to the authorization letter ID has changed during the aforementioned time period. In this case, the message has expired, and there is no need for a subsequent response to the authorization letter message (even if a response were given, it would be meaningless). Therefore, to avoid unnecessary resource consumption, the current index update process can be terminated directly. Otherwise, if the latest version number and the permission version number are consistent, the process can proceed to step S712.

[0137] In step S712, the consumer of the authorization message sends the song message to the song message queue.

[0138] In step S713, the consumer of the song message queries the latest version number in the cache.

[0139] In step S714, the consumer of the song message determines whether the latest version number recorded in the cache is consistent with the permission version number recorded in the message.

[0140] After reading the song message from the song message queue, the consumer of the song message can query the latest version number recorded in the cache at the current time in response to the message, and determine the consistency between the latest version number and the permission version number recorded in the song message.

[0141] Similar to step S711 above, if the latest version number does not match the permission version number recorded in the song message, it indicates that the song message has expired at the current moment, and the current index update process can be terminated directly. Otherwise, if the latest version number matches the permission version number, the process can proceed to step S715.

[0142] In step S715, if the latest version number is inconsistent with the permission version number recorded in the song message, the consumer of the song message queries the target authorization letter based on the authorization letter ID and determines the new ownership information recorded in the target authorization letter.

[0143] Consumers of song messages can query the target authorization letter corresponding to the authorization letter ID from multiple authorization letters, and determine the ownership information recorded in the authorization letter as the new ownership information after the change.

[0144] Step S716: If the latest version number is consistent with the permission version number recorded in the song message, the server updates the old ownership information in the target index according to the new ownership information.

[0145] After the new attribution information is determined, the consumer of the song message can query the target index corresponding to the target resource in the resource index based on the song ID recorded in the song message, and update the old attribution information recorded in the target index with the new attribution information. Alternatively, the consumer of the song message can further generate an update message containing the song ID and the new attribution information, and send the message to the update message queue, so that the consumer of the message can query the target index corresponding to the target resource in the resource index based on the song ID recorded in the song message, and update the old attribution information recorded in the target index with the new attribution information.

[0146] According to the index update method of this disclosure, the server monitors the permission information of resources in real time, and in response to the monitoring of a change in the permission information, determines the corresponding target resource in the resource according to the new permission information after the change, and then updates the permission information recorded in the index of the target resource to the new permission information after the change.

[0147] In this approach, the server can immediately update the permission information (the old permission information before the change) recorded in the index of the corresponding target resource upon real-time monitoring of permission information changes, thereby achieving real-time synchronization of the resource index. It is understandable that even if the changed permission information corresponds to multiple target resources, the time delay of the server's update process for the corresponding target index can be controlled within milliseconds or even microseconds. Therefore, compared to related technologies, this solution significantly shortens the time delay of the index update process and effectively enhances the timeliness of resource maintenance.

[0148] Exemplary media

[0149] After introducing the methods of exemplary embodiments of this disclosure, the following references are made. Figure 8 The medium for exemplary embodiments of this disclosure will be described.

[0150] In this exemplary embodiment, the above method can be implemented by a program product, such as a portable compact disc read-only memory (CD-ROM) including program code, which can run on a device, such as a personal computer. However, the program product disclosed herein is not limited thereto. In this document, the readable medium 80 can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0151] The program product can take the form of any combination of one or more readable media. The readable medium 80 can be a readable signal medium or a readable medium in general. The readable medium 80 can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable media (a non-exhaustive list) include: electrical connections with one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0152] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable medium that can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0153] The program code contained on the readable medium 80 can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RE, etc., or any suitable combination thereof.

[0154] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0155] Exemplary device

[0156] Having introduced the medium of exemplary embodiments of this disclosure, the following references are made to... Figure 9 The apparatus of exemplary embodiments of this disclosure will be described. The specific manner in which each functional module performs its operations and the specific functions achieved after the operations are performed have been described in detail in the foregoing embodiments of the index update method, and will not be elaborated further here.

[0157] Figure 9 A block diagram of an index updating apparatus according to an embodiment of the present disclosure is shown schematically. The index updating apparatus may include:

[0158] The real-time monitoring module 901 is used to monitor resource permission information in real time.

[0159] The resource determination module 902 is used to determine the corresponding target resource in the resource according to the new permission information after the change is detected;

[0160] The information update module 903 is used to update the permission information recorded in the index of the target resource to the new permission information.

[0161] Optionally, the permission information of the resource includes the permission identifier corresponding to the resource identifier of the resource, and any permission identifier corresponds to the corresponding ownership information;

[0162] The resource determination module 902 is further configured to: in response to detecting a change in the permission identifier corresponding to any resource identifier, determine the resource corresponding to any resource identifier as the target resource;

[0163] The resource determination module 902 is further configured to: determine the target index of the target resource in the index of the resource according to any resource identifier, and update the ownership information recorded in the target index to the new ownership information corresponding to the changed new permission identifier.

[0164] Optionally, the resource determination module 902 is further configured to:

[0165] The system detects any change in the permission identifier corresponding to any resource identifier recorded in the first relationship table, which is used to record the correspondence between resource identifiers and permission identifiers.

[0166] Optionally, in response to detecting a change in the permission identifier corresponding to any resource identifier recorded in the first relation table, the apparatus further includes:

[0167] The first generation module 904 is configured to generate a first change message containing any of the resource identifiers and the modified new permission identifier, and, in response to the first change message, query a second relation table for new ownership information corresponding to the new permission identifier; or, generate a second change message containing any of the resource identifiers, and, in response to the second change message, query the first relation table for the modified new permission identifier corresponding to the any of the resource identifiers, and query the second relation table for new ownership information corresponding to the new permission identifier; wherein, the second relation table is used to record the correspondence between permission identifiers and ownership information;

[0168] The second generation module 905 is used to generate a first update message containing any of the resource identifiers and the queried new ownership information. The first update message is used to trigger the updating of the old ownership information recorded in the target index to the new ownership information corresponding to the changed new permission identifier.

[0169] Optionally, the permission information of the resource includes the ownership information corresponding to the resource, and each ownership information corresponds to a corresponding permission identifier;

[0170] The resource determination module 902 is further configured to: in response to detecting a change in the ownership information corresponding to any permission identifier, determine at least one resource corresponding to any permission identifier as the target resource;

[0171] The resource determination module 902 is further configured to: determine at least one target index corresponding to each of the target resources in the index of the resources, and update the ownership information recorded in each target index to the new ownership information after the change.

[0172] Optionally, the resource determination module 902 is further configured to:

[0173] The system detects changes in ownership information corresponding to any permission identifier recorded in the second relationship table, which is used to record the correspondence between permission identifiers and ownership information.

[0174] Optionally, it also includes:

[0175] The third generation module 906 is used to generate a third change message containing the any permission identifier in response to the monitoring of a change in the ownership information corresponding to any permission identifier recorded in the second relation table.

[0176] The fourth generation module 907 is configured to, in response to the third change message, query at least one resource identifier corresponding to any permission identifier in a first relation table and generate a first permission message containing the any permission identifier and the queried at least one resource identifier; and, in response to the first permission message, query the second relation table for the changed new ownership information corresponding to any permission identifier; or, in response to the third change message, query the second relation table for the corresponding new ownership information and generate a second permission message containing the any permission identifier and the queried new ownership information; and, in response to the second permission message, query the first relation table for at least one resource identifier corresponding to any permission identifier; wherein the first relation table is used to record the correspondence between resource identifiers and permission identifiers;

[0177] The fifth generation module 908 is used to generate a second update message containing the at least one resource identifier found and the new ownership information. The second update message is used to trigger the ownership information recorded in each target index to be updated to the new ownership information.

[0178] Optionally, it also includes:

[0179] Version number determination module 909 is used to respond to the monitoring of a change in the ownership information corresponding to any permission identifier recorded in the second relationship table, and to determine the permission version number corresponding to the permission identifier. The permission version number is used to be included in the generated third change message and second update message, and also used to be included in the generated first permission message or second permission message.

[0180] The message sending module 910 is used to determine the latest version number corresponding to any permission identifier in any message at the current time when any of the third change message, first permission message, second permission message and second update message has been generated, and to send any message if the determined latest version number is consistent with the permission version number contained in any message.

[0181] Optionally, the version number determination module 909 is further configured to:

[0182] If the historical version number corresponding to any of the permission identifiers is not recorded in the cache, the first preset value is determined as the permission version number corresponding to any of the permission identifiers, and the first preset value is recorded in the cache; or...

[0183] If the cache contains a historical version number corresponding to any of the permission identifiers, the permission version number corresponding to any of the permission identifiers is determined based on the historical version number.

[0184] Optionally, the version number determination module 909 is further configured to:

[0185] In response to the historical version number exceeding the preset version number range, the second preset value is determined as the permission version number corresponding to any of the permission identifiers; or,

[0186] In response to the historical version number not exceeding the preset version number range, a version number not exceeding the preset version number range is determined based on the historical version number, and used as the permission version number corresponding to any permission identifier.

[0187] Optionally, it also includes:

[0188] The message discarding module 911 is used to discard any message when it receives any of the third change message, the first permission message, the second permission message, and the second update message, in response to the permission version number contained in any message being inconsistent with the latest version number recorded in the cache.

[0189] Optionally, it also includes:

[0190] The attribution information update module 912 is used to update the attribution information recorded in each target index to the new attribution information after obtaining the second update message, in response to the permission version number contained in the second update message being consistent with the latest version number recorded in the cache.

[0191] Optionally, the fourth generation module 907 is further configured to:

[0192] If the first relation table corresponds to a second relation table, query the second relation table for the new attribution information corresponding to any of the permission identifiers; or...

[0193] When the first relation table corresponds to multiple second relation tables, the corresponding second relation table is determined according to any of the permission identifiers, and the ownership information recorded in the determined second relation table is determined as the new ownership information.

[0194] Optionally, for any one of the third change message, the first permission message, the second permission message, and the second update message, the apparatus further includes:

[0195] The queue message production module 913 is used by the producer of any message to send any message to a preset message queue; and,

[0196] The queue message consumption module 914 is used by the consumer of any message to retrieve and consume any message from the preset message queue.

[0197] Exemplary computing device

[0198] Having described the methods, media, and apparatus of exemplary embodiments of this disclosure, the following references... Figure 10 A computing device according to an exemplary embodiment of the present disclosure will be described.

[0199] Figure 10 The computing device 100 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0200] like Figure 10 As shown, the computing device 100 is presented in the form of a general-purpose computing device. The components of the computing device 100 may include, but are not limited to: at least one processing unit 1001, at least one storage unit 1002, and a bus 1003 connecting different system components (including the processing unit 1001 and the storage unit 1002).

[0201] Bus 1003 includes a data bus, a control bus, and an address bus.

[0202] Storage unit 1002 may include readable media in the form of volatile memory, such as random access memory (RAM) 10021 and / or cache memory 10022, and may further include readable media in the form of non-volatile memory, such as read-only memory (ROM) 10023.

[0203] Storage unit 1002 may also include a program / utility 10025 having a set (at least one) program module 10024, such program module 10024 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0204] The computing device 100 can also communicate with one or more external devices 1004 (such as a keyboard, pointing device, etc.).

[0205] This communication can be performed via input / output (I / O) interface 1005. Furthermore, the computing device 100 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapter 1006. Figure 10 As shown, network adapter 1006 communicates with other modules of computing device 100 via bus 1003. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with computing device 100, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0206] It should be noted that although several units / modules or sub-units / modules of the index update apparatus have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0207] Furthermore, although the operations of the methods disclosed herein are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0208] While the spirit and principles of this disclosure have been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. An index updating method, comprising: monitoring, in real time, permission information of a resource, the permission information of the resource comprising ownership information corresponding to the resource, any ownership information corresponding to a corresponding permission identifier, and a corresponding relationship between the permission identifier and the ownership information being recorded in a second relationship table; in response to monitoring that the permission information is changed, determining a corresponding target resource in the resource according to new permission information after the change, comprising: in response to monitoring that the ownership information corresponding to any permission identifier recorded in the second relationship table is changed, determining the target resource in the resource and generating a target message; the target message at least containing a permission version number corresponding to the any permission identifier when the ownership information is monitored to be changed, the target message being used for index updating in response to a change event of the ownership information corresponding to the any permission identifier; in a case where the target message has been generated, if it is determined that a latest version number corresponding to the any permission identifier at a current time is consistent with the permission version number contained in the target message, the target message is sent; updating permission information recorded in an index of the target resource to the new permission information.

2. The method according to claim 1, wherein the permission information of the resource further comprises a permission identifier corresponding to a resource identifier of the resource, any permission identifier corresponding to corresponding ownership information; the response to monitoring that the permission information is changed, the determination of the corresponding target resource in the resource according to the new permission information after the change, further comprises: in response to monitoring that the permission identifier corresponding to any resource identifier is changed, determining a resource corresponding to the any resource identifier as the target resource; the updating of the permission information recorded in the index of the target resource to the new permission information comprises: determining a target index of the target resource in the index of the resource according to the any resource identifier, and updating the ownership information recorded in the target index to new ownership information corresponding to the new permission identifier after the change.

3. The method according to claim 2, wherein the monitoring of the change of the permission identifier corresponding to any resource identifier comprises: monitoring the change of the permission identifier corresponding to any resource identifier recorded in a first relationship table, the first relationship table being used for recording a corresponding relationship between a resource identifier and a permission identifier.

4. The method according to claim 3, in response to monitoring that the permission identifier corresponding to any resource identifier recorded in the first relationship table is changed, the method further comprises: generating a first change message containing the any resource identifier and the new permission identifier after the change, and in response to the first change message, querying new ownership information corresponding to the new permission identifier in a second relationship table; or, generating a second change message containing the any resource identifier, and in response to the second change message, querying the new permission identifier after the change corresponding to the any resource identifier in the first relationship table, and querying new ownership information corresponding to the new permission identifier in the second relationship table; wherein the second relationship table is used for recording a corresponding relationship between a permission identifier and ownership information. generate a first update message containing the any resource identifier and the queried new home information, the first update message being used to trigger updating the old home information recorded in the target index to the new home information corresponding to the changed new permission identifier.

5. The method of claim 1, The determining the target resource in the resource in response to listening to the change of the home information corresponding to any authority identifier recorded in the second relationship table comprises: in response to listening to the change of the home information corresponding to the any permission identifier, determining at least one resource corresponding to the any permission identifier as the target resource respectively; the updating the permission information recorded in the index of the target resource to the new permission information comprises: determining the target index corresponding to at least one target resource in the index of the resource respectively, and updating the home information recorded in each target index to the changed new home information respectively.

6. The method of claim 5, the updating the home information recorded in each target index to the changed new home information respectively comprises: in the case that the obtained target message is a second update message, in response to the permission version number contained in the second update message being consistent with the latest version number recorded in the cache, updating the home information recorded in each target index to the changed new home information respectively; wherein the second update message contains the permission version number corresponding to the any permission identifier when the change of the home information is listened to, at least one resource identifier corresponding to the any permission identifier, and the changed new home information corresponding to the any permission identifier.

7. The method of claim 1, the target message comprises any one of a third change message, a second update message, a first permission message and a second permission message; the generating the target message comprises: in response to listening to the change of the home information corresponding to any permission identifier recorded in the second relationship table, determining the permission version number corresponding to the any permission identifier when the change of the home information is listened to, and generating a third change message containing the any permission identifier and the permission version number; in response to the third change message, querying at least one resource identifier corresponding to the any permission identifier in the first relationship table, and generating a first permission message containing the permission version number, the any permission identifier and the queried at least one resource identifier, and in response to the first permission message, querying the changed new home information corresponding to the any permission identifier in the second relationship table; or, in response to the third change message, querying the corresponding new home information in the second relationship table, and generating a second permission message containing the permission version number, the any permission identifier and the queried new home information, and in response to the second permission message, querying at least one resource identifier corresponding to the any permission identifier in the first relationship table; wherein the first relationship table is used to record the correspondence between the resource identifier and the permission identifier; generate a second update message containing the permission version number, the queried at least one resource identifier and the new home information, the second update message being used to trigger updating the home information recorded in each target index to the changed new home information respectively.

8. The method of claim 7, wherein the querying the second relationship table for the new ownership information corresponding to the any authority identifier comprises: in a case where the first relationship table corresponds to one second relationship table, querying the second relationship table for the new ownership information corresponding to the any authority identifier; or in a case where the first relationship table corresponds to a plurality of second relationship tables, determining a corresponding second relationship table according to the any authority identifier, and determining the ownership information recorded in the determined second relationship table as the new ownership information.

9. The method of claim 1, wherein the determining the authority version number corresponding to the any authority identifier when the ownership information is changed comprises: in a case where the cache does not record a historical version number corresponding to the any authority identifier, determining a first preset value as the authority version number corresponding to the any authority identifier, and recording the first preset value in the cache; or in a case where the cache records a historical version number corresponding to the any authority identifier, determining the authority version number corresponding to the any authority identifier based on the historical version number.

10. The method of claim 9, wherein the determining the authority version number corresponding to the any authority identifier based on the historical version number comprises: in response to the historical version number exceeding a preset version number range, determining a second preset value as the authority version number corresponding to the any authority identifier; or in response to the historical version number not exceeding the preset version number range, determining a version number not exceeding the preset version number range based on the historical version number as the authority version number corresponding to the any authority identifier.

11. The method of claim 9, further comprising: in a case where the target message is obtained, in response to an authority version number contained in the target message being inconsistent with a latest version number recorded in the cache, discarding the target message.

12. The method of claim 1, wherein the sending and responding to the target message comprises: a producer of the target message sending the target message to a preset message queue; and a consumer of the target message obtaining and consuming the target message from the preset message queue.

13. An index updating apparatus, comprising: a real-time monitoring module configured to monitor authority information of a resource in real time, the authority information of the resource comprising ownership information corresponding to the resource, any ownership information corresponding to a corresponding authority identifier, and a corresponding relationship between an authority identifier and ownership information being recorded in a second relationship table; a resource determining module configured to, in response to the authority information being changed, determine a corresponding target resource in the resource according to new authority information after the change, comprising: ​ ​ ​ ​ in response to listening to the change of the ownership information corresponding to any authority identifier recorded in the second relationship table, determining the target resource in the resource, and generating a target message; the target message at least contains the authority version number corresponding to the any authority identifier when the change of the ownership information is listened to, and the target message is used to respond to the index update of the change event of the ownership information corresponding to the any authority identifier; in the case that the target message has been generated, if it is determined that the latest version number corresponding to the any authority identifier at the current time is consistent with the authority version number contained in the target message, the target message is sent; an information updating module, configured to update the authority information recorded in the index of the target resource to the new authority information.

14. The apparatus of claim 13, wherein the authority information of the resource further comprises an authority identifier corresponding to a resource identifier of the resource, and any authority identifier corresponds to corresponding ownership information. The resource determining module is further configured to: in response to listening to the change of any authority identifier corresponding to any resource identifier, determine the resource corresponding to the any resource identifier as the target resource. The information updating module is further configured to: determine a target index of the target resource in the index of the resource according to the any resource identifier, and update the ownership information recorded in the target index to the new ownership information corresponding to the new authority identifier after the change.

15. The apparatus of claim 14, wherein the resource determining module is further configured to: listen to the change of any authority identifier corresponding to any resource identifier recorded in a first relationship table, and the first relationship table is used to record the correspondence between the resource identifier and the authority identifier.

16. The apparatus of claim 15, in response to listening to the change of any authority identifier corresponding to any resource identifier recorded in the first relationship table, the apparatus further comprises: a first generating module configured to generate a first change message containing the any resource identifier and the new authority identifier after the change, and in response to the first change message, query the new ownership information corresponding to the new authority identifier in a second relationship table; or generate a second change message containing the any resource identifier, and in response to the second change message, query the new authority identifier after the change corresponding to the any resource identifier in the first relationship table, and query the new ownership information corresponding to the new authority identifier in the second relationship table; wherein the second relationship table is used to record the correspondence between the authority identifier and the ownership information; a second generating module configured to generate a first update message containing the any resource identifier and the queried new ownership information, and the first update message is used to trigger the update of the old ownership information recorded in the target index to the new ownership information corresponding to the new authority identifier after the change.

17. The apparatus of claim 13, The resource determining module is further configured to: in response to listening to the change of the ownership information corresponding to any authority identifier, determine at least one resource corresponding to the any authority identifier as the target resource, respectively. The information updating module is further configured to determine target indexes corresponding to the at least one target resource respectively in the index of the resources, and update the ownership information recorded in each target index to the changed new ownership information respectively.

18. The apparatus of claim 17, wherein the updating the ownership information recorded in each target index to the changed new ownership information respectively comprises: in a case where the obtained target message is a second update message, updating the ownership information recorded in each target index to the changed new ownership information respectively in response to the fact that a permission version number contained in the second update message is consistent with a latest version number recorded in the cache, wherein the second update message contains the permission version number corresponding to the any permission identifier at the time when the change of the ownership information is listened to, the at least one resource identifier corresponding to the any permission identifier, and the changed new ownership information corresponding to the any permission identifier.

19. The apparatus of claim 13, wherein the target message comprises any one of a third change message, a second update message, a first permission message, and a second permission message. The generating the target message comprises: in response to listening to the change of the ownership information corresponding to any permission identifier recorded in the second relationship table, determining a permission version number corresponding to the any permission identifier at the time when the change of the ownership information is listened to, and generating a third change message containing the any permission identifier and the permission version number; in response to the third change message, querying the at least one resource identifier corresponding to the any permission identifier in the first relationship table, and generating a first permission message containing the permission version number, the any permission identifier, and the queried at least one resource identifier, and in response to the first permission message, querying the changed new ownership information corresponding to the any permission identifier in the second relationship table, or in response to the third change message, querying the corresponding new ownership information in the second relationship table, and generating a second permission message containing the permission version number, the any permission identifier, and the queried new ownership information, and in response to the second permission message, querying the at least one resource identifier corresponding to the any permission identifier in the first relationship table, wherein the first relationship table is configured to record the correspondence between resource identifiers and permission identifiers; generating a second update message containing the permission version number, the queried at least one resource identifier, and the new ownership information, wherein the second update message is configured to trigger the updating of the ownership information recorded in each target index to the changed new ownership information respectively.

20. The apparatus of claim 19, wherein the querying the changed new ownership information corresponding to the any permission identifier in the second relationship table comprises: in a case where the first relationship table corresponds to one second relationship table, querying the new ownership information corresponding to the any permission identifier in the second relationship table; or ​ In a case where the first relationship table corresponds to a plurality of second relationship tables, a corresponding second relationship table is determined according to the any authority identifier, and the ownership information recorded in the determined second relationship table is determined as the new ownership information. 21.The apparatus of claim 13, further comprising: a version number determining module configured to: in a case where no historical version number corresponding to the any authority identifier is recorded in the cache, determine a first preset value as the authority version number corresponding to the any authority identifier, and record the first preset value in the cache; or, in a case where a historical version number corresponding to the any authority identifier is recorded in the cache, determine the authority version number corresponding to the any authority identifier based on the historical version number. 22.The apparatus of claim 21, wherein the version number determining module is further configured to: determine a second preset value as the authority version number corresponding to the any authority identifier in response to the historical version number exceeding a preset version number range; or determine, as the authority version number corresponding to the any authority identifier, a version number that does not exceed the preset version number range based on the historical version number in response to the historical version number not exceeding the preset version number range. 23.The apparatus of claim 21, further comprising: a message discarding module configured to, in a case where the target message is acquired, discard the target message in response to an authority version number contained in the target message being inconsistent with a latest version number recorded in the cache. 24.The apparatus of claim 13, wherein for the target message, the apparatus further comprises: a queue message producing module configured to, by a producer of the target message, send the target message into a preset message queue; and a queue message consuming module configured to, by a consumer of the target message, acquire and consume the target message from the preset message queue. 25.A medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the method of any one of claims 1-12. 26.A computing device comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the method of any one of claims 1-12 by running the executable instructions. ​

Images