Data processing methods, apparatus, storage media and electronic equipment

Abstract

This application provides a data processing method, apparatus, storage medium, and electronic device, relating to the field of computer technology. The method includes: receiving a data operation request initiated by a first micro-frontend application; acquiring a lock on a target data item for the data operation request based on the business semantics of the request; if the lock is locked, creating a snapshot of the target data item before modification and executing the data operation specified in the data operation request; creating a snapshot after modification after the data operation is completed, and calculating the data difference between the snapshot before and after modification; generating a change event containing the operation result and data difference, and sending the change event to a second micro-frontend application subscribing to the target data item; and releasing the lock on the target data item after sending the change event. This method can avoid data inconsistencies and state anomalies between multiple sub-applications.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus, storage medium and electronic device. Background Technology

[0002] In scenarios such as large-scale enterprise-level front-end applications, platform-as-a-service products, and complex single-page applications, the micro-front-end architecture effectively solves engineering problems such as low team collaboration efficiency and difficulty in upgrading the technology stack by splitting the monolithic front-end into multiple independently developed and deployed sub-applications.

[0003] Currently, data management solutions under micro-frontend architectures mainly follow the state management techniques of traditional single-page applications. For example, they use a reactive state management library based on the proxy pattern in conjunction with an event bus mechanism to achieve data sharing and communication between sub-applications. However, when faced with scenarios where multiple sub-applications run collaboratively and frequently interact and share data, existing solutions struggle to effectively coordinate data change operations between sub-applications, easily leading to data inconsistencies and cross-application state anomalies. Summary of the Invention

[0004] In view of this, this application provides a data processing method, apparatus, storage medium, and electronic device that can avoid data inconsistencies and state anomalies among multiple sub-applications. The specific solution is as follows:

[0005] A data processing method, comprising:

[0006] Receive a data operation request initiated by the first micro front-end application;

[0007] Based on the business semantics of the data operation request, acquire the lock for the target data item for the data operation request;

[0008] If the lock on the target data item is locked, create a snapshot of the target data item before modification, and perform the data operation specified in the data operation request on the target data item.

[0009] After the data operation is completed, a modified snapshot is created, and the data differences between the pre-modification snapshot and the modified snapshot are calculated;

[0010] Generate a change event that includes the operation result of the data operation and the data difference, and send the change event to the second micro-frontend application that subscribes to the target data item;

[0011] After the change event is sent, the lock on the target data item is released, restoring the target data item to an idle state.

[0012] Optionally, in the above method, acquiring a lock for the target data item based on the business semantics of the data operation request includes:

[0013] Based on the business semantics of the data operation request, calculate the operation priority of the data operation request;

[0014] Based on the operation priority, the data operation request acquires the lock for the target data item.

[0015] Optionally, in the above method, calculating the operation priority of the data operation request based on the business semantics of the data operation request includes:

[0016] Extract at least one of the following semantic features indicated by the business semantics from the data operation request: operation type, user role initiating the data operation request, criticality of the data operated by the data operation request, and current system load;

[0017] According to the preset weighting rules, the extracted semantic feature information is weighted and scored to generate a dynamic priority score;

[0018] The dynamic priority score is used as the operation priority of the data operation request.

[0019] Optionally, in the above method, acquiring the lock for the target data item for the data operation request based on the operation priority includes:

[0020] Check the current state of the lock associated with the target data item;

[0021] If the lock is in an idle state, the lock is granted to the data operation request, and the state of the lock is switched to a locked state;

[0022] If the lock is in a locked state, the data operation request is placed in the priority waiting queue according to the operation priority. After the lock is released, the data operation request is retrieved from the priority waiting queue in descending order of priority and the lock is granted to the data operation request.

[0023] Optionally, in the above method, creating a snapshot of the target data item before modification includes:

[0024] Invoke the snapshot manager to obtain the current complete data status of the target data item;

[0025] An incremental snapshot of the target data item is generated as a snapshot before modification.

[0026] Optionally, in the above method, calculating the data difference between the snapshot before modification and the snapshot after modification includes:

[0027] Compare the snapshot before modification with the snapshot after modification to obtain a difference identification result. The difference identification result includes at least one of the data path that has changed in the target data item, the old value before the change, and the new value after the change.

[0028] Based on the difference identification results, a minimal change description set is generated. The change description set contains at least one change entry, and each change entry records at least one of the change type, change path, old value, and new value.

[0029] The set of change descriptions is used as the data difference.

[0030] Optionally, in the above method, generating a change event that includes the operation result of the data operation and the data difference, and sending the change event to a second micro-frontend application subscribing to the target data item, includes:

[0031] Assign an event sequence number to the change event, and establish a mapping relationship between the event sequence number and the operation sequence number of the data operation;

[0032] The change event carrying the event sequence number, the operation result, and the data difference is stored in the event log;

[0033] Based on a preset subscription relationship table, determine the second micro-frontend application that subscribes to the target data item, and send the change event to the second micro-frontend application.

[0034] A data processing apparatus, comprising:

[0035] The receiving unit is used to receive data operation requests initiated by the first micro front-end application;

[0036] The first computing unit is used to acquire a lock for the target data item for the data operation request based on the business semantics of the data operation request;

[0037] A creation unit is configured to, when the lock of the target data item is in a locked state, create a snapshot of the target data item before modification, and perform the data operation specified by the data operation request on the target data item;

[0038] The second calculation unit is used to create a modified snapshot after the data operation is completed, and to calculate the data difference between the snapshot before modification and the snapshot after modification.

[0039] A generation unit is configured to generate a change event that includes the operation result of the data operation and the data difference, and send the change event to a second micro-frontend application that subscribes to the target data item;

[0040] The execution unit is used to release the lock of the target data item after completing the sending of the change event, so that the target data item is restored to an idle state.

[0041] A storage medium includes storage instructions, wherein, when the instructions are executed, the device in which the storage medium resides controls the execution of the data processing method described above.

[0042] An electronic device includes a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors using the data processing method described above.

[0043] This application provides a data processing method, apparatus, storage medium, and electronic device. The method includes: receiving a data operation request initiated by a first micro-frontend application; calculating the operation priority of the data operation request based on its business semantics; acquiring a lock on a target data item for the data operation request according to the operation priority; creating a pre-modification snapshot of the target data item while the lock is locked, and performing the data operation specified by the data operation request on the target data item; creating a post-modification snapshot after the data operation is completed, and calculating the data difference between the pre-modification snapshot and the post-modification snapshot; generating a change event containing the operation result of the data operation and the data difference, and sending the change event to a second micro-frontend application subscribing to the target data item; and releasing the lock on the target data item after sending the change event, restoring the target data item to an idle state. Applying the method provided in this application can coordinate data change operations between multiple sub-applications in a micro-frontend architecture, effectively reducing data inconsistency and cross-application state anomalies, and improving system reliability and maintainability. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0045] Figure 1 A flowchart of a data processing method provided in this application;

[0046] Figure 2 A flowchart of a process for calculating the operation priority of the data operation request provided in this application;

[0047] Figure 3 A schematic diagram of the structure of a data processing device provided in this application;

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

[0049] The technical solutions of the embodiments 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, and 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.

[0050] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0051] This application provides a data processing method that can be applied to an electronic device, such as a mobile terminal, tablet computer, or server. The flowchart of the method is shown below. Figure 1 As shown, it specifically includes:

[0052] S101: Receive a data operation request initiated by the first micro front-end application.

[0053] In this embodiment, the first micro-frontend terminal application can be an independently deployed and running frontend functional module that constitutes the micro-frontend architecture, such as a user center module, an order management module, or a product display module.

[0054] In this embodiment, a data operation request refers to an instruction issued by the first micro-frontend application to change or query the status of shared data.

[0055] Optionally, data operation requests can carry information such as operation type, target data path, business priority prompt, and request source identifier.

[0056] S102: Based on the business semantics of the data operation request, acquire a lock for the target data item for the data operation request.

[0057] In this embodiment, business semantics refers to the contextual information carried in a data operation request that reflects the importance or urgency of the operation. This contextual information may include, but is not limited to: the type of business involved in the operation (e.g., payment settlement, data query), the user role initiating the request (e.g., administrator, ordinary user), the business criticality level of the target data (e.g., core transaction data, auxiliary configuration data), and the current system load. The target data item can be a data object pointed to by the data operation request, such as a user record, an order information, or a configuration object. Locks can be used to ensure that at any given time, only one data operation request can modify the target data item, thereby preventing data contention and state inconsistencies.

[0058] Specifically, the aforementioned business semantic information can be parsed from data operation requests. Based on this business semantic information, the current data operation request is comprehensively evaluated to determine its processing order relative to other concurrent requests. The availability of the lock associated with the target data item is checked. If the lock is not currently held by any other request, it is granted to the current data operation request, and the lock is marked as occupied, while the holder information is recorded. If the lock is already held by another request, the current request is placed in a waiting queue. Requests in the waiting queue are ordered according to their respective scheduling order. When the current lock holder completes its operation and releases the lock, the next request is selected from the waiting queue, removed from the queue, and the lock is granted, thus implementing concurrent access control based on business semantics.

[0059] S103: When the lock of the target data item is in a locked state, create a snapshot of the target data item before modification, and perform the data operation specified by the data operation request on the target data item.

[0060] In this embodiment, the locked state means that the current data operation request has successfully acquired the lock associated with the target data item, and the lock has not yet been released.

[0061] Optionally, a pre-modification snapshot is a complete or incremental record of the current data state of a target data item before any modifications are made to it. Pre-modification snapshots can be used for subsequent change tracking and possible rollback operations.

[0062] Specifically, after confirming that the lock is held by the current requester, the snapshot management function is invoked. The snapshot management function obtains the current data state of the target data item and generates a snapshot before modification. A globally unique operation identifier is generated for this data operation. After the snapshot is created, the specific data change logic specified in the data operation request is executed under the protection of the lock, such as modifying object properties, adding elements to an array, or deleting a field.

[0063] S104: After the data operation is completed, create a modified snapshot and calculate the data difference between the original snapshot and the modified snapshot.

[0064] In this embodiment, a post-modification snapshot refers to a record of the latest data state of the target data item after the data operation has been completed. Data difference refers to the set of change information obtained by comparing the pre-modification snapshot and the post-modification snapshot; this set describes the changed parts of the target data item and the values ​​before and after the change. Change events can be used to propagate state changes between micro-frontend sub-applications. A second micro-frontend sub-application refers to other micro-frontend functional modules that have subscribed to the target data item.

[0065] Specifically, after the data operations are completed, the snapshot management function is invoked again to obtain the current state of the target data item, forming a modified snapshot. Subsequently, the snapshot before modification and the snapshot after modification are compared, the data path is traversed, all locations where changes have occurred are marked, and a minimal description of the data differences is generated.

[0066] S105: Generate a change event that includes the operation result of the data operation and the data difference, and send the change event to the second micro-frontend application that subscribes to the target data item.

[0067] In this embodiment, change events can be constructed, each assigned a globally unique event identifier, and the operation result and data differences can be included in the event body. The change events are written to the event log to ensure recovery in the event of system failure.

[0068] Optionally, based on the subscription relationships maintained by the system, all second micro-frontend applications that have subscribed to the target data item are located, and the change event is sent to the second micro-frontend applications. In some embodiments, the sending process can be performed asynchronously and non-blockingly.

[0069] S106: After sending the change event, release the lock on the target data item to restore the target data item to an idle state.

[0070] In this embodiment, releasing the lock means that the current data operation request actively relinquishes its holding of the lock associated with the target data item. The idle state refers to a state where the lock is not held by any request, at which point a new request can acquire the lock.

[0071] Specifically, after the change event is sent, the current request invokes the lock management function to perform a lock release operation. The release operation clears the lock holder record and marks the lock state as idle. The lock management function checks whether there are any waiting requests in the waiting queue. If there are, the next request is retrieved in descending order of operation priority, the lock is granted to that request, and the lock state is switched to occupied; if the queue is empty, the lock remains in the idle state.

[0072] The method provided in this application can coordinate data change operations between multiple sub-applications under a micro-frontend architecture, effectively reducing data inconsistency and cross-application state anomalies, and improving the reliability and maintainability of the system.

[0073] In one embodiment provided in this application, based on the above-described solution, optionally, acquiring a lock for the target data item for the data operation request based on the business semantics of the data operation request includes:

[0074] Based on the business semantics of the data operation request, calculate the operation priority of the data operation request;

[0075] Based on the operation priority, the data operation request acquires the lock for the target data item.

[0076] In this embodiment, a higher operation priority value indicates that the request should be processed first.

[0077] Specifically, information indicated by business semantics can be extracted from data operation requests. This extracted information is then comprehensively evaluated according to preset rules to determine the operation priority of the request. After obtaining the operation priority, the current state of the lock associated with the target data item is checked. If the lock is idle, it is granted to the current request and the request is switched to a locked state. If the lock is locked, the current request is inserted into a waiting queue according to its operation priority. Once the lock is released, the request with the highest priority from the waiting queue is granted the lock.

[0078] In one embodiment provided in this application, based on the above-described scheme, optionally, the process of calculating the operation priority of the data operation request based on the business semantics of the data operation request is as follows: Figure 2 As shown, it includes:

[0079] S201: Extract at least one of the following semantic features from the data operation request, as indicated by the business semantics: operation type, user role initiating the data operation request, criticality of the data operated by the data operation request, and current system load.

[0080] In this embodiment, the operation type refers to the specific action category performed by the data operation request, which includes at least read, write, and delete operations. Different operation types have different sensitivities to data consistency. For example, write and delete operations may trigger state changes, and their priority may be higher than that of query operations that read data.

[0081] The user role that initiates the data operation request refers to attribute information that identifies the permission level or identity category of the request source, which can be obtained by parsing the authentication token carried in the request.

[0082] For example, user roles may include administrators, regular users, system service accounts, etc., and operations initiated by administrators may have higher processing priority.

[0083] In this embodiment, the criticality of the data operated on by the data operation request refers to the importance of the target data item in the business logic. Criticality can be marked by a pre-defined data dictionary or metadata tags. For example, operations involving core business data such as funds, orders, and user identities have a higher criticality level than page configuration or temporary cache data.

[0084] Optionally, the current system load refers to the workload status of the data processing system during operation, which may include indicators such as the lock manager's waiting queue length, the backlog in the event center, or the CPU utilization rate. In implementation, the above load information can be obtained in real time through the system monitoring interface.

[0085] Specifically, the operation type is extracted by parsing the type field in the request structure, which is populated by the first micro-frontend application when constructing the request. User roles are extracted by verifying the token attached to the request and reading the role declaration from the token's payload. Data criticality is extracted by querying a pre-established data asset catalog based on the target data path in the request; this catalog maintains a criticality score for each data item. The current system load is extracted by calling the system monitoring module's interface to obtain real-time load metrics. All four types of information can be extracted, or only a portion can be selectively extracted based on system configuration. When any information is missing, its corresponding weight contribution is set to zero.

[0086] S202: According to the preset weighting rules, the extracted semantic feature information is weighted and scored to generate a dynamic priority score.

[0087] In this embodiment, weighting rules can be used to determine the mapping relationship of the proportion of different semantic feature information in priority calculation. Weighted scoring refers to multiplying each extracted semantic feature information by its corresponding weight coefficient, and then summing the products to obtain a comprehensive score. Dynamic priority score refers to a value dynamically calculated based on the real-time context of the current request. The dynamic priority score can reflect the urgency of the request compared to other requests.

[0088] Optionally, the weighting rules can be configured using a multi-dimensional decision matrix. For example, the weighting coefficient for operation type can be set to give higher weights to write and delete operations, and lower weights to read operations. The weighting coefficient for user role can be set to give higher weights to administrator roles than to regular user roles. The weighting coefficient for data criticality can be set to give higher weights to core data than to auxiliary data. The weighting coefficient for the current system load can be set to give lower weights as the load increases, or a load correction factor can be used to adjust the final score.

[0089] In implementation, the extracted semantic features can be mapped to dimensionless scores. For operation types, write operations can be assigned higher scores, delete operations higher scores, and read operations lower scores. For user roles, administrator roles receive higher scores, and ordinary user roles receive lower scores. For data criticality, core data receives higher scores, and auxiliary data receives lower scores. For the current system load, the load value can be mapped to a score between 0 and 100, using a monotonically decreasing mapping method, meaning the higher the load, the lower the score. Then, each score is multiplied by its corresponding weight coefficient, and all products are summed to obtain the dynamic priority score. The sum of all weight coefficients is 1 to ensure the final score falls within a preset range. To avoid scores being too large or too small, the weighted summation result can be normalized to limit the final score to a preset range, such as an integer between 0 and 100. The higher the dynamic priority score, the earlier the data operation request should acquire the lock resource.

[0090] Furthermore, the weighted scoring process described above can be dynamically adjusted based on the request's waiting time. For example, an aging factor can be introduced, gradually increasing the effective priority of a request as its waiting time in the queue increases. This ensures that high-priority requests receive a fast response while preventing low-priority requests from being delayed for extended periods.

[0091] S203: Use the dynamic priority score as the operation priority of the data operation request.

[0092] In this embodiment, operation priority refers to the sorting key value used by the lock manager when scheduling requests.

[0093] Specifically, after the weighted scoring is calculated, the resulting dynamic priority score is written to the priority field of the request object. This field can be an integer or a floating-point number. When the request is subsequently submitted to the lock manager's waiting queue, the queue's sorting logic directly reads the value of this field for comparison. If the system is configured so that higher scores result in higher priority, the queue is sorted in descending order of score; otherwise, it is sorted in ascending order of score.

[0094] In one embodiment provided in this application, based on the above-described scheme, optionally, acquiring the lock of the target data item for the data operation request according to the operation priority includes:

[0095] Check the current state of the lock associated with the target data item;

[0096] If the lock is in an idle state, the lock is granted to the data operation request, and the state of the lock is switched to a locked state;

[0097] If the lock is in a locked state, the data operation request is placed in the priority waiting queue according to the operation priority. After the lock is released, the data operation request is retrieved from the priority waiting queue in descending order of priority and the lock is granted to the data operation request.

[0098] In this embodiment, a lock state record can be obtained. The lock state record contains at least three fields: the current state value (idle, locked, or a waiting queue reference), the current holder identifier, and the lock acquisition timestamp. By querying the lock state record, the current state of the lock associated with the target data item can be obtained.

[0099] Specifically, upon receiving a data operation request, the lock manager searches for the corresponding lock record in the lock state mapping table based on the target data item path carried in the request. If no record is found, it means that the target data item is not locked, and it can be considered as an idle state, and a lock record is created. If the state value is idle, the lock is granted to the target data item; if the state value is locked, the target data item is queued and waits.

[0100] In this embodiment, granting a lock means that the lock manager transfers control of the target data item to the current data operation request and updates the lock record to reflect this occupancy relationship. An idle state means that the lock is not held by any request; in this case, the holder identifier in the lock record is empty or invalid. Switching to a locked state includes the following specific actions: modifying the status field in the lock record from idle to locked; writing the identifier of the current data operation request into the holder field; and recording the current system timestamp as the lock acquisition time.

[0101] In practice, after completing the lock state transition, the lock manager returns a success response to the request, allowing the request to continue executing subsequent data operations. Information such as the type of lock allocation event, the target data item, and the request priority is recorded.

[0102] In this embodiment, a locked state indicates that the lock is already held by other data operation requests, and new requests cannot immediately acquire the lock. The priority waiting queue can be a container ordered according to operation priority, used to temporarily store requests that cannot immediately acquire the lock.

[0103] Specifically, when placing a data operation request into the queue, the lock manager first reads the operation priority value of the request and then inserts the request into the appropriate position in the queue based on this value. If a min-heap is used, lower priority values ​​are closer to the top of the heap, so the comparison logic needs to be adjusted according to the priority definition. After the insertion operation is completed, the request's status is marked as waiting. The lock manager can start a timeout timer for this request to prevent the request from waiting indefinitely due to an abnormal holder. The timeout period can be set according to the system configuration, such as 30 seconds or 1 minute.

[0104] When the current lock holder completes its data operation and actively releases the lock, the lock manager triggers a scheduling process. The scheduling process first checks if the priority waiting queue is empty. If the queue is not empty, the highest priority request is retrieved from the top of the queue, removed, and then a lock grant operation is performed, setting that request as the new lock holder and maintaining the lock state as locked. The awakened request then continues its subsequent data operations. If the queue is empty, the lock state is set to idle.

[0105] Additionally, when a request in the waiting queue waits for more than a preset threshold, the lock manager can release the lock and wake up the request at the head of the queue, or send a timeout notification to the holder requesting it to release the lock.

[0106] In one embodiment provided in this application, based on the above-described solution, optionally, creating a snapshot of the target data item before modification includes:

[0107] Invoke the snapshot manager to obtain the current complete data status of the target data item;

[0108] An incremental snapshot of the target data item is generated as a snapshot before modification.

[0109] In this embodiment, the snapshot manager can be a functional module for data state capture, storage, and recovery. Calling the snapshot manager means sending a snapshot creation command to the module through a predefined application programming interface (API), the command carrying at least the identifier of the target data item. Obtaining the current complete data state of the target data item means reading the current value of the data item from the shared data center.

[0110] Specifically, the current state can be obtained in two ways: First, directly read the current snapshot of the target data item from the global state store (such as the Redux store, Vuex store, or a self-developed centralized state tree); second, utilize the interception hooks provided by the data reactivity system to proactively capture the current value before data changes. To ensure the atomicity of the obtained state, i.e., it cannot be modified by other concurrent operations, this acquisition action should be performed after the current request has successfully acquired the lock of the target data item. Since the lock is already held by the current request, other requests cannot modify the data item simultaneously, thus the read operation is thread-safe. After the call is completed, the snapshot manager stores the current data state.

[0111] In this embodiment, incremental snapshots refer to recording the differences relative to a reference state (e.g., the previous snapshot or the initial state). Using an incremental approach can significantly reduce memory usage and storage overhead.

[0112] Optionally, incremental snapshots can be generated using a structure-sharing approach. Taking an immutable data model as an example, when the target data item is a tree, creating a snapshot only requires copying nodes from the root node to the nodes along the change path, while nodes outside the path directly reuse references from the old tree. For instance, if a user is about to modify a deep property of an object, the snapshot manager will copy the root object and each parent object along the path, but the unchanged parts of the child objects will still point to the original object. The resulting snapshot can be a new tree sharing most of its internal nodes with the current state, and its additional memory usage is proportional to the depth of the change path. Another implementation is to record the original value before the change, that is, only the old value of the field to be modified in the target data item is extracted and stored along with the field path in a lightweight change description object, without copying the entire data item.

[0113] Optionally, when generating incremental snapshots, the snapshot manager assigns a globally monotonically increasing operation sequence number to each snapshot. This sequence number serves two purposes: firstly, it uniquely identifies the current data operation; secondly, it establishes a connection with subsequent modified snapshots and change events, facilitating time travel debugging and state rollback. The operation sequence number is stored along with the incremental snapshot in the snapshot storage area. The storage medium can be an ordered list in memory or a persistent log file. When it is necessary to roll back to a specific operation, the corresponding pre-modification snapshot can be retrieved from the storage area based on the operation sequence number and then applied to the current state.

[0114] In one embodiment provided in this application, based on the above-described scheme, optionally, calculating the data difference between the snapshot before modification and the snapshot after modification includes:

[0115] Compare the snapshot before modification with the snapshot after modification to obtain the difference identification result, which includes the data path that has changed in the target data item, the old value before the change, and the new value after the change.

[0116] Based on the difference identification results, a minimal change description set is generated. The change description set contains at least one change entry, and each change entry records the change type, change path, old value, and new value.

[0117] The set of change descriptions is used as the data difference.

[0118] In this embodiment, the pre-modification snapshot and the post-modification snapshot record the complete state of the target data item before and after the data operation, respectively. The comparison operation involves a field-by-field, path-by-path structured comparison of the two snapshots to determine their differences. Since snapshots can contain nested objects, arrays, or basic data types, the comparison process requires a depth-first traversal algorithm, simultaneously traversing the data trees of both the pre-modification and post-modification snapshots. When a node is found on a path that exists in the pre-modification snapshot but not in the post-modification snapshot, the difference is identified as a deletion; when it does not exist in the pre-modification snapshot but exists in the post-modification snapshot, it is identified as an addition; when the node values ​​on the same path differ between the two snapshots, it is identified as a modification. The changed data path in the difference identification result can be represented by a hierarchical string separated by dots, such as "order information.delivery address.city". The old value before the change is taken from the data corresponding to that path in the pre-modification snapshot, and the new value after the change is taken from the data corresponding to that path in the post-modification snapshot.

[0119] Specifically, the comparison algorithm can be implemented using a recursive function. For object types, it iterates through all attribute names and compares the value corresponding to each attribute. For array types, comparisons can be made based on index position or the unique identifier of the array element. To improve comparison efficiency, a verification signature can be generated for each snapshot when it is created. When the root signatures of two snapshots are the same, they can be determined to be indistinguishable. The difference identification results can be temporarily stored in memory in the form of structured data, such as a difference list, where each element is a difference entry containing fields such as path, old value, new value, and difference type.

[0120] In this embodiment, the minimized change description set refers to simplifying potentially redundant or duplicated information in the difference identification results, retaining only the minimum dataset necessary to express the change. For example, when an entire array is replaced, the difference identification results might list the changes at each index position item by item, while the minimized set can abstract this as a single overall replacement operation, recording the array path, old array reference, and new array reference. Change types include, but are not limited to, addition, modification, deletion, and overall replacement. The change path is used to uniquely identify the data location where the change occurred. The old and new values ​​record the data segments before and after the change, respectively. For deletion-type changes, the new value can be ignored; for addition-type changes, the old value can be ignored.

[0121] Optionally, when generating a minimal change description set, changes to multiple consecutive sub-attributes within a nested object can be merged into a single change to the parent object. Similarly, for multiple insertions or deletions of elements in an array, operations within a consecutive range can be merged into a single range operation. In implementation, the change description set can use a structured array format, where each array element is an object containing the following fields: a change type field with values ​​of "Add," "Modify," "Delete," or "Replace"; a change path field with a dot-separated path string; an old value field storing the data before the change; and a new value field storing the data after the change.

[0122] In this embodiment, data differences refer to the representation of changes that occur from the pre-modification snapshot to the post-modification snapshot. Data differences can be used for cross-application state synchronization, as well as for change auditing, data rollback, and time travel debugging. When it is necessary to roll back the current state to the pre-modification state, the recovery operation can be reversed based on the change description set: replacing the new value in each change entry with the old value, or performing the addition and deletion operations in reverse. Through the above methods, accurate and efficient capture of data changes is achieved, completely describing the state change process with minimal data volume.

[0123] In one embodiment provided in this application, based on the above-described scheme, optionally, generating a change event that includes the operation result of the data operation and the data difference, and sending the change event to a second micro-frontend application subscribing to the target data item, includes:

[0124] Assign an event sequence number to the change event, and establish a mapping relationship between the event sequence number and the operation sequence number of the data operation;

[0125] The change event carrying the event sequence number, the operation result, and the data difference is stored in the event log;

[0126] Based on a preset subscription relationship table, determine the second micro-frontend application that subscribes to the target data item, and send the change event to the second micro-frontend application.

[0127] In this embodiment, a change event is a communication carrier that encapsulates the results of data operations and data differences. The event sequence number can be a globally monotonically increasing integer value used to identify each change event. The operation sequence number is an identifier assigned to the data operation when creating a snapshot before modification; it can also be globally monotonically increasing. Establishing a mapping relationship means creating a one-to-one correspondence between event sequence numbers and operation sequence numbers, and recording the association between the two internally. This mapping relationship can be stored in the event log or maintained in a separate mapping table. Through this association, when it is necessary to trace the change event corresponding to a certain data operation, the event sequence number can be quickly located based on the operation sequence number, and vice versa.

[0128] Specifically, when generating a change event, the event center requests the next available event sequence number from the sequence number generator. The sequence number generator guarantees that each returned value is larger than the previous one and will not be repeated throughout the entire system operation. Subsequently, the event center reads the operation sequence number assigned in the previous steps, combines this operation sequence number with the event sequence number to form a key-value pair, and writes it to the mapped storage area. The mapped storage area can be an ordered mapping table in memory or a persistent key-value database. When it is necessary to query the corresponding event based on the operation sequence number later, it can be retrieved directly from the mapped storage area.

[0129] In this embodiment, the event log is an append-only persistent storage structure used to record all change events that occur in the system. Storing events in the event log ensures reliability and recoverability: even if a system failure occurs during event transmission, the stored events will not be lost and can be retransmitted after system recovery. The operation result refers to the execution feedback of the data operation request, such as information like successful modification, failed modification, or the number of rows affected. The data difference is the minimized set of change descriptions obtained through the aforementioned difference calculation steps.

[0130] In implementation, event logs can be persisted using a local file system, a remote database, or a distributed message queue. During storage, information such as the event sequence number, operation result, data differences, source sub-application identifier, target data item path, and timestamp are organized into a log record according to a predefined format and then appended to the log file or database table. Write operations should employ a synchronous disk persistence strategy, meaning that success is only returned after confirming that the data has been safely written to physical storage, thereby minimizing data loss. After writing is complete, the event center receives confirmation that the event has been persisted and then proceeds to the sending phase.

[0131] In this embodiment, the subscription relationship table is a dynamic data structure maintained by the system, recording the subscription correspondence between each micro-frontend sub-application and the data items it is interested in. Each sub-application can register its target data item path with the system by calling the subscription interface during initialization or runtime. The system stores this registration information in the subscription relationship table, with each entry containing the subscriber identifier and the subscribed data path. When a data item changes, the system queries the subscription relationship table based on the data item path to obtain a list of all sub-applications that have subscribed to that path or its parent path. The second micro-frontend sub-application refers to other sub-applications that have subscribed to the current target data item; their number can be zero or one or more.

[0132] Specifically, after the event log is written, the event center reads the subscription relationship table and searches for all subscribers whose paths match the target data item. Once the subscriber list is determined, the event center sends the change event to each subscriber asynchronously and non-blockingly. Sending can be done via Hypertext Transfer Protocol calls, message queue push, or a custom inter-process communication mechanism. For each subscriber, the event center records the sending time, the number of times it was sent, and its current status (pending, sending, acknowledged). This step ends after sending is complete.

[0133] and Figure 1 Corresponding to the method described herein, embodiments of this application also provide a data processing apparatus, applied to an electronic device, for processing data... Figure 1 The specific implementation of the method is shown in the schematic diagram of the device. Figure 3 As shown, it includes:

[0134] The receiving unit 301 is used to receive a data operation request initiated by the first micro front-end application;

[0135] The first calculation unit 302 is used to acquire a lock for the target data item for the data operation request based on the business semantics of the data operation request;

[0136] The creation unit 303 is used to create a snapshot of the target data item before modification when the lock of the target data item is in a locked state, and to perform the data operation specified by the data operation request on the target data item.

[0137] The second calculation unit 304 is used to create a modified snapshot after the data operation is completed, and to calculate the data difference between the snapshot before modification and the snapshot after modification.

[0138] The generation unit 305 is used to generate a change event that includes the operation result of the data operation and the data difference, and send the change event to the second micro-frontend application that subscribes to the target data item;

[0139] The execution unit 306 is used to release the lock of the target data item after completing the sending of the change event, so that the target data item is restored to an idle state.

[0140] In one embodiment provided in this application, based on the above-described solution, optionally, the first computing unit includes:

[0141] An extraction subunit is used to extract at least one piece of information from the data operation request: operation type, user role that initiated the data operation request, criticality of the data operated by the data operation request, and current system load.

[0142] A sub-unit is generated to perform weighted scoring on the extracted information according to a preset weighting rule, and generate a dynamic priority score.

[0143] An execution subunit is used to use the dynamic priority score as the operation priority of the data operation request.

[0144] The specific principles and execution processes of each unit and module in the data processing apparatus disclosed in the above embodiments of this application are related to... Figure 1 The data processing methods disclosed in the embodiments are the same, and can be found in the corresponding parts of the data processing methods provided in the embodiments of this application above, which will not be repeated here.

[0145] This application also provides a storage medium, which includes stored instructions, wherein when the instructions are executed, the device where the storage medium is located is controlled to perform the above-described data processing method or the above-described control method for a mobile device.

[0146] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 4 As shown, it specifically includes a memory 401 and one or more instructions 402, wherein one or more instructions 402 are stored in the memory 401 and are configured to be executed by one or more processors 403 to perform the above-described data processing method.

[0147] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0148] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0149] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0150] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0151] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data processing method, characterized in that, include: Receive a data operation request initiated by the first micro front-end application; Based on the business semantics of the data operation request, acquire the lock for the target data item for the data operation request; If the lock on the target data item is locked, create a snapshot of the target data item before modification, and perform the data operation specified in the data operation request on the target data item. After the data operation is completed, a modified snapshot is created, and the data differences between the pre-modification snapshot and the modified snapshot are calculated; Generate a change event that includes the operation result of the data operation and the data difference, and send the change event to the second micro-frontend application that subscribes to the target data item; After the change event is sent, the lock on the target data item is released, restoring the target data item to an idle state.

2. The method according to claim 1, characterized in that, The business semantics based on the data operation request, for which a lock is acquired for the target data item in the data operation request, includes: Based on the business semantics of the data operation request, calculate the operation priority of the data operation request; Based on the operation priority, the data operation request acquires the lock for the target data item.

3. The method according to claim 2, characterized in that, The calculation of the operation priority of the data operation request based on the business semantics of the data operation request includes: Extract at least one of the following semantic features indicated by the business semantics from the data operation request: operation type, user role initiating the data operation request, criticality of the data operated by the data operation request, and current system load; According to the preset weighting rules, the extracted semantic feature information is weighted and scored to generate a dynamic priority score; The dynamic priority score is used as the operation priority of the data operation request.

4. The method according to claim 2, characterized in that, The step of acquiring a lock for the target data item for the data operation request according to the operation priority includes: Check the current state of the lock associated with the target data item; If the lock is in an idle state, the lock is granted to the data operation request, and the state of the lock is switched to a locked state; If the lock is in a locked state, the data operation request is placed in the priority waiting queue according to the operation priority. After the lock is released, the data operation request is retrieved from the priority waiting queue in descending order of priority and the lock is granted to the data operation request.

5. The method according to claim 1, characterized in that, The creation of the pre-modification snapshot of the target data item includes: Invoke the snapshot manager to obtain the current complete data status of the target data item; An incremental snapshot of the target data item is generated as a snapshot before modification.

6. The method according to claim 1, characterized in that, The calculation of the data difference between the snapshot before modification and the snapshot after modification includes: Compare the snapshot before modification with the snapshot after modification to obtain a difference identification result. The difference identification result includes at least one of the data path that has changed in the target data item, the old value before the change, and the new value after the change. Based on the difference identification results, a minimal change description set is generated. The change description set contains at least one change entry, and each change entry records at least one of the change type, change path, old value, and new value. The set of change descriptions is used as the data difference.

7. The method according to claim 1, characterized in that, The process of generating a change event that includes the operation result of the data operation and the data difference, and sending the change event to a second micro-frontend application subscribed to the target data item, includes: Assign an event sequence number to the change event, and establish a mapping relationship between the event sequence number and the operation sequence number of the data operation; The change event carrying the event sequence number, the operation result, and the data difference is stored in the event log; Based on a preset subscription relationship table, determine the second micro-frontend application that subscribes to the target data item, and send the change event to the second micro-frontend application.

8. A data processing apparatus, characterized in that, include: The receiving unit is used to receive data operation requests initiated by the first micro front-end application; The first computing unit is used to acquire a lock for the target data item for the data operation request based on the business semantics of the data operation request; A creation unit is configured to, when the lock of the target data item is in a locked state, create a snapshot of the target data item before modification, and perform the data operation specified by the data operation request on the target data item; The second calculation unit is used to create a modified snapshot after the data operation is completed, and to calculate the data difference between the snapshot before modification and the snapshot after modification. A generation unit is configured to generate a change event that includes the operation result of the data operation and the data difference, and send the change event to a second micro-frontend application that subscribes to the target data item; The execution unit is used to release the lock of the target data item after completing the sending of the change event, so that the target data item is restored to an idle state.

9. A storage medium, characterized in that, The storage medium includes stored instructions, wherein, when the instructions are executed, the device containing the storage medium is controlled to perform the data processing method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes a memory, and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described in any one of claims 1 to 7.

Images