Ambiguation change processing method, device, equipment, medium and product

Abstract

The invention discloses an affiliation change processing method and device, equipment, a medium and a product, and the method comprises the steps: responding to an affiliation change request initiated by a user side, and updating the affiliation master data in a management service based on the affiliation change request; a first affiliation change instruction is issued to each associated business service, so that each associated business service asynchronously executes an affiliation change operation on the local redundant affiliation data, and the affiliation change operation corresponds to the affiliation change request; and returning an affiliation change success response to the user side under the condition of not waiting for each associated business service to complete the affiliation change operation. According to the technical scheme provided by the embodiment of the invention, the problem of delay, lagging or consistency caused by a large number of services, slow response or complex state can be remarkably reduced.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a method, apparatus, equipment, medium and product for handling ownership change. Background Technology

[0002] In a multi-service architecture, entity ownership information is typically distributed across a central management module and multiple business service modules to support data aggregation, access control, and business logic isolation. In practice, changes in ownership are common operational or business processes, often requiring synchronized updates across multiple services to ensure system consistency and correct function execution. However, due to differences in data models, interface specifications, processing flows, and triggering mechanisms among services, unifying ownership information updates presents significant challenges. Especially in scenarios with large data volumes, frequent changes, or high concurrency requests, the propagation of ownership changes may experience delays, omissions, or conflicts, leading to inconsistent states, access control anomalies, or degraded user experience. Therefore, a solution that improves the consistency and efficiency of ownership information changes across multiple services is urgently needed. Summary of the Invention

[0003] This application provides an implementation scheme that differs from related technologies to solve the technical problems of inconsistent changes in multi-service ownership information and low processing efficiency in related technologies.

[0004] Firstly, this application provides a method for handling ownership change, applied to management services, including:

[0005] In response to an ownership change request initiated by a user, update the ownership master data in the management service based on the ownership change request;

[0006] A first attribution change instruction is issued to each associated business service so that each associated business service asynchronously performs an attribution change operation on the local redundant attribution data, wherein the attribution change operation corresponds to the attribution change request;

[0007] Without waiting for the various associated business services to complete the ownership change operation, a success response for the ownership change is returned to the user terminal.

[0008] Secondly, this application provides an ownership change processing device for management services, comprising:

[0009] An update unit is used to respond to an ownership change request initiated by a user terminal and update the ownership master data in the management service based on the ownership change request;

[0010] The issuing unit is used to issue a first attribution change instruction to each associated business service, so that each associated business service asynchronously performs an attribution change operation on the local redundant attribution data, wherein the attribution change operation corresponds to the attribution change request;

[0011] The return unit is used to return a successful attribution change response to the user terminal without waiting for the various associated service operations to complete the attribution change operation.

[0012] Thirdly, this application provides an electronic device, comprising:

[0013] Processor; and

[0014] Memory for storing the executable instructions of the processor;

[0015] The processor is configured to execute the first aspect, or any method in any possible implementation of the first aspect, by executing the executable instructions.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the first aspect, or any method in any possible implementation of the first aspect.

[0017] Fifthly, according to an embodiment of this application, a computer program product includes computer instructions that, when executed by a processor, implement the first aspect or any method in any possible implementation of the first aspect.

[0018] This application provides a solution that responds to a user-initiated ownership change request by updating the ownership master data in the management service based on the ownership change request; issuing a first ownership change instruction to each associated business service, so that each associated business service asynchronously performs ownership change operations on its local redundant ownership data, wherein the ownership change operation corresponds to the ownership change request; and returning a success response to the user without waiting for each associated business service to complete the ownership change operation. By introducing an asynchronous ownership change processing mechanism, in response to a user-initiated ownership change request, the management service first completes the update of the ownership master data and issues ownership change instructions to each associated business service, so that they asynchronously update their respective local redundant ownership information, without waiting for all services to complete the change operation before responding to the user. With the help of this asynchronous update mechanism, a fast response and concurrency decoupling of ownership change operations are achieved, which significantly reduces the technical effect of delay, lag, or consistency problems caused by a large number of services, slow response, or complex states. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0020] Figure 1 A first flowchart illustrating an embodiment of the ownership change processing method provided in this application;

[0021] Figure 2 This is a schematic diagram of the service and data distribution provided in one embodiment of this application;

[0022] Figure 3 A second flowchart of an ownership change processing method provided in an embodiment of this application;

[0023] Figure 4 A third flowchart of an ownership change processing method provided in an embodiment of this application;

[0024] Figure 5 A flowchart illustrating the causes of data inconsistency across multiple services provided in one embodiment of this application;

[0025] Figure 6 A fourth flowchart of an ownership change processing method provided in an embodiment of this application;

[0026] Figure 7 This is a schematic diagram of the structure of an ownership change processing device provided in an embodiment of this application;

[0027] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] Embodiments of this application are described in detail below, with examples of these embodiments illustrated in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting it.

[0029] The terms "first" and "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the solution can be implemented in a different order than that illustrated or described in this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] In multi-service systems, the ownership information of entity objects (such as member ownership relationships and customer ownership relationships) is usually scattered across management services and multiple business services. Changes in ownership require synchronous updates to the data of all parties. Due to the different processing mechanisms between services, problems such as synchronization delays and inconsistent states can easily occur. Especially in scenarios with frequent changes in relationships and high concurrency, it is difficult to guarantee system consistency and response efficiency.

[0031] For example, in a traditional multi-service architecture, multiple services typically share a unified membership table. All queries involving the group to which an account manager belongs, as well as retrieval operations related to that group, must be processed through the membership management service. For instance, the deposit / withdrawal records and transaction order records in the asset service often reach tens of millions of data points. In these business scenarios, it's necessary to bind the transaction records to the corresponding account managers for queries. When it's necessary to display the member group information to which the transaction belongs, the asset service must frequently initiate query requests to the membership management service. As query conditions become more complex and data volume increases, member group relationship queries become a system performance bottleneck, leading to concentrated traffic and excessive single-point load, thus affecting the overall system's response efficiency and stability.

[0032] To address this technical problem, this application provides a method, apparatus, equipment, medium, and product for handling ownership change, which solves the technical problems of inconsistent ownership information changes and low processing efficiency in related technologies.

[0033] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0034] Figure 1 A first flowchart illustrating an exemplary embodiment of this application provides a method for handling ownership changes. This method can be applied to management services and includes at least the following steps 1100 to 130:

[0035] Step 110: In response to the ownership change request initiated by the user, update the ownership master data in the management service based on the ownership change request.

[0036] After receiving an ownership change request from the user, the management service updates the corresponding ownership relationship in its maintained ownership master data according to the request content.

[0037] The management service is the centralized control and maintenance module for the master data, responsible for receiving and processing ownership change requests. The management service may include specific implementations such as member management service and organizational structure management service.

[0038] The user end refers to the client or front-end interface that initiates the ownership change operation, including but not limited to PC, mobile app, management backend, third-party interface, etc. The ownership change request on the user end can be triggered by relevant operators or automated processes.

[0039] A change of ownership request refers to an operation request initiated by the user to modify the ownership information of a target entity object. It may include the object identifier of the target entity object whose ownership information has been changed, the target ownership field identifier in the ownership information of the target entity object, and the target ownership value corresponding to the target ownership field identifier. The target ownership field identifier is used to indicate the identifier of the ownership field that has been changed, and the target ownership value is used to indicate the changed value of the ownership field that has been changed. Furthermore, the change of ownership request may also include change triggering conditions and other content.

[0040] Attribution master data refers to the core data maintained by the management service that identifies the current attribution relationship (or attribution information) of entity objects (such as users, accounts, organizations, etc.), and is the basic data source for performing attribution change operations. For example, when the management service is a member management service, an attribution change request can instruct the modification of the attribution information of the entity object "Customer Manager". That is, the attribution master data can refer to the attribution information of the Customer Manager. The attribution information of the Customer Manager includes data such as the Customer Manager ID, the group ID of the group to which the Customer Manager belongs, and the team ID of the team to which the Customer Manager belongs. The group and team to which the Customer Manager belongs can be defined through the attribution master data. It can be understood that the group to which the Customer Manager belongs and the team to which the Customer Manager belongs are attribution fields, and the group ID of the group to which the Customer Manager belongs and the team ID of the team to which the Customer Manager belongs are the attribution values ​​under the corresponding attribution fields. Here, "Customer Manager" is an abbreviation for Account Manager, representing the business personnel responsible for customer management and maintenance in the Customer Relationship Management (CRM) system, and is one of the core objects of attribution relationship management in the member management service.

[0041] Specifically, after receiving a home change request, the object identifier of the target entity object to be changed can be obtained from the home change request. Then, based on the object identifier of the target entity object, the home master data of the target entity object can be obtained from the management service. Based on the target home field identifier that has been changed as indicated in the home change request and the target home value after the change of the target home field identifier, the home master data is updated.

[0042] For example, when the management service is used for member management, the attribution change request can instruct the group to which the entity object of customer member A belongs to be changed to group A. That is, the attribution change request includes: the object identifier of customer member A, the target attribution field identifier of the group, and the target attribution value of group A. After obtaining the attribution master data of customer member A from the management service, the field value of the attribution field of the group in the attribution master data can be changed to group A.

[0043] Step 120: Issue the first attribution change instruction to each associated business service so that each associated business service can asynchronously perform attribution change operation on the local redundant attribution data, wherein the attribution change operation corresponds to the attribution change request.

[0044] When the management service receives an ownership change request initiated by the user, and updates the ownership master data in the management service based on the ownership change request, in response to the successful update information of the ownership master data in the management service, the management service will issue the first ownership change instruction to each related business service, so that each related business service can asynchronously perform the ownership change operation corresponding to the ownership change request on the local redundant ownership data.

[0045] Among them, related business services refer to services that use or rely on the owner's data in the actual business process. For example, when the management service is a member management service, the corresponding related business services may include, but are not limited to, customer service, asset service, and channel service.

[0046] The local redundant attribution data of related business services refers to the copies of all or part of the attribution fields related to the attribution master data maintained by the management service stored in the local database of each related business service, which are used to support the query and processing of local business logic.

[0047] In step 120, "asynchronous" means that after the management service issues the first ownership change instruction, it does not need to wait for each related business service to complete the ownership change operation. Instead, each related business service processes and reports the task status in the background, so as to realize the asynchronous execution and tracking of ownership change.

[0048] Please see Figure 2 , Figure 2This diagram illustrates the service and data distribution provided in this application embodiment. Taking the member management service as an example, the member management service maintains a customer service member affiliation table. The corresponding affiliation master data includes information describing the customer service member's affiliation, specifically including the group the customer service member belongs to, the team the customer service member belongs to, etc., used to record the organizational affiliation of the customer service member (e.g., an account manager). The member management service corresponds to multiple business-related services including customer service, asset service, channel service, and other services. In these business services, to improve local business efficiency and decouple the system, some or all fields of the member affiliation table are often redundantly stored in their databases. For example, customer service may store a customer table, where a single customer record may include the customer's account identifier and affiliation information. Asset services may store a transaction order table, where a single transaction order record may include the order's transaction identifier, the customer's account identifier of the customer who initiated the order, and the customer's affiliation information. The customer affiliation information includes the member identifier of the customer service representative to whom the customer belongs, the group identifier of the group to which the customer service representative belongs, and the team identifier of the team to which the customer service representative belongs. It is understandable that other business services may also redundantly record some data from the member affiliation table, depending on the business scenario, to support their affiliation-related business logic processing.

[0049] In one embodiment, before the step of issuing a first attribution change instruction to each associated business service so that each associated business service asynchronously performs attribution change operation on local redundant attribution data, the process may specifically include: obtaining operation records of attribution master data within a preset time period, the operation records including business services that perform read and / or write operations on the attribution master data; and determining the associated business service corresponding to the attribution master data based on the operation records.

[0050] Furthermore, a first attribution change instruction is issued to each associated business service to enable each associated business service to asynchronously perform attribution change operations on the local redundant attribution data. Specifically, this includes: responding to the success update information of the attribution master data in the management service, generating an asynchronous attribution change parent task based on the attribution master data indicated by the success update information, and generating a task timestamp for the asynchronous attribution change parent task based on the success update information. The parent task includes multiple subtasks, each subtask corresponding to an associated business service, and each subtask sharing the task timestamp of the parent task. Simultaneously, a distributed lock identifier is obtained based on the object identifier of the attribution master data indicated by the success update information. If the distributed lock identifier is successfully obtained, the target process is started based on the distributed lock identifier, and each subtask is written to the message queue of the target process. Finally, the target process retrieves and executes each subtask from the message queue to realize the generation of a first attribution change instruction by the target process based on the changed attribution master data, and sending the first attribution change instruction to the associated business service corresponding to the currently processed subtask, so that the associated business service performs an attribution change operation on the local redundant attribution data according to the attribution master data carried by the first attribution change instruction.

[0051] Understandably, after the associated business service completes the ownership change operation on the local redundant ownership data, it can call back the task success information corresponding to the subtask to the target process. When the target process receives the task success information corresponding to all subtasks under the parent task, it can release the distributed lock and the target process corresponding to the distributed lock.

[0052] Furthermore, before all related business services complete the ownership change operation on the local redundant ownership data, i.e. before the target process is released, if another ownership change request for the ownership master data with the same object identifier is received, and the ownership master data in the management service is updated again based on the ownership change request, an asynchronous ownership change parent task can be generated again, and each subtask under the asynchronous ownership change parent task can be written into the message queue of the target process. When the target process completes the execution of the previous subtask and obtains the next pending subtask to be consumed from the message queue, it obtains all candidate subtasks corresponding to the target related business service according to the target pending subtask, and obtains the subtask with the latest task timestamp from the candidate subtasks as the final target subtask for processing according to the task timestamp corresponding to the candidate subtask. Before all related business services complete the ownership change operation on the local redundant ownership data, the ownership change instruction is issued to each related business service by changing the ownership master data of the same object identifier in the same process. This realizes process reuse and reduces the waste of server resources caused by frequent updates of ownership master data. At the same time, by comparing timestamps, only the latest ownership master data is sent as the ownership change instruction to the related business services, avoiding multiple data changes to the same business service and effectively improving the efficiency of data change.

[0053] Step 130: Without waiting for each related business service to complete the ownership change operation, return a success response to the user terminal.

[0054] After issuing the first ownership change instruction to each associated business service, the management service can return a successful ownership change response to the user without waiting for each associated business service to complete the corresponding ownership change operation. This method effectively reduces the waiting time of front-end requests and significantly improves the smoothness of the ownership change operation interface and user experience, and is especially suitable for business scenarios with large-scale ownership data synchronization requirements.

[0055] In some embodiments, a first attribution change instruction is issued to each associated business service to cause each associated business service to asynchronously perform an attribution change operation on the local redundant attribution data, including:

[0056] Based on the preset ownership change interface defined by the management service, a first ownership change instruction is issued to each associated business service, enabling each associated business service to asynchronously perform ownership change operations on local redundant ownership data according to the preset ownership change interface. The preset ownership change interface can be different for different associated business services.

[0057] More specifically, the management service issues a first attribution change instruction to each associated business service, enabling each associated business service to asynchronously perform attribution change operations on the local redundant attribution data. This includes: the management service calling the preset attribution change interface corresponding to each associated business service and issuing a first attribution change instruction to each associated business service, so that each associated business service can asynchronously perform attribution change operations on the local redundant attribution data according to its corresponding preset attribution change interface.

[0058] The management service, as the caller, uniformly defines the interface specification for the "ownership change interface," while each related business service, as the callee, completes the update logic of its own business table according to its corresponding preset ownership change interface.

[0059] Specifically, such as Figure 3 As shown, Figure 3 A second flowchart of the ownership change processing method provided in this application embodiment. In this embodiment, the management service is a member management service, and the associated business services include customer service, asset service, and several other services. The method includes:

[0060] S31. The client sends a request to the member management service to change the group to which the member belongs;

[0061] S32. In response to the request to change the group to which the member belongs, the member management service modifies the member's group ID in the master data.

[0062] S33. The member management service calls the preset ownership change interface corresponding to the customer service;

[0063] S34. Customer service modifies the group ID of a member in the local redundant attribution data;

[0064] S35. The member management service calls the preset ownership change interface corresponding to the asset service;

[0065] S36. Asset service modifies the group ID of a member in the local redundant attribution data;

[0066] S37. The member management service calls the preset ownership change interface corresponding to several other services;

[0067] S38. Several other services modify the group ID of a member in the local redundant attribution data.

[0068] It should be noted that the management service can call the preset affiliation change interface of each related business service in various ways, such as asynchronous call, sequential call, concurrent call, or call order based on preset strategy, so as to update the member group information in the local redundant affiliation data. The specific call order or call method is not limited in this application.

[0069] In some embodiments, before issuing the first attribution change instruction to each associated service in response to an attribution change request initiated by the user, the method further includes steps 140 to 150:

[0070] Step 140: Generate corresponding asynchronous task records for each related business service.

[0071] Specifically, in response to an ownership change request initiated by the user, after updating its own ownership master data, the management service will first generate corresponding asynchronous task records for each associated business service, and then issue the first ownership change instruction to each associated business service.

[0072] Step 150: In response to the callback request returned after any associated business service completes the ownership change operation, update the task completion status of the corresponding asynchronous task record based on the callback request.

[0073] Specifically, in response to a callback request returned after any associated business service completes an ownership change operation, the management service updates the task completion status of the asynchronous task record corresponding to that associated business service based on the callback request, for example, marking the task completion status of the corresponding asynchronous task record as completed.

[0074] Specifically, such as Figure 4 As shown, Figure 4 A third flowchart of the ownership change processing method provided in this application embodiment, wherein the management service is a member management service and the associated business service is an asset service, and the method includes:

[0075] S41. The member management service updates the group identifier of the member in the master data;

[0076] S42. The member management service generates corresponding asynchronous task records for the asset service and records the task identifier;

[0077] S43. The member management service calls the preset ownership change interface corresponding to the asset service to initiate an ownership change request to the asset service;

[0078] S44. In response to the request, the asset service modifies the group identifier of the member in the local redundant attribution data;

[0079] S45. After completing the local ownership change operation, the asset service sends a callback request to the callback address preset by the member management service to return the processing status.

[0080] S46. After receiving the callback request, the member management service updates the task completion status of the corresponding asynchronous task record based on the task identifier carried in the request, for example, by marking it as "completed".

[0081] In a multi-service collaborative relationship management system, changes in ownership relationships in the ownership master data are not only caused by ownership change requests triggered by user-end operations, but also by interference from other concurrent tasks. For example, in addition to receiving ownership change requests initiated by the user end, other operation instructions in related business services may update the ownership master data in related tables (such as the transaction order table of the asset service and the member table of the customer service) that store related data information. However, multiple operation requests occurring simultaneously or with delays can lead to data inconsistencies.

[0082] like Figure 5 As shown, Figure 5 This is a flowchart illustrating the causes of data inconsistency across multiple services, provided in an embodiment of this application. Figure 5 Taking asset services as an example, asset services can include OA system approval processes. After the member management service issues an ownership change instruction to change the group identifier in the ownership master data of customer service members' ownership information, the asset service responds to the ownership change instruction and asynchronously updates the group identifier of the group to which the customer service member belongs in the local redundant ownership data (such as the customer ownership information of the transaction order data in the transaction order table). At the same time, when the OA system approval process in the asset service performs the approval operation on the transaction order data, it can first send a read request for the customer service member's ownership information to the member management service. If the member management service is performing an ownership change operation on the customer service member's ownership information at this time, such as changing the group identifier of the group to which the customer service member belongs, the OA system approval process for the customer service member's ownership information may read the old value of the group identifier before the ownership change operation, and then write the read old value of the group identifier into the transaction order table in the asset service. Ultimately, this causes the group identifier of the customer service member's ownership information in the transaction order table to be overwritten by the old value, which is inconsistent with the latest customer service member ownership information in the member management service. Therefore, it is necessary to use scheduled tasks to verify and correct the data within a set time period to ensure the consistency of member affiliation relationships in a distributed scenario across the entire scope.

[0083] In some embodiments, to address the technical problem of inconsistency between the local redundant attribution data of associated business services and the attribution master data of management services in the above scenario, the method further includes steps 160 to 170:

[0084] Step 160: Based on a preset period, obtain the target attribution field identifier and the target attribution value corresponding to the target attribution field identifier from the attribution master data.

[0085] The management service retrieves the target data information that needs to be corrected (including the target attribution field identifier and the target attribution value corresponding to the target attribution field identifier) ​​from the attribution master data based on a preset period, providing benchmark data for subsequent attribution consistency correction.

[0086] The specific value of the preset period is not limited in this application; for example, it can be 5 minutes.

[0087] The target attribution field identifier is the identifier of the field data that needs to be attribution corrected. The target attribution value is the latest field value corresponding to the target attribution field identifier in the attribution master data, which serves as the benchmark value for correcting local redundant attribution data in related business services.

[0088] In some embodiments, the target attribution field is identified as the attribution field whose data has changed within a preset time window in the past.

[0089] Specifically, the target attribution field identifier can be the identifier of the attribution field that has undergone data changes within a preset time window in the past. It is used to specifically repair data inconsistencies that may be caused by recent changes. For example, if a member has undergone an attribution change operation in the past 48 hours, then the attribution field identifier corresponding to that member is the target attribution field identifier.

[0090] In some embodiments, the target attribution field is identified as the identifier of any attribution field in the attribution master data.

[0091] Specifically, the target attribution field identifier can also be the identifier of any attribution field in the attribution master data, used for regression verification of local redundant attribution data across the entire system.

[0092] Step 170: Issue a second attribution correction instruction to each associated business service so that each associated business service asynchronously corrects the field value corresponding to the target attribution field identifier in the local redundant attribution data to the target attribution group identifier.

[0093] The management service issues a second attribution correction instruction to each associated business service, so that each associated business service asynchronously corrects the field value corresponding to the target attribution field identifier in the local redundant attribution data to the target attribution group identifier.

[0094] In this embodiment, a closed loop of "periodic fetching of baseline data + asynchronous correction of redundant data" is used to solve the problem of data attribution deviation caused by multiple concurrent services (such as OA approval workflows and browser requests) at low cost. Even if there are timing conflicts in cross-microservice operations (reading old values ​​and writing old values), the correction process every 5 minutes (or a preset period) can force the local redundant data attribution of related business services (such as the asset service transaction table group_id) to be aligned with the master data. This ensures both eventual data consistency and business reliability, while also being compatible with the performance requirements of high-concurrency scenarios and having scalability to flexibly adapt to different business modules.

[0095] like Figure 6 As shown, Figure 6The fourth flowchart of the ownership change processing method provided in this application embodiment, in which the management service is a member management service, and the associated business services include customer service, asset service and several other services, and the method includes:

[0096] S61. The member management service obtains the target attribution field identifier and its field value (target group identifier) ​​for targets whose attribution group has changed in the past 48 hours.

[0097] S62. The member management service calls the preset ownership change interface corresponding to the customer service;

[0098] S63. Customer service modifies the target attribution field identifier in the local redundant attribution data to the target group identifier.

[0099] S64. The member management service calls the preset ownership change interface corresponding to the asset service;

[0100] S65. The asset service modifies the target attribution field identifier in the local redundant attribution data to the target group identifier.

[0101] S66. The member management service calls the preset ownership change interface corresponding to several other services;

[0102] S67. Several other services modify the target attribution field identifier in the local redundant attribution data to the target group identifier.

[0103] It should be noted that the management service can call the preset affiliation change interface of each related business service in various ways, such as asynchronous call, sequential call, concurrent call, or call order based on preset strategy, so as to update the group identifier of the target member identifier in the local redundant affiliation data to the target group identifier. The specific call order or call method is not limited in this application.

[0104] This application provides a solution that responds to a user-initiated ownership change request by updating the ownership master data in the management service based on the ownership change request; issuing a first ownership change instruction to each associated business service, so that each associated business service asynchronously performs ownership change operations on its local redundant ownership data, wherein the ownership change operation corresponds to the ownership change request; and returning a success response to the user without waiting for each associated business service to complete the ownership change operation. By introducing an asynchronous ownership change processing mechanism, in response to a user-initiated ownership change request, the management service first completes the update of the ownership master data and issues ownership change instructions to each associated business service, so that they asynchronously update their respective local redundant ownership information, without waiting for all services to complete the change operation before responding to the user. With the help of this asynchronous update mechanism, a fast response and concurrency decoupling of ownership change operations are achieved, which significantly reduces the technical effect of delay, lag, or consistency problems caused by a large number of services, slow response, or complex states.

[0105] Figure 7 A schematic diagram of the structure of an apparatus provided for an exemplary embodiment of this application;

[0106] The device includes:

[0107] Update unit 71 is used to update the ownership master data in the management service in response to the ownership change request initiated by the user terminal.

[0108] The issuing unit 72 is used to issue the first attribution change instruction to each associated business service, so that each associated business service can asynchronously perform attribution change operation on the local redundant attribution data, wherein the attribution change operation corresponds to the attribution change request;

[0109] Return unit 73 is used to return a successful ownership change response to the user without waiting for each related business service to complete the ownership change operation.

[0110] In some embodiments, when the issuing unit 72 issues a first attribution change instruction to each associated service so that each associated service asynchronously performs an attribution change operation on the local redundant attribution data, it is specifically used for:

[0111] Based on the preset ownership change interface defined by the management service interface specification, the first ownership change instruction is issued to each related business service, so that each related business service can asynchronously perform ownership change operation on the local redundant ownership data according to the preset ownership change interface.

[0112] In some embodiments, before issuing a first attribution change instruction to each associated service in response to an attribution change request initiated by the user terminal, the apparatus is further configured to:

[0113] Generate corresponding asynchronous task records for each related business service;

[0114] In response to a callback request returned after any associated business service completes an ownership change operation, update the task completion status of the corresponding asynchronous task record based on the callback request.

[0115] In some embodiments, the device is further configured to:

[0116] Based on a preset period, the target attribution field identifier and the target attribution value corresponding to the target attribution field identifier are obtained from the attribution master data.

[0117] A second attribution correction instruction is issued to each associated business service so that each associated business service asynchronously corrects the field value corresponding to the target attribution field identifier in the local redundant attribution data to the target attribution group identifier.

[0118] In some embodiments, the target attribution field is identified as the attribution field whose data has changed within a preset time window in the past.

[0119] In some embodiments, the target attribution field is identified as the identifier of any attribution field in the attribution master data.

[0120] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, they will not be repeated here. Specifically, the device can execute the above method embodiments, and the foregoing and other operations and / or functions of each module in the device correspond to the corresponding processes in the various methods in the above method embodiments, which will not be repeated here for the sake of brevity.

[0121] The apparatus of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0122] Figure 8 This is a schematic block diagram of an electronic device provided in an embodiment of this application. The electronic device may include:

[0123] The system includes a memory 801 and a processor 802. The memory 801 stores computer programs and transfers the program code to the processor 802. In other words, the processor 802 can retrieve and run the computer programs from the memory 801 to implement the methods described in the embodiments of this application.

[0124] For example, the processor 802 can be used to execute the above-described method embodiments according to instructions in the computer program.

[0125] In some embodiments of this application, the processor 802 may include, but is not limited to:

[0126] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0127] In some embodiments of this application, the memory 801 includes, but is not limited to:

[0128] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0129] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 801 and executed by the processor 802 to perform the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0130] like Figure 8 As shown, the electronic device may further include:

[0131] Transceiver 803, which may be connected to processor 802 or memory 801.

[0132] The processor 802 can control the transceiver 803 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 803 may include a transmitter and a receiver. The transceiver 803 may further include antennas, and the number of antennas may be one or more.

[0133] It should be understood that the various components in the electronic device are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0134] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0135] When implemented using software, it can be implemented wholly or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0136] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0137] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0138] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0139] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0140] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for handling ownership change, characterized in that, Applied to management services, including: In response to an ownership change request initiated by a user, update the ownership master data in the management service based on the ownership change request; A first attribution change instruction is issued to each associated business service so that each associated business service asynchronously performs an attribution change operation on the local redundant attribution data, wherein the attribution change operation corresponds to the attribution change request; Without waiting for the various associated business services to complete the ownership change operation, a success response for the ownership change is returned to the user terminal.

2. The method according to claim 1, characterized in that, A first attribution change instruction is issued to each of the associated business services, so that each of the associated business services asynchronously performs the attribution change operation on the local redundant attribution data, including: Based on the preset attribution change interface defined by the management service interface specification, a first attribution change instruction is issued to each of the associated business services, so that each of the associated business services asynchronously performs the attribution change operation on the local redundant attribution data according to the preset attribution change interface.

3. The method according to claim 1, characterized in that, Before issuing the first attribution change instruction to each related business service in response to the attribution change request initiated by the user, the method further includes: Generate corresponding asynchronous task records for each related business service; In response to a callback request returned after any associated business service completes the ownership change operation, the task completion status of the corresponding asynchronous task record is updated based on the callback request.

4. The method according to claim 1, characterized in that, The method further includes: Based on a preset period, the target attribution field identifier and the target attribution value corresponding to the target attribution field identifier are obtained from the attribution master data; A second attribution correction instruction is issued to each of the associated business services, so that each of the associated business services asynchronously corrects the field value corresponding to the target attribution field identifier in the local redundant attribution data to the target attribution value.

5. The method according to claim 4, characterized in that, The target attribution field identifier is the identifier of the attribution field that has undergone data changes within a preset time window in the past.

6. The method according to claim 4, characterized in that, The target attribution field identifier is the identifier of any attribution field in the attribution master data.

7. An affiliation change processing device, characterized in that, Applied to management services, including: An update unit is used to respond to an ownership change request initiated by a user terminal and update the ownership master data in the management service based on the ownership change request; The issuing unit is used to issue a first attribution change instruction to each associated business service, so that each associated business service asynchronously performs an attribution change operation on the local redundant attribution data, wherein the attribution change operation corresponds to the attribution change request; The return unit is used to return a successful attribution change response to the user terminal without waiting for the various associated business services to complete the attribution change operation.

8. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the method of any one of claims 1-6 by executing the executable instructions.

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

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method described in any one of claims 1-6.

Images