A cross-platform session state reconstruction method and system based on event trace source

Abstract

The application discloses a cross-platform session state reconstruction method and system based on event trace source, relates to the field of cross-platform customer service integration, and comprises the following steps: introducing a measurable business impact weight for cross-platform field events in a business semantic-based event formatting mode, and maintaining cross-platform event order in combination with a vector clock; through time sequence cumulative calculation of the event weight, a state summary of a truly key event in business significance is adaptively selected to generate, instead of taking a snapshot based on fixed time or a fixed number, so that the data transmission amount and the calculation overhead required for state reconstruction are significantly reduced; in the client recovery stage, only the summary and the incremental event after the summary need to be transmitted, so that the client can still quickly reconstruct the state at a low cost in a weak network and low bandwidth environment. Therefore, the differentiated compression and recovery of the cross-platform event trace source semantic level are realized, and the session reconstruction efficiency and resource utilization efficiency in a large-scale multi-platform scenario of customer service are greatly improved.

Description

Technical Field

[0001] This application relates to the field of cross-platform customer service integration technology, and in particular to a cross-platform session state reconstruction method and system based on event tracing. Background Technology

[0002] In cross-platform interaction scenarios, user actions are scattered across multiple independent systems (such as mobile applications, web applications, and third-party services), resulting in complete session state information being fragmented and stored in the backend databases of different platforms. This data fragmentation makes it impossible for any single system to obtain a global session view. Especially in businesses that require continuous state maintenance, such as e-commerce and online customer service, users face the risk of losing state when switching devices or platforms.

[0003] Current cross-platform customer service systems typically rely on a strong server-side state synchronization mechanism, requiring all platforms to report operation details to a central server in real time. This results in massive amounts of redundant network transmission, and in weak network environments, frequent data packet loss leads to state inconsistencies. Simultaneously, terminal devices need to fully load historical operation records for local state reconstruction, placing significant computational pressure on low-performance devices and causing recovery delays to exceed the user's tolerance threshold.

[0004] In addition, while high-frequency state snapshots can improve recovery speed, they significantly increase storage overhead; while sparse snapshot strategies save resources, they force clients to replay a large number of events, resulting in minute-level reconstruction delays in complex session scenarios. It is difficult to effectively balance the contradiction between real-time performance and resource consumption, especially in cross-platform, multi-device interactive environments. Summary of the Invention

[0005] This application provides a method, system, storage medium, computer program product, and electronic device for cross-platform session state reconstruction based on event tracing, in order to at least solve the problems of difficulty in guaranteeing cross-platform session state consistency and excessive recovery costs in the current related technologies.

[0006] In a first aspect, embodiments of this application provide a cross-platform session state reconstruction method based on event sourcing. The method includes: acquiring an original event stream generated by cross-platform user operations; uniformly formatting the original event stream according to event type, source platform, payload content, and timestamp to generate domain events carrying predefined business impact weights; classifying and storing the domain events in an event repository according to session identifiers, and assigning a vector clock to each event to maintain the cross-platform event order; performing time-series cumulative calculations on each stored domain event, detecting at least one target domain event in each domain event whose cumulative business impact weight exceeds a dynamic weight threshold, and generating a session state summary based on the event characteristics of each target domain event; and, in response to a client's session recovery request, sending the session state summary and incremental domain events after the generation time of the session state summary to the client, enabling the client to restore the initial state based on the session state summary and replay the incremental domain events in vector clock order to reconstruct the session state.

[0007] Secondly, embodiments of this application provide a cross-platform session state reconstruction system based on event sourcing. The system includes: an event generation unit, used to acquire the original event stream generated by cross-platform user operations, and uniformly format the original event stream according to event type, source platform, payload content, and timestamp to generate domain events carrying predefined business impact weights; an event library maintenance unit, used to classify and store the domain events in an event library according to session identifiers, and assign a vector clock to each event to maintain the cross-platform event order; a session summary generation unit, used to perform time-series cumulative calculation on each stored domain event, detect at least one target domain event in each domain event whose cumulative value of business impact weight exceeds a dynamic weight threshold, and generate a session state summary according to the event characteristics of each target domain event; and a session reconstruction unit, used to respond to a client's session recovery request, send the session state summary and incremental domain events after the generation time of the session state summary to the client, so that the client can restore the initial state based on the session state summary and replay the incremental domain events in vector clock order to reconstruct the session state.

[0008] Thirdly, an electronic device is provided, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the event sourcing-based cross-platform session state reconstruction method of any embodiment of this application.

[0009] Fourthly, embodiments of this application provide a storage medium storing a computer program thereon, characterized in that, when the program is executed by a processor, it implements the steps of the event sourcing-based cross-platform session state reconstruction method of any embodiment of this application.

[0010] Fifthly, embodiments of this application provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the event-based cross-platform session state reconstruction method of any embodiment of this application.

[0011] The cross-platform session state reconstruction method and system based on event sourcing provided in this application can achieve at least the following technical effects:

[0012] (1) By uniformly formatting and associating original cross-platform events with vector clocks, and aggregating events into domain events carrying business impact weights, a comparable, traceable, and measurable state evolution structure can be constructed between heterogeneous operational behaviors on multiple platforms. This enables the system to accurately identify the main factors of state impact intensity under cross-platform concurrency conditions and reduces the risk of session state misalignment caused by out-of-order, delay, and multi-source event conflicts. As a result, cross-platform sessions still maintain consistent reproducibility in complex interactive environments such as weak network environments, asynchronous synchronization, and terminal switching.

[0013] (2) By dynamically determining the timing of state summary generation based on the time-series cumulative judgment of business impact weight, the summary generation is transformed from fixed-period triggering to data validity-driven, thereby avoiding the solidification of invalid states. At the same time, this summary serves as a state anchor point, and state recovery can be completed by simply sending incremental domain events after the summary time point to the client. This reduces the client's full replay computation burden, making the recovery cost related to recent valid change data, rather than processing a full scale of historical session data. This significantly reduces network burden and recovery latency, allowing low-performance terminals to still have an acceptable state recovery time when resuming cross-terminal sessions.

[0014] This technical solution employs weight-driven event sourcing and dynamic state summarization, and performs incremental replay under vector clock constraints. This transforms the complexity of cross-platform session state recovery from historical scale dependence to a controllable boundary dominated by the density of key impact events, forming a new balance mechanism between recovery real-time performance and resource costs, and improving the ability to construct continuous states across platforms. Attached Figure Description

[0015] 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating an example of an event-based cross-platform session state reconstruction method according to an embodiment of this application is shown.

[0017] Figure 2 A flowchart illustrating an example of generating a domain event according to an embodiment of this application is shown.

[0018] Figure 3 A flowchart illustrating an example of issuing a session state summary according to an embodiment of this application is shown.

[0019] Figure 4 A flowchart illustrating an example of generating a session state summary according to an embodiment of this application is shown.

[0020] Figure 5 A flowchart illustrating an example of incremental coding compression processing based on domain semantics according to an embodiment of this application is shown.

[0021] Figure 6 A schematic diagram illustrating the effect of different reconstruction times as a function of the number of events is shown;

[0022] Figure 7 This diagram illustrates the effect of different methods on network throughput as a snapshot interval.

[0023] Figure 8 A structural block diagram of an example of an event sourcing-based cross-platform session state reconstruction system according to an embodiment of this application is shown. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, 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.

[0025] Currently, some experts and scholars have put forward some new insights into the technology of platform customer service systems, but there are still certain limitations.

[0026] Currently, many customer service system platforms use a single relational database to store the current state of a session. Each write operation directly updates the database table, and read operations directly access the latest state. The advantages are simplicity and fast query speed; the disadvantages are the inability to rewind history and the inability to seamlessly switch between multiple devices. When a user switches from a web-based customer service interaction to a mobile device, the system can only provide the latest state and cannot accurately reconstruct every interaction in between, resulting in incomplete context. Furthermore, the traditional CRUD pattern is prone to transaction lock contention under high concurrency, leading to performance degradation.

[0027] To cope with high-load scenarios, the industry is increasingly adopting Event Sourcing and Command Query Responsibility Separation (CQRS) patterns. Event sourcing treats each state change as an immutable event and appends it to the event store in chronological order. When it is necessary to backtrack or rebuild the state, the precise state at a specific moment can be obtained by replaying the event sequence. Compared with the traditional CRUD pattern, event sourcing provides historical traceability, auditing capabilities, and better concurrent processing performance.

[0028] Specifically, the event sourcing pattern saves each state change as an event to an event store. In microservice architecture websites, when the number of entity events is large, periodic snapshots can improve loading performance. The advantages of event sourcing include event immutability, auditing capabilities, and decoupling of read-write models. However, this pattern also has some drawbacks:

[0029] 1) High cost of event replay: The system needs to replay the complete event sequence to build the current state. When the event stream is too long, this will become a major performance bottleneck.

[0030] 2) Version and compatibility: The event schema (data schema) should not be modified. When the schema needs to be upgraded, additional processing logic needs to be written for the old and new versions.

[0031] 3) Event ordering and consistency: In a multi-instance or multi-threaded environment, event ordering and merging are complex issues. Events need to be marked with timestamps or an increasing sequence to ensure consistent order.

[0032] 4) Lack of differentiation in replay process: All events are replayed without distinction of importance, ignoring the differences in the importance of business events, resulting in low efficiency.

[0033] To address the cost of replay, some event sourcing systems have introduced snapshot mechanisms. Snapshots record the entity's state at a specific point in time; during reconstruction, subsequent events are replayed starting from the most recent snapshot. Snapshots reduce the number of events that need to be replayed, improving read performance, and are created periodically based on the number of events. However, snapshot creation strategies are typically based on a fixed number of events or time intervals, lacking consideration for event weight and business semantics, and a large number of snapshots consume significant storage space. Furthermore, snapshots still require the client to completely replay all events after the snapshot, and mobile devices may still face performance bottlenecks in weak network environments. In addition, event sourcing leads to a large amount of event storage; however, current compression strategies are mostly simple merging rules, lacking dynamic evaluation of the importance of different event types and failing to address optimization needs under different terminal capabilities and network environments.

[0034] It should be understood that the above description of the relevant technologies is intended only to help the public better understand the inventive spirit and motivation of this application, and is not intended to limit this application. Furthermore, the technical solutions described in the above-mentioned relevant technologies are not prior art, and may also be undisclosed technical solutions, such as those under research or in the laboratory stage.

[0035] The technical solutions in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of users' personal information, comply with relevant laws and regulations and do not violate public order and good morals.

[0036] Figure 1 A flowchart illustrating an example of an event-based cross-platform session state reconstruction method according to an embodiment of this application is shown.

[0037] Regarding the execution subject of the method in the embodiments of this application, it can be any controller or processor with computing or processing capabilities, especially a cross-platform session reconstruction controller integrated on the server side. Through a unified domain event model based on event sourcing, vector clock ordered control, and weight-driven dynamic state summary generation, it achieves efficient and consistent reconstruction of session state in complex interaction scenarios involving multiple terminals and multiple platforms.

[0038] In some examples, it may be integrated into an electronic device or terminal through software, hardware, or a combination of both, and the type of terminal or electronic device may be diverse.

[0039] like Figure 1 As shown, in step S110, the original event stream generated by cross-platform user operations is obtained, and the original event stream is uniformly formatted according to the event type, source platform, payload content and timestamp to generate domain events carrying predefined business impact weights.

[0040] In cross-platform interaction scenarios, user actions originate from diverse sources (such as mobile devices, web applications, and third-party interfaces), and the event data structures and timestamp standards differ across platforms, making direct integration difficult. Therefore, a unified event formatting mechanism is used to abstract the raw event stream into structured domain events, enabling comparable and traceable event representation across systems.

[0041] In some implementations, the raw event stream generated across platforms is acquired, and core elements of the events are extracted, such as event type (e.g., click, submit, redirect), source platform identifier, payload content, and timestamp. Subsequently, the events are uniformly encoded according to a predefined format template, transforming them into domain event objects with a unified structure. Each event is assigned a predefined business impact weight, reflecting the event's importance in the evolution of the session state. For example, in a cross-platform customer service system for e-commerce, the "place an order" event might be assigned a weight of 0.9, while "browse product details" might be assigned a weight of 0.2, reflecting different levels of impact on the session state.

[0042] Through formatting and weighting mechanisms, the originally heterogeneous and disordered event streams are unified into a parsable structural space. This enables the identification of key business turning points based on weight changes, thereby quantifying the impact of events at different times on the session state and achieving semantic aggregation and importance stratification of events.

[0043] In step S120, domain events are categorized and stored in the event repository according to session identifiers, and a vector clock is assigned to each event to maintain the cross-platform event order.

[0044] In some implementations, all events are categorized and stored in corresponding event repositories based on the session identifier carried by each event, forming an event set based on sessions. Each event is assigned a vector clock before storage. This clock, composed of multi-dimensional counters, reflects the causal relationships between events, rather than their sequential order on a single timeline. For example, if two operations are triggered simultaneously on a mobile device and a web device, and if they are independent, they can be recorded in parallel; if one event depends on another (such as payment confirmation depending on order submission), the partial order of the vector clock accurately reflects this dependency. Thus, the accuracy of event causality is maintained even in asynchronous, delayed, or out-of-order scenarios, avoiding state misordering problems.

[0045] In step S130, time-series cumulative calculations are performed on the stored domain events, at least one target domain event in each domain event whose cumulative business impact weight exceeds the dynamic weight threshold is detected, and a session state summary is generated based on the event characteristics of each target domain event.

[0046] It should be noted that the number of events in the event repository accumulates rapidly over time, and directly replaying all events would lead to delays in state recovery and increased computational resource consumption. Therefore, this application proposes a time-series accumulation mechanism based on business impact weights to dynamically identify significantly impactful event segments, generate state summaries, and achieve critical state solidification and redundancy compression.

[0047] In some implementations, events in each domain are traversed in the event repository, and time-series cumulative calculations are performed according to their vector clock order. Whenever the cumulative weight exceeds a dynamic weight threshold, a summary generation operation is triggered, which solidifies all state changes up to that event into a structured session state summary.

[0048] The dynamic weight threshold can be adaptively adjusted based on the business type and system load. For example, in high-frequency interaction scenarios (such as online customer service), the threshold can be appropriately increased to reduce frequent fixation; in high-value state change scenarios (such as transaction confirmation), the threshold can be decreased to ensure timely snapshot generation.

[0049] By employing a weight-driven summary generation strategy, the redundancy of traditional fixed-interval snapshots is avoided, while also addressing the issue of excessive replay latency caused by sparse snapshots. Furthermore, the generation frequency of session state summaries is strongly correlated with the actual validity of business events, eliminating the need to generate summaries for all events, thus significantly reducing storage and transmission burden.

[0050] In step S140, in response to the client's session recovery request, a session state summary and incremental domain events after the generation time of the session state summary are sent to the client, enabling the client to restore the initial state based on the session state summary and replay the incremental domain events in vector clock order to reconstruct the session state.

[0051] When a user reconnects or switches terminals, requiring the client to replay all events from scratch would result in unacceptable recovery latency. In this embodiment, a session recovery mechanism combining session state digests and incremental events is employed. This mechanism restores the session state by sending the latest state digest and incremental events since the digest point.

[0052] Specifically, when a client initiates a session recovery request, the server retrieves the latest state summary of the corresponding session and filters and generates a set of incremental domain events after the summary time point. Then, both sets of data are sent to the client. Upon receiving the data, the client first restores the initial session state directly based on the summary, and then replays the incremental events in vector clock order to reconstruct the complete state. This allows the client to process only a limited number of incremental events, significantly reducing computational complexity and memory consumption. The state recovery latency is changed from being proportional to the total number of events to being proportional to the number of incremental events after the summary point. Thus, even in low-performance devices or high-latency network environments, the recovery latency is anchored within a controllable range of "recent effective changes," still supporting millisecond-level or second-level session state recovery, significantly improving user experience and system robustness.

[0053] Figure 2 A flowchart illustrating an example of generating a domain event according to an embodiment of this application is shown.

[0054] like Figure 2 As shown, in step S210, based on the preset event semantic classification rules, various original events from cross-platform multi-type user interaction events in the original event stream are mapped to a unified set of event abstract types.

[0055] Because different platforms exhibit heterogeneity in event field structure, parameter naming, and behavior expression (e.g., "BUY", "AddToCart", and "Add to Cart" may all represent the same semantics), it is difficult to accurately determine the actual impact of events on session evolution if the original format is used directly for state analysis.

[0056] Specifically, this is achieved by defining a semantic dictionary and a rule mapping function. To achieve the original event Abstract semantic mapping:

[0057] Equation (1)

[0058] in, This represents the normalized abstract event type. Through this process, heterogeneous events from cross-platform and cross-terminal sources can be uniformly projected into a consistent semantic space.

[0059] In step S220, corresponding business influence weights are assigned to each event abstract type according to the business weight relationship table, thereby forming domain event instances carrying business influence weights.

[0060] In some examples, the business weight relationship table pre-stores multiple calibrated domain events and their corresponding business impact weights, where the calibrated domain events include any one of the following: payment success event, product add-to-cart event, product details browsing event, message sending event, or work order change event.

[0061] For example, weights can be assigned in the following ways:

[0062] Equation (2)

[0063] in, For the predefined set of business impact weights in the business weight relationship table, payment success events... The event with the highest weight, added to cart Centering, Product Details View Event Weight The lowest. This hierarchical weighting mechanism allows for the differentiation of contributions from different event types during state accumulation, thereby preventing low-value events from drowning out high-value key events during accumulation, and making state evolution evaluation more interpretable, quantifiable, and auditable.

[0064] In step S230, the source platform identifier, payload data representation, timestamp precision, and event sequence number of the domain event instance are standardized across platforms.

[0065] For example, events can be uniformly resampled or recoded into a uniform format:

[0066] Equation (3)

[0067] In the formula, For platform identification, For standardized load expression, For high-precision timestamps after unified time base synchronization processing, For event sequence numbering, For abstract types, Weighting is applied to business impact. This unified and standardized process ensures that domain events have a consistent reference scale and time system in subsequent cross-platform time series accumulation, partial order constraint maintenance, and summary layer selection processes. This provides the cross-platform state reconstruction model with a reliable input consistency and data access foundation, enhancing the accuracy and robustness of end-to-end state recovery.

[0068] Regarding the explanation of session state summaries, different business scenarios have varying requirements for state recovery speed, state accuracy, and resource consumption. A single-granularity state summary cannot simultaneously ensure real-time recovery and state integrity. Therefore, in some examples of this application's embodiments, a multi-level summary structure is introduced to enable the session state to be resolved progressively, establishing layered availability for the recovery terminal.

[0069] More specifically, the generated session state summary is a multi-level session state summary, which includes coarse-grained session state summary, medium-grained session state summary and fine-grained session state summary.

[0070] The coarse-grained session state digest contains state hash values ​​determined based on the event characteristics of events in each target domain. These state hash values ​​represent the overall consistent structural characteristics of the current state space, exhibiting a highly compressed form that can be used for rapid state fingerprint matching. For example, when a client only needs to "quickly determine whether recovery is needed" (e.g., an e-commerce app returning to the foreground, a customer service window briefly switching to the background), this digest can be used for a second-level comparison. If the states match, the recovery process can be skipped, avoiding meaningless replays and reducing unnecessary network consumption and client processing overhead.

[0071] The medium-granularity session state summary contains state hash values ​​and event features of a preset number of target domain events ranked by weight, used to provide local state stabilization nodes. These event features directly affect the reconstruction of core state constraints, such as order state transitions, user identity changes, and session intent switching. This summary maintains a compact size while allowing clients to obtain the key state structure without fully replaying the complete incremental chain.

[0072] Fine-grained session state summaries contain state hash values ​​and compressed event features of each target domain event. Specifically, in addition to state hash values, fine-grained summaries also include domain-specific compressed event features of each target domain event. Compression can employ techniques such as feature vector dimensionality reduction, semantic field preservation and extraction, and structural fragment pruning to ensure that each event retains the core semantic information necessary to construct a complete state. Fine-grained summaries can then be used as a complete semantic basis for directly reconstructing an executable state tree.

[0073] Therefore, through the multi-level session state summary mechanism of this application embodiment, the summary of session state is transformed into a multi-granularity form that can be hierarchically and progressively selected, enabling the system to dynamically balance performance, network cost and state semantic integrity.

[0074] In some business application scenarios, when executing the state recovery process, the client can select the digest granularity as needed based on network conditions, current device computing power, and business scenario requirements. This enables controllable time cost, controllable resource consumption, and controllable state consistency assurance during cross-platform session state recovery, significantly improving the continuity and recovery efficiency of session state in cross-platform interactive environments.

[0075] Figure 3 A flowchart illustrating an example of issuing a session state summary according to an embodiment of this application is shown.

[0076] In step S310, the terminal communication performance index of the client is obtained. The terminal communication performance index is used to characterize the data transmission carrying capacity of the client.

[0077] In some implementations, after detecting a session recovery request initiated by the client, the server extracts performance metrics characterizing the communication link's carrying capacity from the data communication characteristics reported by the client. These metrics include current available bandwidth information, current network quality status information, and real-time packet loss ratio estimates. By using these terminal communication performance metrics, the server can quantify the client's actual data interaction capabilities in the current network environment. This allows the server to determine whether the client is suitable for receiving higher-granularity data content or can only handle lower-granularity summary expressions, thus avoiding the direct delivery of excessively large data structures in weak network scenarios, which could lead to recovery failure or excessive latency.

[0078] For example, the terminal communication performance index can be calculated using the following formula:

[0079] Equation (4)

[0080] In the formula, For terminal communication performance indicators, This is an estimate of the currently available bandwidth. This represents the real-time packet loss ratio under the current network link. A network stability score calculated based on client network quality status information; These are preset weighting coefficients used to adjust the combined impact of available bandwidth, packet loss suppression capability, and network stability. Thus, through terminal communication performance indicators, the data transmission capacity of the client in the current network environment is quantified.

[0081] In step S320, a target granularity level that matches the terminal communication performance index is determined, and a session state summary corresponding to the target granularity level is sent to the client. The target granularity level is any one of the following: coarse-grained, medium-grained, or fine-grained.

[0082] In some implementations, the server dynamically estimates the amount of data the client can currently handle based on terminal communication performance metrics, and selects between three session state summary levels: coarse-grained, medium-grained, and fine-grained. For example, when the terminal communication performance metrics are detected to be at a low level, the server may choose to send only a coarse-grained session state summary to reduce data transmission volume and end-side processing overhead; when the terminal communication capabilities are detected to be at a medium or high level, the server may choose a medium-grained or fine-grained session state summary respectively, allowing the client to obtain more complete session state details. Thus, the server can adaptively adjust the data content sent according to the differences in the client's communication capabilities, effectively improving the success rate and speed of session recovery.

[0083] In some examples of embodiments of this application, the average packet size of each level is obtained, and the level is selected based on the target transmission efficiency constraint relationship between the average packet size and the terminal communication performance index to determine the target granularity level that matches the terminal communication performance index.

[0084] In some implementations, the server pre-calculates the average packet size of the session state digest at different granularity levels based on historical business data and network transmission statistics. , where the granularity level set .

[0085] Upon detecting the terminal communication performance metrics reported by the client. Then, the server bases the calculation on the average packet size. Communication performance indicators with terminals The hierarchical selection is based on the target transmission efficiency constraints between the nodes to determine the acceptable target granularity level for the terminal under the current network conditions. The selection rule can be determined by the following formula:

[0086] Equation (5)

[0087] In the formula, Indicates the target granularity level. The target transmission delay ratio, For terminal communication performance indicators, Representing granularity levels L Average package size This represents a set of granularity levels.

[0088] Here, the server calculates the relative deviation between the current network's carrying capacity and the average packet size at different granularity levels in real time, and selects the granularity level with the smallest deviation as the target granularity level. This enables an adaptive digest granularity distribution strategy for different network conditions. Since terminals cannot carry large, high-granularity digest structures in weak network scenarios, the above selection mechanism avoids the risk of excessive data transmission failure or significant recovery delays in weak network conditions. Under good network conditions, higher-granularity data structures can be distributed, allowing clients to achieve higher-precision state recovery with less incremental event replay, thereby improving the overall efficiency and consistency of state reconstruction. This ensures that the session state recovery process can balance data accuracy and data transmission efficiency.

[0089] Figure 4 A flowchart illustrating an example of generating a session state summary according to an embodiment of this application is shown.

[0090] In step S410, the business impact weights corresponding to each target domain event are calculated by exponential decay to obtain the cumulative weight value.

[0091] In some implementations, the business impact weight of each event is accumulated over time using a time-ordered sequence of domain events as input. Exponential decay is used to make events that are closer to the time contribute more to the accumulated result, while the influence of historical events that are further apart gradually fades, so that the accumulated weight value is updated accordingly as the event flow progresses.

[0092] Equation (6)

[0093] In the formula, This is the historical weight decay coefficient. For time Events that occurred in the target area The weight of business influence; To accumulate events in the target domain within the event sequence. The cumulative business impact weight at any given time.

[0094] For example, each time a new event (timestamp) arrives... That is, update once according to formula (3). Attenuation coefficient During deployment, parameters are adjusted according to the scenario. For example, 0.7-0.9 can be used for IM (instant messaging) conversations, and 0.5-0.8 can be used for transactional conversations to highlight recent actions. In this way, responsiveness (with greater weight for recent events) and stability (with historical noise diluted) are balanced, providing a monotonic signal with interpretable and controllable thresholds for the triggering strategy.

[0095] In step S420, summary generation is triggered when the cumulative weight value is detected to exceed the adaptive threshold.

[0096] Here, the adaptive threshold is determined by the following formula:

[0097] Equation (7)

[0098] In the formula, As the baseline threshold, For adjustment coefficients, For time Session complexity metrics This refers to network bandwidth performance metrics. For time Adaptive threshold.

[0099] Here, the adaptive threshold is dynamically adjusted according to session complexity and network capacity. In equation (4), with... Based on the benchmark, by adjusting the coefficient Introducing session complexity With bandwidth capability indicators The ratio. Complexity metrics can be obtained from online statistics (such as the weighted sum of the number of participants, the number of concurrent sub-sessions, the number of unmerged events within the most recent window, and the number of unconfirmed milestone events). Therefore, the triggering timing adapts to the scenario and link. In weak network / high-complexity sessions, the current state is "solidified" more quickly to reduce future replay burden and failure rate; while in good network or simple session scenarios, excessive digest segmentation is avoided to reduce unnecessary storage and management overhead.

[0100] In step S430, when the summary generation is triggered, for each historical domain event between the previous summary generation time and the current time, the historical domain events are mapped to the event state vector based on the state encoding function, and then the state hash value is calculated.

[0101] In some implementations, upon triggering, the historical domain events from the previous summary to the current window are mapped to event state vectors and weighted and aggregated. The aggregation result is then hashed to obtain the summary root information, which is used as a version / consistency anchor.

[0102] Specifically, the state hash value can be calculated using the following formula:

[0103] Equation (8)

[0104] In the formula, Indicates the first Events in a historical field, For historical events The timestamp of the occurrence The first domain event index after the previous summary is generated, so that the state hash value can be used to form the summary root information of the session state summary; Indicates time The corresponding state hash value, For state encoding functions, For time Historical events that occurred The weight of business impact.

[0105] In equation (5), the state coding function As pure functions, this ensures that the same event input will always produce the same vector representation, avoiding inconsistencies introduced by platform differences. During vector aggregation, the window starting index of the weights... This is the first event following the previous summary. The hash function can be a stable, low-collision-rate scheme (e.g., BLAKE2 / XXH3), combined with a domain salt to avoid cross-system collisions. By compressing cross-platform, multi-semantic event windows into short and verifiable state fingerprints, it facilitates rapid alignment between network transmission and the edge. Furthermore, the output... Archived together with window termination timestamps and vector clock boundaries, it provides verifiable anchors for end-side reconstruction and server-side auditing, and retains key business signals through weighted aggregation, reducing reliance on a large number of original events.

[0106] In step S440, a set of boundary conditions is constructed.

[0107] To balance verifiability and recoverability, select the business impact before the window is activated. K Historical events form a set of boundary conditions, which carry necessary state information (such as encoding vectors and timestamps). Here, boundary conditions refer to the conditions selected from historical domain events based on their business impact weights within the time interval that triggers summary generation. K The set of state content corresponding to each key event is used to define the boundary benchmark for the range of information retained in the session state summary at different granularity levels.

[0108] Equation (9)

[0109] In the formula, In the interval The internal selection of business influence rankings is relatively high. K A collection of events in various historical fields; The set of boundary conditions corresponding to the abstract represents the interval The set of state content corresponding to the selected historical events.

[0110] Based on equation (6) in the interval The TopK event is selected by weight, and each selected element is recorded. (A minimized structured load summary may be included if necessary), but the complete original event volume is not included, and the volume is controlled. It should be noted that... K The selection can be a fixed preset value, or it can be adaptively set based on average packet size quotas or edge capabilities to ensure stable and controllable abstracts. This allows for concise abstracts while providing sufficient interpretable context to anchor key information.

[0111] In step S450, based on the state hash value Generate a coarse-grained session state summary based on the state hash value. and boundary condition set The former m Item generates a medium-granularity session state digest based on the state hash value. and boundary condition set Generate a fine-grained session state summary.

[0112] It should be noted that, m The default value can be automatically calculated based on the target latency or packet quota at the endpoint. Furthermore, each layer's summary includes the last event number / vector clock boundary, facilitating subsequent sequential requests for incremental domain events at the endpoint. To ensure consistency between auditing and replayability, the summary generation will... The data is stored in the database along with window metadata, supporting post-event comparison and rollback. Thus, a three-layer digest structure is adopted, giving the system good scalability and evolution compatibility. The multi-layer digest allows weak network terminals to quickly align their states with smaller packets, while high-capacity terminals can obtain finer-grained information. Furthermore, it achieves controllable recovery latency and interpretable consistency under different network and computing power conditions.

[0113] In this embodiment, a time window is constructed using the target domain event trigger point as the anchor point. Historical domain events occurring within the window (which can be other types of domain events different from the target domain event) are uniformly aggregated and processed. A time-weighted state hash value is obtained based on a state encoding function. Simultaneously, a set of boundary conditions is constructed by selecting Top-K events from these historical events according to their business impact weights, thus forming a composite structural expression that combines "global evolution trend" and "key event boundary constraints." This avoids semantic bias caused by relying solely on the features of a single target event for summary generation. The summary reflects the overall evolution of the cross-platform session state within the specified time period and ensures the controllable retention of key business event information at different granularity levels. This improves the robustness and interpretability of summaries at different granularities in backend session recovery and cross-platform consistency reconstruction.

[0114] In this embodiment, a set of boundary conditions is used to construct a hierarchical summary. After the summary is generated, instead of simply retaining all historical events, the top-ranked events are selected from the trigger interval according to their business impact weight.K A set of boundary conditions is formed by key historical domain events, enabling the summary generation process to perform hierarchical pruning with the state hash as the root and this set as the difference boundary. This supports an adjustable summary hierarchy structure, where coarse-grained summarization retains only the root state, medium-grained summarization retains some key boundary content, and fine-grained summarization retains all boundary content. As a result, the summary size is significantly reduced without compromising semantic consistency, and the most suitable summary level can be dynamically selected based on the terminal network capacity. This allows cross-platform session state reconstruction to maintain the integrity of key semantics while significantly shortening reconstruction time and reducing the computational burden on the edge under weak network and complex concurrency conditions.

[0115] In some examples of embodiments of this application, the incremental domain event is an incremental domain event based on the incremental encoding compression processing of domain semantics. Figure 5 A flowchart illustrating an example of incremental coding compression processing based on domain semantics according to an embodiment of this application is shown.

[0116] like Figure 5 As shown, in step S510, events whose corresponding business impact weight exceeds the key weight threshold are retained.

[0117] Here, high-weight events typically lead to irreversible or significant changes in business status, such as payment confirmation, work order status changes, or permission upgrades. These events have inherent audit and recovery value. Therefore, during the incremental compression phase, events whose business impact weight exceeds a preset key weight threshold are prioritized for direct retention. This ensures that the reconstruction process can restore key decision states without relying on derivation or external compensation, thereby guaranteeing the certainty and seriousness of core business semantics in the cross-platform reconstruction path.

[0118] In step S520, duplicate events with the same business semantics and weights lower than the key weight threshold within a continuous time window are merged to generate corresponding merged events.

[0119] In real-world customer service or e-commerce interaction scenarios, there are numerous repetitive user actions (such as repeatedly adjusting quantities, continuously inputting short message fragments, and repeatedly expanding the same knowledge base node). Here, by identifying semantically consistent and low-weight repetitive events within a local time window and performing semantic merging on their payloads, the original discrete events of quantity can be compressed into a single entity representation. This avoids the cumulative resource waste caused by repetitive events on the transmission side and reduces the cost of multiple replays on the client side during the recovery phase.

[0120] In step S530, offset aggregation is performed on paired events with inverse operation relationships.

[0121] In some business interactions, there are clear inverse operation relationships, such as "subscribe ↔ unsubscribe", "increase in cart quantity ↔ decrease in cart quantity", and "like ↔ unlike". Specifically, when inverse semantic events appearing in pairs within the same session time series are detected, their semantic cancellation relationship is used to directly aggregate them, retaining only the event expression corresponding to their net effect. This avoids including intermediate events with no actual business contribution in the transmission sequence, thereby further compressing the event scale and reducing the overhead of state recovery processing.

[0122] In step S540, a new vector clock is assigned to the merged event, and each dimension of the new vector clock takes the maximum value of the corresponding original event vector clock.

[0123] Vector clocks are used to maintain partial order constraints across platforms. After completing the aforementioned semantic-level compression, to ensure that the original partial order relationship between events is not destroyed, the maximum vector clock value of the original event from which each dimension originates is selected as the new vector clock identifier in the merged event. This allows incremental events to still be correctly inserted into the original state timeline based on the partial order relationship when played back on the cross-platform end.

[0124] For example, a user adds the same product to their cart ("+1") on both mobile and desktop devices (Vector Clock). ) and "−1 discount" (vector clock) After semantic merging, the net effect "0 change" is obtained, and the new vector clock of the merged event takes the maximum value of each dimension. This approach can simultaneously reflect the latest known prior sequence relationship between mobile and desktop devices in terms of the order of events they occur, thus allowing for correct insertion of the timeline based on the partial order relationship during playback on the device side. Therefore, even with weak network conditions, out-of-order uploads, and multi-device concurrency, the incrementally compressed event sequence maintains semantic correctness and sequential consistency, significantly reducing transmission and replay burdens while ensuring the replayability of the session state and business consistency during recovery.

[0125] To verify the effectiveness of the method proposed in this application, a series of simulation experiments were designed and compared with traditional event tracing schemes. The experiments used a simulated data generator to generate cross-platform customer service conversation event streams, including various events such as user message sending, product operations, payment behavior, and knowledge base queries. Weights were assigned to the events according to a weight table. We set two baseline schemes:

[0126] • Baseline Solution A: Traditional event sourcing + fixed-interval snapshots. A complete snapshot is generated every 100 events, without distinguishing event weights or performing incremental compression.

[0127] • Baseline Scheme B: Event Provenance + General Compression. Merges mutually canceling events, but does not use weighted summarization or adaptive hierarchy.

[0128] We name the proposed scheme WDES-DSDE (Weighted Dynamic Event Summarization — Domain-Specific Delta Encoding, which combines dynamic event summarization based on business impact weights with domain semantic incremental encoding). It employs weighted summarization, multi-layer snapshots, adaptive thresholding, and intra-domain incremental encoding. Evaluation metrics include reconstruction time (ms), transmitted data size (KB), and consistency collision rate. Simulated network environments include high bandwidth (100 Mbps), medium bandwidth (10 Mbps), and weak network (1 Mbps).

[0129] Figure 6 This diagram illustrates an example of how reconstruction time varies with the number of events for different methods. The experiment, conducted under a fixed network bandwidth (10 Mbps), tested the impact of different event numbers on the reconstruction time of each scheme. We generated event streams of lengths 100, 500, 1000, 2000, and 4000, and measured the time from requesting reconstruction to completing state reconstruction on the client side.

[0130] from Figure 6 As can be seen, as the number of events to be reconstructed gradually increases from 100 to 4000, the reconstruction time of baseline scheme A (corresponding to the top line) shows an approximately linear upward trend, reaching nearly 1.8 seconds with 4000 events. Baseline scheme B (corresponding to the middle line) reduces the reconstruction time compared to baseline scheme A by merging and compressing some events, but still exhibits a linear growth characteristic with the event size. In contrast, the WDES-DSDE scheme proposed in this application (corresponding to the bottom line), under the same event size, shows a significantly smaller increase in reconstruction time compared to the two baseline schemes mentioned above. When the event size reaches 4000, the reconstruction time is approximately 0.6 seconds, only about one-third of that of baseline A. Therefore, by introducing a multi-level summarization and domain semantic incremental encoding strategy driven by business impact weights, the client's reconstruction computational burden can be effectively reduced, significantly improving the efficiency of cross-platform session state recovery.

[0131] Figure 7 A schematic diagram illustrating the effect of different methods on network throughput as the snapshot interval is shown. Specifically, in this experimental group, the snapshot interval was set to 20, 50, 100, 200, and 400 events, and the difference in data throughput between baseline scheme A and the WDES-DSDE scheme proposed in this application was compared.

[0132] like Figure 7As shown, baseline scheme A uses a full snapshot approach for state recovery. As the snapshot interval gradually increases, the network transmission volume increases significantly due to the linear accumulation of event information in each snapshot; when the interval expands to 400 events, the transmission volume approaches 800 units. In contrast, the WDES-DSDE scheme proposed in this application introduces a weight-driven adaptive snapshot strategy, combined with DSDE incremental coding and multi-level digest compression mechanisms, significantly slowing the increase in network transmission volume with increasing snapshot intervals. At the same 400-event snapshot interval, the network transmission volume of the WDES-DSDE scheme is approximately half that of the baseline scheme. Therefore, the WDES-DSDE scheme proposed in this application can reduce the network bandwidth overhead of state synchronization without significantly increasing the snapshot interval reconstruction error. It is particularly suitable for cross-platform application scenarios with limited mobile terminals, weak network links, or edge computing power, and can significantly improve the scalability of state synchronization and network resource utilization efficiency.

[0133] This paper proposes a session state reconstruction method based on event sourcing for cross-platform customer service integration scenarios. By deeply analyzing the shortcomings of existing technologies, such as high replay overhead, lack of event weight differentiation, and fixed snapshot strategies, we design a weighted event digest algorithm (WDES), an intra-domain incremental coding algorithm (DSDE), and an adaptive snapshot hierarchy strategy to reduce client-side reconstruction burden, decrease network transmission volume, and ensure data consistency. Experimental simulation results show that the proposed scheme outperforms traditional schemes in terms of reconstruction time, data transmission volume, and recovery performance in weak network environments, while automatically handling the vast majority of cross-platform conflicts.

[0134] Future research could further optimize the learning and adjustment mechanism of the weight function, introducing lightweight machine learning to dynamically adjust weights based on historical interactions. Meanwhile, how to integrate it with AI customer service systems to achieve event-driven intelligent recommendations and automatic responses is also a direction worth exploring.

[0135] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of combined actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Secondly, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application. In the above embodiments, the descriptions of each embodiment have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0136] Figure 8A structural block diagram of an example of an event sourcing-based cross-platform session state reconstruction system according to an embodiment of this application is shown.

[0137] like Figure 8 As shown, the cross-platform session state reconstruction system 800 based on event tracing includes an event generation unit 810, an event database maintenance unit 820, a session summary generation unit 830, and a session reconstruction unit 840.

[0138] The event generation unit 810 is used to acquire the original event stream generated by cross-platform user operations, and to perform unified formatting processing on the original event stream according to the event type, source platform, payload content and timestamp to generate domain events carrying predefined business impact weights.

[0139] The event library maintenance unit 820 is used to categorize and store the domain events into the event library according to the session identifier, and assign a vector clock to each event to maintain the cross-platform event order.

[0140] The session summary generation unit 830 is used to perform time-series cumulative calculation on the stored domain events, detect at least one target domain event in each of the domain events whose cumulative value of business impact weight exceeds the dynamic weight threshold, and generate a session state summary based on the event characteristics of each target domain event.

[0141] The session reconstruction unit 840 is used to respond to a client's session recovery request by sending the session state summary and incremental domain events after the generation time of the session state summary to the client, so that the client can restore the initial state based on the session state summary and replay the incremental domain events in vector clock order to reconstruct the session state.

[0142] In some embodiments, this application provides a non-volatile computer-readable storage medium storing one or more programs including execution instructions. The execution instructions can be read and executed by electronic devices (including but not limited to computers, servers, or network devices) to perform the steps of any of the above-described event sourcing-based cross-platform session state reconstruction methods of this application.

[0143] In some embodiments, this application also provides a computer program product, the computer program product including a computer program stored on a non-volatile computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the steps of any of the above-described cross-platform session state reconstruction methods based on event sourcing.

[0144] In some embodiments, this application also provides an electronic device comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform steps of an event sourcing-based cross-platform session state reconstruction method.

[0145] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0146] The electronic devices in this application can exist in various forms, including but not limited to: mobile communication devices, ultra-mobile personal computer devices, portable entertainment devices, or other airborne electronic devices with data interaction functions.

[0147] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0148] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable 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, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0149] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications 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.

Claims

1. A cross-platform session state reconstruction method based on event sourcing, characterized in that, The method includes: Obtain the raw event stream generated by cross-platform user operations, and perform unified formatting processing on the raw event stream according to event type, source platform, payload content and timestamp to generate domain events carrying predefined business impact weights; The domain events are categorized and stored in the event repository according to the session identifier, and a vector clock is assigned to each event to maintain the cross-platform event order; The system performs time-series cumulative calculations on the stored domain events, detects at least one target domain event in each domain event whose cumulative business impact weight exceeds the dynamic weight threshold, and generates a session state summary based on the event characteristics of each target domain event. In response to a client's session recovery request, the client is sent the session state summary and incremental domain events after the generation time of the session state summary, enabling the client to restore the initial state based on the session state summary and replay the incremental domain events in vector clock order to reconstruct the session state.

2. The method according to claim 1, characterized in that, The generated session state summary is a multi-level session state summary, which includes coarse-grained session state summary, medium-grained session state summary and fine-grained session state summary. The coarse-grained session state summary includes a state hash value determined based on the event characteristics of each of the target domain events; The medium-granularity session state summary includes the state hash value and the event characteristics of a preset number of target domain events with the highest weight ranking; The fine-grained session state summary includes the state hash value and the compressed event characteristics of each of the target domain events.

3. The method according to claim 2, wherein, The step of performing time-series cumulative calculations on the stored domain events, detecting at least one target domain event in each domain event whose cumulative business impact weight exceeds a dynamic weight threshold, and generating a session state summary based on the event characteristics of each target domain event includes: The business impact weights corresponding to events in each target domain are calculated using an exponential decay cumulative method to obtain the cumulative weight value: ， In the formula, This is the historical weight decay coefficient. For time Events that occurred in the target area The weight of business influence; To accumulate events in the target domain within the event sequence. The cumulative business impact weight at any given time; Summary generation is triggered when the cumulative weight value exceeds an adaptive threshold, which is determined by the following formula: ， In the formula, As the baseline threshold, For adjustment coefficients, For time Session complexity metrics This refers to network bandwidth performance metrics. For time Adaptive threshold; When digest generation is triggered, for each historical domain event between the previous digest generation time and the current time, the historical domain events are mapped to event state vectors based on a state encoding function, and the state hash value is calculated according to the following formula: ， In the formula, Indicates the first Events in a historical field, For historical events The timestamp of the occurrence The first domain event index after the previous summary is generated, so that the state hash value is used to form the summary root information of the session state summary; Indicates time The corresponding state hash value, For state encoding functions, For time Historical events that occurred The weight of business influence; Construct the set of boundary conditions: ， In the formula, In the interval The internal selection of business influence rankings is relatively high. K A collection of events in various historical fields; The set of boundary conditions corresponding to the abstract represents the interval The set of state content corresponding to the selected historical events. Based on the state hash value Generate a coarse-grained session state summary based on the state hash value. and The former Item generates a medium-granularity session state digest based on the state hash value. and Generate a fine-grained session state summary.

4. The method according to claim 2 or 3, wherein, The step of responding to a client's session recovery request by sending the session state summary and incremental domain events after the generation time of the session state summary to the client includes: Obtain the terminal communication performance index of the client, which is used to characterize the data transmission carrying capacity of the client; A target granularity level matching the terminal communication performance index is determined, and a session state summary corresponding to the target granularity level is sent to the client. The target granularity level is any one of the following: coarse-grained, medium-grained, or fine-grained.

5. The method according to claim 4, characterized in that, The determination of the target granularity level that matches the terminal communication performance index includes: The average packet size of each level is obtained, and the target granularity level that matches the terminal communication performance index is determined by selecting a level based on the target transmission efficiency constraint relationship between the average packet size and the terminal communication performance index. ， In the formula, Indicates the target granularity level. The target transmission delay ratio, For terminal communication performance indicators, Representing granularity levels L Average package size This represents a set of granularity levels.

6. The method according to claim 1, characterized in that, The incremental domain event is an incremental domain event based on domain semantics-based incremental coding compression processing; wherein, the incremental coding compression processing based on domain semantics includes: Retain events whose corresponding business impact weight exceeds the key weight threshold; By merging repeated events with the same business semantics within a continuous time window and whose weights are lower than the key weight threshold, a corresponding merged event is generated. Perform offset aggregation on paired events with inverse operation relationships; A new vector clock is assigned to the merged events, and each dimension of the new vector clock takes the maximum value of the corresponding original event vector clock.

7. The method according to claim 1, characterized in that, The process of acquiring the raw event stream generated by cross-platform user operations involves uniformly formatting the raw event stream according to event type, source platform, payload content, and timestamp to generate domain events carrying predefined business impact weights, including: Based on preset event semantic classification rules, various original events from cross-platform multi-type user interaction events in the original event stream are mapped to a unified set of event abstract types. Assign corresponding business impact weights to each event abstract type based on the business weight relationship table, thereby forming domain event instances carrying business impact weights; The source platform identifier, payload data representation, timestamp precision, and event sequence number of the event instances in the domain will be standardized and unified across platforms.

8. The method according to claim 7, characterized in that, The business weight relationship table pre-stores multiple calibrated domain events and their corresponding business impact weights, wherein the calibrated domain events include any one of the following: payment success event, product add-to-cart event, product details browsing event, message sending event, or work order change event.

9. A cross-platform session state reconstruction system based on event sourcing, characterized in that, The system includes: The event generation unit is used to acquire the original event stream generated by cross-platform user operations, and perform unified formatting processing on the original event stream according to the event type, source platform, payload content and timestamp to generate domain events carrying predefined business impact weights; The event library maintenance unit is used to classify and store the domain events into the event library according to the session identifier, and assign a vector clock to each event to maintain the cross-platform event order; The session summary generation unit is used to perform time-series cumulative calculation on the stored domain events, detect at least one target domain event in each of the domain events whose cumulative value of business impact weight exceeds the dynamic weight threshold, and generate a session state summary based on the event characteristics of each target domain event. The session reconstruction unit is configured to respond to a client's session recovery request by sending the session state summary and incremental domain events after the generation time of the session state summary to the client, so that the client can restore the initial state based on the session state summary and replay the incremental domain events in vector clock order to reconstruct the session state.

10. An electronic device, characterized in that, include: At least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

Images