Method and system for synchronizing user data

Abstract

The application provides a user data synchronization method and a data synchronization system, comprising: receiving a user data change request initiated by a first service application for a target user; before executing the user data change request, sending a service pre-check query request to other service applications associated with the target user; if each check result indicates that the target user does not have an unfinished service in the corresponding other service application, executing a data change operation corresponding to the user data change request to generate a user data change message; and broadcasting the user data change message to each other service application to enable each other service application to synchronously update the user data of the target user. In this way, by constructing a unified control mechanism for user data change on the side of the basic service platform, pre-service pre-check and post-broadcast synchronization control are performed on the data change process, which can improve the reliability of user data synchronization and the stability of overall business operation under a multi-brand shared account system.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method and system for synchronizing user data. Background Technology

[0002] As enterprises deepen their digital transformation, they often have multiple independently operating brands and corresponding business applications. To reduce development and maintenance costs, enterprises typically build a unified basic service platform, using a single underlying account system to support the basic services of multiple brands, forming a one-to-many correspondence between platform accounts and multiple brand application accounts.

[0003] In existing technologies, the backends of various brand business applications typically operate relatively independently. When a user triggers a change in user data within a particular brand application, this operation often directly modifies the user information on the underlying infrastructure service platform. However, this one-way direct modification lacks a global business pre-inspection and state synchronization mechanism. This prevents other brand applications sharing the same underlying account from promptly detecting data changes, easily leading to synchronization conflicts due to data inconsistencies. Furthermore, ignoring potential unfinished business processes in other applications can severely impact the normal operation of other brand services.

[0004] In summary, existing technologies are insufficient to achieve cross-application security business verification and global collaboration on data changes in an architecture where multiple brands operate independently but share underlying accounts. This results in a high risk of data conflict and business interference during user data synchronization in a multi-brand environment. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a user data synchronization method and a data synchronization system. By introducing a unified processing mechanism of the basic service platform during the user data change process, and performing business pre-inspection across business applications before executing data changes and global broadcast synchronization after changes, user data consistency control between multi-brand business applications can be achieved, thereby avoiding data conflicts caused by changes in a single business application and interference with other business applications, and thus improving the reliability of user data synchronization and the stability of overall business operation under a multi-brand shared account system.

[0006] In a first aspect, the present invention provides a method for synchronizing user data, applied to a basic service platform, the basic service platform being communicatively connected to multiple business applications, and the basic service platform being used to uniformly manage user data associated with the multiple business applications; the method includes: Receive user data change requests for target users initiated by the first business application.

[0007] Before executing the user data change request, a business pre-inspection query request is sent to other business applications associated with the target user to receive the verification results returned by each other business application; the verification results are used to indicate whether the target user has any unfinished business in the corresponding other business applications.

[0008] If each verification result indicates that the target user has no unfinished business in the corresponding other business applications, execute the data change operation corresponding to the user data change request and generate a user data change message.

[0009] The user data change message is broadcast to each other business application so that each other business application can update the user data of the target user in a synchronized manner.

[0010] In an optional implementation, the step of receiving a user data change request for a target user initiated by a first service application includes: Receive user data change request messages sent by the first business application.

[0011] The target user identifier and the user data field to be changed are obtained by parsing the user data change request message.

[0012] Based on the target user identifier, identify multiple business applications associated with the target user, and identify other business applications besides the first business application.

[0013] In an optional implementation, a user data change request may include a request to modify user information or a request to cancel a user account.

[0014] In an optional implementation, "unfinished business" is used to characterize the state of business that the target user has not yet finished or has not been processed in the corresponding business application.

[0015] In an optional implementation, after the step of sending a business pre-inspection query request to other business applications associated with the target user before executing the user data change request, the method further includes: If any verification result indicates that the target user has unfinished business in other corresponding business applications, the verification result is determined to be abnormal, the user data change request is aborted, and a prompt message containing the reason for failure is returned to the first business application.

[0016] In an optional implementation, the step of sending a business pre-inspection query request to other business applications associated with the target user before executing the user data change request includes: Add a distributed write lock to the user data of the target users in the basic service platform.

[0017] Asynchronously send business pre-inspection query requests to other business applications associated with the target user, and start a preset timer.

[0018] If no verification result is received from each other business application before the preset timer expires, the distributed write lock is released and the user data change request is aborted.

[0019] In an optional implementation, the step of broadcasting the user data change message to each other business application includes: The message synchronization service establishes a corresponding message transmission channel for each other business application.

[0020] User data change messages are pushed to each other business application through the message transmission channel.

[0021] In an optional implementation, after the step of broadcasting the user data change message to each other business application, the method further includes: Receive the processing results returned by each other business application.

[0022] When any other business application returns a processing failure, the corresponding user data change message is written to the compensation queue.

[0023] Based on the preset retry policy, the user data change message is resent from the compensation queue until the preset maximum number of retries is reached.

[0024] Secondly, this invention provides a method for synchronizing user data, applied to business applications; the business applications are communicatively connected to a basic service platform, which is used to uniformly manage user data associated with the business applications; the method includes: Receive user data change messages sent by the basic service platform; the user data change message includes the target user data, change identifier and data version number.

[0025] The change identifier is used to determine whether the data update operation corresponding to the user data change message has been executed.

[0026] If already executed, ignore user data change messages.

[0027] If not executed, obtain the current data version number corresponding to the target user data and determine whether the data version number is higher than the current data version number; if the data version number is higher than the current data version number, execute the data update operation according to the business scenario corresponding to the business application; if the data version number is not higher than the current data version number, ignore the user data change message.

[0028] Thirdly, the present invention provides a data synchronization system, including a basic service platform for communication connection and multiple business applications; the basic service platform is configured to execute a user data synchronization method according to any of the foregoing embodiments; the business applications are configured to execute the user data synchronization method according to the foregoing embodiments.

[0029] This application provides a user data synchronization method and system. By uniformly receiving and processing user data change requests on the basic service platform side, performing business pre-checks on various business applications associated with the target user before executing data changes, and generating user data change messages and performing global broadcast synchronization after the verification is passed, it can achieve consistent management of user data among multiple business applications. This avoids data inconsistency problems caused by information asynchrony or business conflicts during data changes, thereby improving the accuracy of user data synchronization, the reliability of system operation, and the overall business collaborative processing capabilities under a multi-brand shared account system.

[0030] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application are realized and obtained through the structures particularly pointed out in the description, claims and drawings.

[0031] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art 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 from these drawings without creative effort.

[0033] Figure 1 A schematic diagram of a data synchronization system provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for synchronizing user data applied to a basic service platform, as provided in an embodiment of this application. Figure 3 A flowchart of a user data change request receiving method provided in an embodiment of this application; Figure 4 Flowchart of the service pre-inspection query request sending method provided in the embodiments of this application; Figure 5 Flowchart of the user data change message broadcasting method provided in the embodiments of this application; Figure 6 A flowchart illustrating a method for synchronizing user data in business applications, as provided in an embodiment of this application.

[0034] Icons: 1-Basic service platform; 2-Business applications. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] To help those skilled in the art better understand this application, a brief introduction to its application scenarios and design concepts is provided.

[0037] In existing technologies, multi-brand business applications typically share the same underlying user account system based on a unified basic service platform, but each business application maintains a relatively independent operating mode in the backend. When a user triggers a user data change operation (such as modifying user information or canceling a user account) in a certain business application, the change often directly affects the user data in the basic service platform, lacking a unified awareness and coordination mechanism for the status of other business applications. On the one hand, other business applications cannot be informed of user data changes in a timely manner, which can easily lead to inconsistencies in data status between different business applications, resulting in data synchronization conflicts. On the other hand, directly executing data changes without verifying the business status of other business applications may alter user data when the target user still has unfinished business, thereby interfering with the normal business processes of other business applications and even causing business anomalies or system errors. Therefore, existing technologies struggle to achieve secure control and global coordination of user data changes within an architecture where multiple business applications share an account system.

[0038] Based on this, embodiments of this application provide a user data synchronization method and a data synchronization system. By constructing a unified processing mechanism for user data changes on the basic service platform side, a business pre-check is performed on each business application associated with the target user before executing the user data change. After the check passes, a user data change message is generated and broadcast for synchronization, enabling each business application to update based on a unified data change result. This application enables cross-business application collaborative control during the user data change process, avoiding data inconsistency issues caused by changes in a single business application. This ensures the consistency and accuracy of user data in a multi-business application environment, thereby improving system stability and the collaborative processing capabilities between multiple services.

[0039] To facilitate understanding of this embodiment, the embodiments of this application will be described in detail below.

[0040] This application provides a data synchronization system, referring to... Figure 1The data synchronization system provided in this application embodiment includes a basic service platform 1 with communication connection and multiple business applications 2; the basic service platform 1 is configured to execute a synchronization method for user data applied to the basic service platform; the business applications 2 are configured to execute a synchronization method for user data applied to the business applications.

[0041] Here, the basic service platform 1 is used to uniformly manage user data associated with multiple business applications 2, and serves as a unified processing node for user data changes. Multiple business applications 2 provide services to users for different brands, different business entry points, or different business scenarios. Each business application 2 can correspond to a different brand's application backend. Although different business applications 2 operate independently, they share the underlying user data system within the basic service platform 1. Therefore, a data association relationship is formed between the basic service platform 1 and the multiple business applications 2, targeting the same user.

[0042] The basic service platform may include a request receiving module, a user data management module, an association management module, a business pre-inspection module, a message generation module, a message synchronization module, a compensation processing module, and a lock control module. The request receiving module receives user data change requests initiated by any business application. The user data management module stores, queries, updates, and maintains user data corresponding to the target user. The association management module maintains the associations between the target user and multiple business applications, so that after receiving a user data change request, it can identify other business applications associated with the target user. The business pre-inspection module sends business pre-inspection query requests to other business applications before executing user data changes and receives the verification results returned by each business application. The message generation module generates user data change messages after user data changes are completed. The message synchronization module broadcasts user data change messages to all other business applications. The compensation processing module saves user data change messages to be retried when business application processing fails and resends them according to a preset retry strategy. The lock control module applies distributed write locks to the target user data during pre-inspection and change to prevent data conflicts caused by concurrent writes.

[0043] The business application may include a business interface module, a business status verification module, a message receiving module, a data update module, a version judgment module, and a processing result feedback module. The business interface module receives user-initiated user data change operations and sends corresponding user data change requests to the basic service platform. The business status verification module, upon receiving a business pre-inspection query request from the basic service platform, determines whether the target user has any unfinished business based on the current business application's order status, service status, account status, or other business statuses, and returns the verification result to the basic service platform. The message receiving module receives user data change messages from the basic service platform. The data update module updates user data in the current business application based on the user data change messages. The version judgment module judges the change identifier and data version number in the user data change message to avoid duplicate and invalid updates. The processing result feedback module returns the processing result to the basic service platform after completing the user data update.

[0044] The basic service platform provides unified underlying data management and synchronization control capabilities, while business applications carry their own independent business logic and brand service capabilities. The basic service platform does not replace the business processing functions of individual business applications, nor do business applications directly control data updates in other business applications. A collaborative relationship of centralized coordination and distributed execution exists between the basic service platform and business applications. The basic service platform is responsible for uniformly receiving change requests, performing unified business pre-checks, uniformly executing underlying data changes, and uniformly triggering synchronization broadcasts. Business applications are responsible for reporting local business status, receiving synchronization messages, and completing user data updates based on local business scenarios. Through the correspondence between the basic service platform and business applications, the consistency of the shared user data system and the coordination of business processing can be guaranteed even when multiple business applications operate independently.

[0045] In one feasible implementation, the basic service platform stores user identifiers, basic user information, account status, data version numbers, and association information between the target user and multiple business applications. Basic user information may include mobile phone number, account information, identity information, contact information, or other user data that needs to be shared among multiple business applications. Association information indicates which business applications the target user is currently associated with, whether through account, service, or data synchronization. Upon receiving a user data change request from the first business application, the basic service platform can first parse the target user identifier and the user data field to be changed from the request message. Then, based on the association information, it determines the multiple business applications associated with the target user and excludes the first business application from among them to obtain the other business applications. In this way, the basic service platform can accurately identify the objects that need to participate in pre-inspection and synchronization, avoiding the involvement of irrelevant business applications and improving the accuracy of the synchronization scope.

[0046] To achieve data consistency and business independence in a multi-brand environment, the basic service platform provides user modification and deregistration interfaces to support various business applications in modifying basic service platform account information. The basic service platform also provides message synchronization services. Each business application provides an interface for receiving message notifications, enabling the basic service platform to push user information change messages to each business application.

[0047] When a user initiates a request to change user data within the primary business application, such as changing a phone number or canceling a user account, the primary business application must synchronously notify the basic service platform via an interface. The basic service platform receives the user data change request from the primary business application. Before executing the actual data change and broadcasting the notification, the basic service platform triggers a business pre-inspection process. The basic service platform sends business pre-inspection query requests to other business applications associated with the target user.

[0048] Other business applications verify whether the target user has any outstanding business based on their own business systems. Outstanding business includes, but is not limited to, unsettled orders, ongoing services, and binding relationships. These other business applications then report the verification results to the basic service platform. The basic service platform summarizes and judges the results based on the feedback from all parties.

[0049] If any other business application's backend returns a verification result indicating that the target user has unfinished business in the corresponding other business application, the basic service platform will abort the current user data change request and return a prompt message containing the reason for failure to the first business application that initiated the request.

[0050] If all other business applications confirm that the verification result indicates that the target user has no outstanding business in the corresponding other business applications, the basic service platform will allow subsequent user data change operations to be performed, generating a user data change message. The basic service platform will then broadcast the received user data change message to the backends of all relevant other business applications via message synchronization service.

[0051] Upon receiving user data change notifications from the basic service platform, other business applications synchronize and update the user data of their respective target users according to their specific business scenarios. For example, if we consider the basic service platform as a central ID card registry and the various business applications as banks, driving schools, or libraries, when a banking application modifies its address information and notifies the central ID card registry, the central ID card registry must have a notification system capable of instantly broadcasting this information to the driving school and library applications. This allows the driving school and library applications to update their information based on their specific business needs; for instance, the banking application might require a new address, while the library application might not. This mechanism ensures that all business applications can operate normally, preventing changes to user information from affecting other applications' access to the services provided by the basic service platform.

[0052] In practical deployments, multiple business applications can correspond to different brand-specific business backends. The basic service platform serves as a unified underlying service center, providing shared user data management and synchronization control capabilities for these applications. Although each business application employs its own independent business processes and interface logic, they establish a unified data change control link through the basic service platform. A user only needs to initiate a user data change request once within a single business application, and the basic service platform can complete pre-checking, change processing, message generation, broadcast synchronization, and failure compensation, ensuring consistency across all business applications associated with the target user at the shared user data level.

[0053] The data synchronization system provided in this application can solve the problems of data conflict, synchronization delay and business interference caused by the lack of global coordination and control over user data changes in existing scenarios where multiple brands operate independently but share the underlying account system.

[0054] Based on the above embodiments, this application provides a user data synchronization method applied to a basic service platform. The basic service platform is connected to multiple business applications and is used to uniformly manage user data associated with multiple business applications.

[0055] Here, the basic service platform uses a single account system to support all multi-brand business applications, with a one-to-many relationship between the basic service platform account and the multi-brand accounts. The basic service platform provides user modification and cancellation interfaces to support multiple business applications in modifying basic service platform account information.

[0056] Reference Figure 2 The method for synchronizing user data applied to a basic service platform provided in this application includes: Step S101: Receive a user data change request for the target user initiated by the first business application.

[0057] Here, the target user can initiate requests across platforms within any business application. The target user initiates user data change operations through the front-end interface of the first business application.

[0058] In an optional implementation, a user data change request may include a request to modify user information or a request to cancel a user account.

[0059] A request to modify user information can be a request for a target user to change their mobile phone number within a business application. Besides changing the mobile phone number, requests to modify user information can also include changes to basic user data such as changing the user's login password or contact address.

[0060] A user account cancellation request specifically refers to a user account cancellation operation initiated by a target user within a business application. When a target user modifies user information or cancels their user account within a business application, the user information on the basic service platform is simultaneously modified. This synchronized modification of user information on the basic service platform will affect the normal use of services provided by the basic service platform by other business applications.

[0061] Upon receiving a user data change request from a target user, the first business application must simultaneously notify the basic service platform through the user modification or deregistration interface provided by the basic service platform. User data change requests can be sent to the basic service platform using various communication methods, such as HTTP requests and Remote Procedure Call (RPC) requests.

[0062] After receiving a user data change request, the basic service platform can parse the request and extract the target user identifier and the specific data fields to be modified.

[0063] In addition, to ensure the security of data transmission, the first business application and the basic service platform can use an encrypted channel to transmit user data change requests. The basic service platform will decrypt and verify permissions after receiving the request.

[0064] Step S102: Before executing the user data change request, a business pre-inspection query request is sent to other business applications associated with the target user to receive the verification result returned by each other business application; wherein, the verification result is used to indicate whether the target user has any unfinished business in the corresponding other business applications.

[0065] Here, before executing actual data changes and broadcasting notifications, the basic service platform sends a pre-inspection query request to the backends of all related business applications. Upon receiving the pre-inspection query request, each business application verifies, based on its own business system, whether the target user has any unfinished business.

[0066] In an optional implementation, "unfinished business" is used to characterize the state of business that the target user has not yet finished or has not been processed in the corresponding business application.

[0067] Specifically, each other business application's backend verifies whether the target user has any outstanding business transactions based on its own business system. Outstanding business transactions can include at least one of the following: unsettled orders, ongoing services, and linked relationships. For example, unsettled orders could refer to unpaid shopping orders placed by the target user within a specific brand application; ongoing services could refer to vehicle control services or monthly subscription services currently being used by the target user; and linked relationships could refer to the unresolved association between the target user's vehicle and account. By verifying these business statuses, each other business application can prevent upper-level business logic interruptions or data corruption caused by sudden modifications or cancellations of underlying account information.

[0068] To improve data processing efficiency, the basic service platform can adopt an asynchronous concurrent approach, simultaneously sending business pre-inspection query requests to all other business applications and starting a preset timer. If the basic service platform does not receive a verification result from another business application within the preset time, it can mark the verification result of the unresponsive other business application as having an anomaly.

[0069] Meanwhile, to prevent target users from making new data changes in other business applications during the pre-inspection period, the basic service platform can add a distributed write lock to the target user's user data in the basic service platform to intercept concurrent data change requests for the target user.

[0070] Step S103: If each verification result indicates that the target user has no unfinished business in the corresponding other business applications, execute the data change operation corresponding to the user data change request and generate a user data change message.

[0071] If any other business application's backend returns a verification result indicating unfinished business, the basic service platform will suspend the current user information modification or cancellation operation and return a message containing the reason for failure to the first business application that initiated the request. If all other business application backends confirm that there are no unfinished business, the basic service platform will allow subsequent user data changes and broadcast synchronization operations to proceed.

[0072] When the change is permitted, the basic service platform updates the corresponding data record for the target user in the underlying database, or marks the target user's account status as logged out. After the data change operation is successfully executed, the basic service platform generates a user data change message.

[0073] To ensure the reliability and idempotency of subsequent data synchronization, the basic service platform can attach a globally unique change identifier serial number, timestamp, and data version number to the user data change message.

[0074] Step S104: Broadcast the user data change message to each other business application so that each other business application can synchronously update the target user's user data.

[0075] Here, the basic service platform is responsible for broadcasting user data change information received by the platform to all relevant other business application backends. These other business application backends provide interface interfaces for receiving message notifications, enabling the basic service platform to push user information change messages to them. Upon receiving the user information change message from the basic service platform, each other business application modifies the user information according to its own business scenario.

[0076] Specifically, the basic service platform can distribute user data change messages to the topics subscribed to by various other business applications through a message queue system. If a certain other business application fails to receive or process the user data change message due to network fluctuations or downtime, the basic service platform can resend the user data change message by combining a compensation queue and a preset retry strategy until the preset maximum number of retries is reached.

[0077] When other business applications update the user data of a target user, they can compare the data version number in the user data change message with the current data version number stored locally. Only when the received data version number is higher than the current data version number will other business applications perform local data update operations, thereby avoiding the problem of historical messages overwriting the latest data due to network latency.

[0078] In an optional implementation, refer to Figure 3 Step S101 includes the following steps S201-S203.

[0079] Step S201: Receive the user data change request message sent by the first service application.

[0080] Here, the first business application is any one of the different brand applications.

[0081] When a target user triggers an action to modify information or log out on the front-end interface of the first business application, the first business application generates a user data change request message. This message can be sent to the basic service platform via a secure, encrypted communication protocol to ensure data security during transmission.

[0082] Step S202: Parse the target user identifier and the user data field to be changed from the user data change request message.

[0083] Here, after receiving a user data change request message, the basic service platform parses the user data change request message using preset message parsing rules.

[0084] The target user identifier can be a unique account identifier assigned to the target user by the basic service platform, a mobile phone number, or a unified identity authentication code. The user data field to be changed contains the specific data content that the target user intends to modify. User data change requests can include requests to modify user information or requests to cancel user accounts. For example, a request to modify user information can specifically be a request for a user to change their mobile phone number within the first business application. If the user data change request is a request to cancel a user account, the user data field to be changed can be represented as an instruction identifier indicating that the account status has changed to a canceled status.

[0085] Step S203: Based on the target user identifier, determine multiple business applications associated with the target user, and determine other business applications besides the first business application.

[0086] Here, the basic service platform stores a table showing the binding or authorization relationships between target user identifiers and various business applications. By querying this table, the basic service platform can find all associated business applications that the target user has activated or used. To avoid repeatedly sending business pre-inspection query requests to the first business application that initiated the request, the basic service platform removes the first business application from all the found associated business applications. This allows the platform to accurately identify the other business applications that require synchronization and business pre-inspection. These other business applications are the relatively independent brand business application backends, excluding the first business application.

[0087] In an optional implementation, after step S102, the method further includes: If any verification result indicates that the target user has unfinished business in other corresponding business applications, the verification result is determined to be abnormal, the user data change request is aborted, and a prompt message containing the reason for failure is returned to the first business application.

[0088] Here, if the basic service platform detects any verification result indicating that the target user has unfinished business in other corresponding business applications, the basic service platform determines that the verification result is abnormal. When the verification result is determined to be abnormal, the basic service platform suspends the target user's user data change request. Suspending the user data change request means that the basic service platform will not perform operations to modify user information or cancel user accounts in the underlying database of the basic service platform, nor will the basic service platform broadcast any user data change messages to other business applications.

[0089] After aborting the user data change request, the basic service platform returns a message containing the reason for failure to the first business application that initiated the request. This message specifically indicates which other business application has what type of unfinished business. For example, the message might state that the target user has outstanding orders in application XX and therefore cannot cancel their account. Upon receiving this message, the first business application can display it to the target user on its front-end user interface. By displaying this message, the first business application can guide the target user to complete the outstanding business in the corresponding other business application before re-initiating the user data change request in the first business application.

[0090] In an optional implementation, refer to Figure 4 Step S102 includes the following steps S301-S303.

[0091] Step S301: Add a distributed write lock to the target user's user data in the basic service platform.

[0092] Here, to prevent data conflicts caused by target users simultaneously initiating new data change operations in other business applications during the business pre-inspection period, the basic service platform adds a distributed write lock to the underlying user data of the target user within the basic service platform. The basic service platform can be a remote information processing service platform responsible for providing an account system to support multiple business services. By adding a distributed write lock, the basic service platform can intercept other concurrent data change requests targeting the target user, ensuring the stability and consistency of the target user's underlying data state during the business pre-inspection period.

[0093] In step S302, a business pre-inspection query request is asynchronously sent to other business applications associated with the target user, and a preset timer is started.

[0094] Here, the basic service platform adopts an asynchronous sending method, simultaneously initiating business pre-inspection query requests to multiple other business applications in parallel, thereby improving the data processing efficiency of the basic service platform. These other business applications include the backends of various relatively independently operating brand business applications. While the basic service platform asynchronously sends business pre-inspection query requests, it also starts a preset timeout waiting timer. This preset timer limits the maximum waiting time for the basic service platform to receive verification results from other business applications.

[0095] Step S303: If no verification result is received from each other business application before the preset timer expires, release the distributed write lock and abort the user data change request.

[0096] Here, the backends of various other business applications send the verification results back to the basic service platform. The basic service platform continuously receives the verification results from these applications during the preset timer's execution. If the basic service platform does not receive verification results from each other application before the preset timer expires, this indicates that some other applications may be experiencing network latency or their backend systems may be down. To prevent the basic service platform's system resources from being occupied for an extended period and to avoid potential data inconsistency risks, the basic service platform proactively releases the distributed write locks added for the target user.

[0097] After releasing the distributed write lock, the basic service platform aborts the user data modification operation, such as changing user information or canceling an account. Following the abort, the basic service platform returns a failure reason to the first business application that initiated the request.

[0098] Through timeout checks and distributed write lock release mechanisms, the basic service platform can ensure that all business applications can operate normally, preventing target users from modifying their phone numbers or canceling their accounts without explicit security confirmation from all other business applications. This also prevents data synchronization and modification operations from affecting other brand business applications' normal use of the vehicle control services provided by the basic service platform.

[0099] In an optional implementation, refer to Figure 5 The step of broadcasting the user data change message to each other business application in step S104 includes the following steps S401-S402.

[0100] Step S401: Establish a corresponding message transmission channel for each other business application through the message synchronization service.

[0101] Here, the basic service platform is responsible for broadcasting user data change information received by the basic service platform to all other business application backends through message synchronization service.

[0102] Each other business application is responsible for providing an interface for receiving message notifications, enabling the basic service platform to push user information change messages to these applications. By connecting to and calling the message notification receiving interfaces provided by each other business application, the basic service platform establishes a corresponding message transmission channel for each application. Through these message transmission channels, the basic service platform ensures that user data change messages are accurately and securely delivered to every associated other business application.

[0103] Step S402: Push the user data change message to each other business application through the message transmission channel.

[0104] Here, the basic service platform can broadcast to the corresponding business applications in real time.

[0105] After receiving the user information change notification pushed by the basic service platform, each other business application modifies the user information accordingly based on its own business scenario. For example, if we consider the basic service platform as a central ID card registration office and the various business applications as banks, driving schools, or libraries, when a banking application modifies its address information and notifies the central ID card registration office, the central ID card registration office must have a notification system capable of instantly broadcasting the changes to the driving school and library business applications. This allows the driving school and library business applications to update their information based on their own business needs; for example, the banking application might need a new address, while the library application might not.

[0106] This push mechanism and business scenario-based update mechanism effectively solve the synchronization conflict problem caused by the independent account systems of multiple brand business applications, and avoid the problem that modifying user information will affect the normal use of basic service platform services by other brand business applications.

[0107] In an optional implementation, after the step of broadcasting the user data change message to each other business application in step S104, the method further includes the following steps S501-S503.

[0108] Step S501: Receive the processing results returned by each other business application.

[0109] Here, after each other business application completes its corresponding user information modification operation, it sends the processing result to the basic service platform. The processing result may include a status indicator indicating whether the processing was successful or failed.

[0110] Step S502: When any other business application returns a processing failure, the corresponding user data change message is written to the compensation queue.

[0111] In a real-world network communication and multi-system collaborative environment, other business applications may fail to successfully modify user information due to network fluctuations, server crashes, or database concurrency conflicts. When the basic service platform receives a processing failure result from any other business application, or if it fails to receive a processing result from another business application within a preset time window and therefore assumes the processing has failed, the basic service platform extracts the corresponding unprocessed user data change message. The basic service platform then writes the extracted user data change message into a compensation queue maintained internally by the platform. This compensation queue is a data structure specifically designed to temporarily store messages requiring retry processing.

[0112] Step S503: Resend the user data change message from the compensation queue based on the preset retry strategy until the preset maximum number of retries is reached.

[0113] Here, after the basic service platform writes the corresponding user data change message into the compensation queue, the asynchronous scheduled task or message listening component within the basic service platform periodically scans the compensation queue. Based on a preset retry strategy, the basic service platform extracts the user data change message that needs to be resent from the compensation queue. The preset retry strategy can include a fixed-interval retry strategy or an exponential backoff retry strategy. Following the preset retry strategy, the basic service platform resends the user data change message to the other business application backend that previously returned a processing failure. Each time the basic service platform resends, it increments the retry count. The basic service platform continues resending until the preset maximum number of retries is reached. If, after reaching the preset maximum number of retries, the other business application still returns a processing failure, the basic service platform can transfer the corresponding user data change message to a dead-letter queue and trigger manual intervention or a system alarm process.

[0114] Through a retransmission mechanism based on compensation queues and preset retry strategies, the basic service platform maximizes the reliability and eventual consistency of user data synchronization across multiple business application backends, avoiding technical issues where modifications to user information due to single points of failure in the system would affect the normal use of other brand services.

[0115] Based on the above embodiments, this application provides a user data synchronization method applied to business applications; the business applications are communicatively connected to a basic service platform, which is used to uniformly manage user data associated with the business applications. (Refer to...) Figure 6The user data synchronization method for business applications provided in this application includes: Step S601: Receive a user data change message sent by the basic service platform; wherein the user data change message includes the target user data, change identifier and data version number.

[0116] Here, to receive user data change messages, the business application backend provides an interface for receiving message notifications, enabling the basic service platform to push user information change messages to the business applications. The business applications receive the user data change messages broadcast by the basic service platform through this message notification interface.

[0117] The change identifier included in the user data change message can be a globally unique serial number. The change identifier is used to prevent business applications from processing the same message repeatedly. The data version number is used to identify the order in which the target user data was updated.

[0118] Step S602: Determine whether the data update operation corresponding to the user data change message has been executed based on the change identifier.

[0119] Here, after receiving a user data change message, the business application extracts the change identifier from the message. The business application then checks its local database or cache system to see if the change identifier exists. By querying the change identifier, the business application can determine whether the currently received user data change message has been successfully processed.

[0120] Step S603: If already executed, ignore the user data change message.

[0121] Here, if the change identifier exists in the business application's local storage record, it means that the business application has already performed the data update operation corresponding to the user data change message containing this change identifier. To avoid the business application repeatedly modifying the underlying data, which could lead to wasted system resources or business logic errors, the business application directly discards and ignores the user data change message, and does not perform any substantive data modification actions.

[0122] Step S604: If not executed, obtain the current data version number corresponding to the target user data, and determine whether the data version number is higher than the current data version number; if the data version number is higher than the current data version number, perform the data update operation according to the business scenario corresponding to the business application; if the data version number is not higher than the current data version number, ignore the user data change message.

[0123] Here, if the business application's judgment result is "not executed," the business application retrieves the current data version number corresponding to the target user data stored locally. If the data version number carried in the user data change message is higher than the business application's current data version number, it indicates that the received data modification instruction is the latest. At this point, the business application modifies the user information accordingly based on its own business scenario.

[0124] For example, business applications decide whether to update specific fields based on their own business logic, thereby ensuring that all business applications can operate normally and avoiding the impact of modifying user information on other brands' business applications' normal use of the basic service platform.

[0125] If the data version number carried in a user data change message is not higher than the current data version number, it indicates that the user data change message may be an older message that arrived late due to network latency or a message retry mechanism. To prevent older messages from overwriting the latest local data, business applications directly ignore user data change messages. Through this version number verification mechanism combined with a business scenario-based data update mechanism, business applications can ensure data consistency and business independence across multi-brand architectures.

[0126] The computer program product provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0127] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0128] Furthermore, in the description of the embodiments of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0129] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0130] In the description of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0131] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the claims.

Claims

1. A method for synchronizing user data, characterized in that, The method is applied to a basic service platform that communicates with multiple business applications and is used to uniformly manage user data associated with the multiple business applications; the method includes: Receive user data change requests for target users initiated by the first business application; Before executing the user data change request, a business pre-inspection query request is sent to other business applications associated with the target user to receive the verification result returned by each of the other business applications; wherein, the verification result is used to indicate whether the target user has any unfinished business in the corresponding other business application; If each of the verification results indicates that the target user does not have any unfinished business in the corresponding other business applications, execute the data change operation corresponding to the user data change request and generate a user data change message; The user data change message is broadcast to each of the other business applications so that each of the other business applications can synchronously update the user data of the target user.

2. The user data synchronization method according to claim 1, characterized in that, The step of receiving a user data change request for a target user initiated by the first service application includes: Receive the user data change request message sent by the first service application; The target user identifier and the user data field to be changed are obtained by parsing the user data change request message; Based on the target user identifier, multiple business applications associated with the target user are identified, and other business applications besides the first business application are identified.

3. The user data synchronization method according to claim 2, characterized in that, The user data change request includes a request to modify user information or a request to cancel a user account.

4. The user data synchronization method according to claim 1, characterized in that, The term "unfinished business" is used to characterize the state of business that the target user has not yet completed or processed in the corresponding business application.

5. The user data synchronization method according to claim 4, characterized in that, After the step of sending a business pre-inspection query request to other business applications associated with the target user before executing the user data change request, the method further includes: If any of the verification results indicates that the target user has unfinished business in the corresponding other business applications, the verification result is determined to be abnormal, the user data change request is terminated, and a prompt message containing the reason for failure is returned to the first business application.

6. The user data synchronization method according to claim 1, characterized in that, The step of sending a business pre-inspection query request to other business applications associated with the target user before executing the user data change request includes: Add a distributed write lock to the user data of the target user in the basic service platform; The service pre-inspection query request is asynchronously sent to other service applications associated with the target user, and a preset timer is started; If no verification result is received from each of the other business applications before the preset timer expires, the distributed write lock is released and the user data change request is terminated.

7. The user data synchronization method according to claim 1, characterized in that, The step of broadcasting the user data change message to each of the other business applications includes: A corresponding message transmission channel is established for each of the other business applications through the message synchronization service; The user data change message is pushed to each of the other business applications through the message transmission channel.

8. The user data synchronization method according to claim 1, characterized in that, After the step of broadcasting the user data change message to each of the other business applications, the method further includes: Receive the processing results returned by each of the other business applications; When any of the other business applications returns a processing failure, the corresponding user data change message will be written to the compensation queue. The user data change message is resent from the compensation queue based on a preset retry policy until the preset maximum number of retries is reached.

9. A method for synchronizing user data, characterized in that, The method is applied to business applications; the business applications are communicatively connected to a basic service platform, which is used to uniformly manage user data associated with the business applications; the method includes: Receive user data change messages sent by the basic service platform; wherein, the user data change message includes target user data, change identifier and data version number; Based on the change identifier, determine whether the data update operation corresponding to the user data change message has been executed; If already executed, ignore the user data change message; If not executed, obtain the current data version number corresponding to the target user data, and determine whether the data version number is higher than the current data version number; if the data version number is higher than the current data version number, execute the data update operation according to the business scenario corresponding to the business application; if the data version number is not higher than the current data version number, ignore the user data change message.

10. A data synchronization system, characterized in that, It includes a basic service platform for communication connectivity and multiple business applications; the basic service platform is configured to execute the user data synchronization method according to any one of claims 1-8; the business applications are configured to execute the user data synchronization method according to claim 9.

Images