Cross-park session preservation method, apparatus, device, storage medium and program product

Abstract

The application provides a cross-park session maintenance method, device, equipment, storage medium and program product, relating to the field of financial technology or other related fields. The method comprises: in response to generating session information after a user logs in, storing the session information and the login server identifier of the user to a local storage unit; synchronizing the session information to a distributed cache system; based on a received request, judging whether the local storage unit stores the session information; in the case that the local storage unit does not store the session information and the distributed cache system stores the session information, reconstructing a local session based on the session information obtained through the distributed cache system; in the case that the local storage unit does not store the session information and the distributed cache system does not store the session information, reconstructing the local session based on the login server identifier obtained through the persistent storage unit. The method is used to improve the stability of the system.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a method, apparatus, device, storage medium and program product for maintaining sessions across campuses. Background Technology

[0002] With the widespread adoption of mobile internet and the digital transformation of financial services, multiple zones, or data centers, are typically deployed in different geographical regions to meet the demands of high concurrency, high availability, and disaster recovery. Each zone contains multiple server nodes. Therefore, maintaining session connectivity across zones is crucial.

[0003] Currently, existing cross-campus session persistence methods mainly rely on session binding mechanisms based on data stored on the user's local terminal. Specifically, when a user logs in for the first time, the system records the Internet Protocol Address (IP) and port information of the server accessed by the user through the data identifier stored on the user's local terminal in the Hypertext Transfer Protocol (HTTP) request header, and the network device routes subsequent requests to the same server node.

[0004] However, existing cross-campus session persistence methods rely on sessions that bind data stored on the user's local terminal, the client's Internet Protocol Address (IP) address, or the routing rules of network devices. This results in low efficiency of cross-campus session synchronization and thus poor system stability. Summary of the Invention

[0005] This application provides a method, apparatus, device, storage medium, and program product for maintaining cross-campus sessions, in order to improve system stability.

[0006] Firstly, this application provides a method for maintaining a cross-campus session, including:

[0007] In response to the generation of session information after user login, the session information and the user's login server identifier are stored in a local storage unit; the session information includes at least the user's identity and dialogue context; the local storage unit is deployed on the temporary storage medium of the request processing node, and the local storage unit includes a persistent storage unit; the persistent storage unit is a storage system shared across nodes and is used to store the login server identifier for a long time.

[0008] The session information is synchronized to a distributed caching system; the distributed caching system contains multiple cache nodes, and the cache nodes support data access across network regions.

[0009] Based on the received request, determine whether the local storage unit stores the session information;

[0010] If the session information is not present in the local storage unit but exists in the distributed caching system, the local session is reconstructed based on the session information obtained through the distributed caching system.

[0011] If the session information is not present in the local storage unit and the distributed caching system, the local session is reconstructed based on the login server identifier obtained through the persistent storage unit.

[0012] In one possible implementation, synchronizing the session information to the distributed caching system includes:

[0013] The session information is encapsulated into a message and sent to a message queue; the message queue is used as middleware for asynchronous data transmission in a distributed system.

[0014] Based on the consumer process in the message queue, the message is asynchronously written to the distributed cache system; the asynchronous writing means that after the producer process sends the message, it does not immediately wait for the consumer process to process the result, and the consumer process processes the message asynchronously when resources are available.

[0015] In one possible implementation, the step of encapsulating the session information into a message and sending it to a message queue includes:

[0016] Based on a consistency protocol, the messages in the message queue are simultaneously written to the multiple cache nodes, which are deployed in different network regions. The consistency protocol refers to the algorithm or mechanism for data consistency in the distributed caching system.

[0017] In one possible implementation, synchronizing the session information to the distributed caching system includes:

[0018] Based on the user's historical behavior data, predict the target network areas that the user may visit;

[0019] The session information is preloaded into the cache node corresponding to the target network region in the distributed cache system.

[0020] In one possible implementation, preloading the session information into the cache node corresponding to the predicted target network region in the distributed caching system includes:

[0021] High-frequency users are identified based on user activity levels; these user activity levels are metrics used to measure user request frequency and session access patterns.

[0022] Based on the strategy of prioritizing preloading for high-frequency users, the session information is preloaded into the cache node corresponding to the target network area in the distributed caching system;

[0023] And / or,

[0024] Obtain the load data of the target network area;

[0025] Dynamically allocate preloaded resources based on the load data;

[0026] Based on the preloaded resources, the session information is preloaded into the cache node corresponding to the target network region in the distributed caching system.

[0027] In one possible implementation, after synchronizing the session information to the distributed caching system, the method further includes:

[0028] The session information of users with high activity levels is stored in a memory-based cache node; the memory-based cache node refers to the cache node in the distributed caching system that uses memory as the storage medium.

[0029] The session information of users with low activity is stored in a disk-based cache node, which indicates a cache node in the distributed cache system that uses a disk as the storage medium.

[0030] Secondly, this application provides a cross-campus session holding device, comprising:

[0031] A storage module is used to generate session information in response to user login, and store the session information and the user's login server identifier in a local storage unit; the session information includes at least the user's identity and dialogue context; the local storage unit is deployed on the temporary storage medium of the request processing node, and the local storage unit includes a persistent storage unit; the persistent storage unit is a storage system shared across nodes, used to store the login server identifier for a long time.

[0032] A synchronization module is used to synchronize the session information to a distributed caching system; the distributed caching system contains multiple cache nodes, and the cache nodes support data access across network regions;

[0033] The judgment module is used to determine whether the local storage unit stores the session information based on the received request;

[0034] The reconstruction module is configured to, when the session information is not present in the local storage unit but exists in the distributed caching system, reconstruct the local session based on the session information obtained through the distributed caching system; and to, when the session information is not present in the local storage unit and does not exist in the distributed caching system, reconstruct the local session based on the login server identifier obtained through the persistent storage unit.

[0035] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0036] The memory stores computer-executed instructions;

[0037] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects above.

[0038] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.

[0039] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0040] This application provides a method, apparatus, device, storage medium, and program product for cross-campus session persistence. It generates session information in response to user login and stores this session information, along with the user's login server identifier, in a local storage unit, providing data for subsequent cross-campus session persistence. Synchronizing this session information to a distributed caching system improves system availability and prevents session loss due to single points of failure. Based on a received request, it determines whether the local storage unit stores the session information. If the session information is not present in the local storage unit but exists in the distributed caching system, the local session is reconstructed based on the session information obtained from the distributed caching system, improving the system's dynamic scalability. If the session information is not present in both the local storage unit and the distributed caching system, the local session is reconstructed based on the login server identifier obtained from the persistent storage unit, improving the reliability and flexibility of session management and thus enhancing system stability. Attached Figure Description

[0041] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0042] Figure 1 A flowchart illustrating a cross-campus session persistence method provided in this application;

[0043] Figure 2 A flowchart illustrating a cross-campus session persistence method based on distributed caching provided in this application;

[0044] Figure 3 A schematic diagram of a cross-campus conversation holding device provided in this application;

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

[0046] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0047] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0048] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0049] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0050] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0051] First, let's explain some of the terms used in this application:

[0052] Distributed cache: refers to a storage system shared across nodes (such as a Redis cluster), which supports high-concurrency read and write operations and cross-site access.

[0053] With the widespread adoption of mobile internet and the digital transformation of financial services, multiple zones, or data centers, are typically deployed in different geographical regions to meet the demands of high concurrency, high availability, and disaster recovery. Each zone contains multiple server nodes. Therefore, maintaining session connectivity across zones is crucial.

[0054] Currently, existing cross-campus session persistence methods mainly rely on session binding mechanisms based on data stored on the user's local terminal. Specifically, when a user logs in for the first time, the system records the Internet Protocol Address (IP) and port information of the server accessed by the user through the data identifier stored on the user's local terminal in the Hypertext Transfer Protocol (HTTP) request header, and the network device routes subsequent requests to the same server node.

[0055] However, existing cross-campus session persistence methods rely on sessions that bind data stored on the user's local terminal, the client's Internet Protocol Address (IP) address, or the routing rules of network devices. This results in low efficiency of cross-campus session synchronization and thus poor system stability.

[0056] Considering the aforementioned problems with existing cross-campus session persistence methods, this application proposes a method for cross-campus session persistence that uses distributed caching to centrally store and dynamically synchronize session information across campuses and nodes. This method improves system stability.

[0057] The entity executing this cross-campus session persistence method can be, for example, a session persistence system. Optionally, the session persistence system can be any existing electronic device with processing capabilities, such as a terminal or a server. In some embodiments, the session persistence system can also be deployed in a server cluster or cloud environment. This application does not limit the deployment environment of the session persistence system.

[0058] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments.

[0059] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0060] Figure 1 This is a flowchart illustrating a cross-campus session persistence method provided in this application. Figure 1 As shown, the method includes:

[0061] S101, in response to the generation of session information after user login, the session information and the user's login server identifier are stored in the local storage unit. The session information includes at least the user's identity and dialogue context. The local storage unit is deployed on the temporary storage medium of the request processing node. The local storage unit contains a persistent storage unit, which is a storage system shared across nodes and is used to store the login server identifier for a long time.

[0062] For example, session information can be data about a user's access to services. This could include user identity, account, login time, currently accessed modules, and operation history.

[0063] For example, a request processing node can be a node responsible for receiving and processing user login requests and business operation requests. For instance, a request processing node could be an application server node or a gateway processing node.

[0064] Optionally, the session persistence system can detect that after Tonghu's login request is verified, generate structured session information including user identity, dialogue context, etc., in a preset format, and associate it with the user's login server identifier.

[0065] Optionally, the session persistence system can store the aforementioned session information in a local storage unit, and simultaneously write the user's login server identifier into the persistent storage unit via an interface.

[0066] Optionally, the session persistence system can store session information in the memory of the request processing node and the login server identifier in a distributed shared database. Alternatively, the session persistence system can store session information in the local disk cache of the request processing node, with the persistent storage unit using a distributed file system to store the login server identifier. Another option is to use an embedded cache built into the request processing node to store the session information, with the persistent storage unit using a distributed cache cluster to store the login server identifier.

[0067] S102, synchronize the session information to the distributed caching system, which contains multiple cache nodes and supports data access across network regions.

[0068] In some embodiments, the session persistence system encapsulates the session information into a message and sends it to a message queue. Then, based on the consumer process in the message queue, the message is asynchronously written to the distributed caching system. The message queue serves as middleware for asynchronously transmitting data within the distributed system. This asynchronous writing means that after the producer process sends the message, it does not immediately wait for the consumer process to process the result; the consumer process processes the message asynchronously when resources become available.

[0069] For example, a message can be a structured data unit formed by encapsulating session information in a preset format.

[0070] For example, the producer process can be an execution process responsible for sending the encapsulated session information messages to the message queue.

[0071] For example, a consumer process can be an execution process deployed on a message queue associated node, responsible for retrieving session information messages from the message queue and performing asynchronous write operations to the distributed cache system.

[0072] Optionally, the session persistence system can encapsulate the session information using a lightweight data exchange format (JavaScript Object Notation, JSON). This involves converting session information such as session identifier, user identity, and timeout into a JSON string according to a preset field format, and then encapsulating it into a message. The message header carries a message type identifier.

[0073] Optionally, the session persistence system can also encapsulate the session information using Protocol Buffers (PB) serialization. By defining a PB data structure for the session information, the original session information is serialized to generate a binary message. The PB data structure can, for example, contain the data types and length constraints of the various fields of the session information.

[0074] Optionally, the session persistence system can send encapsulated messages to a designated queue in the message queue via the producer process, ensuring that each message is processed by only one consumer process. The session persistence system can also enable a message queue acknowledgment mechanism when sending messages. After successfully receiving and storing the message, the message queue returns a reception acknowledgment signal to the producer process; if sending fails, the producer process triggers a retry mechanism. For example, if three retries fail, an abnormal situation alarm can be sent to the session persistence system.

[0075] Optionally, the session persistence system can use a consumer process to periodically send retrieval requests to the message queue at a fixed polling interval. If a message is detected in the message queue, it will be retrieved and processed. The session persistence system can also proactively send a notification signal to the consumer process when it detects that a message has been written to the message queue.

[0076] Optionally, the consumer process obtains a session identifier by parsing the message, and determines whether a record corresponding to that session identifier exists in the distributed cache. If a record already exists, it overwrites the existing data; otherwise, it adds a new record. The consumer process can also write changed fields from the session information to the cache, while retaining unchanged fields. After the consumer process writes data, the session persistence system can send a verification request to the distributed cache node. The node returns the data storage status; if the verification fails, the data is re-cached and written.

[0077] As one possible implementation, the session information is encapsulated into a message and sent to a message queue. Then, based on a consistency protocol, the message in the message queue is simultaneously written to multiple cache nodes. These multiple cache nodes are deployed in different network regions. The consistency protocol refers to the algorithm or mechanism for data consistency in the distributed caching system.

[0078] For example, multiple cache nodes can be virtual nodes in this distributed caching system that independently undertake data storage and retrieval tasks. For instance, each cache node can have independent memory modules and respond to data requests independently.

[0079] For example, different network areas can be physically or logically isolated network areas, such as different data centers or geographical campuses.

[0080] Optionally, the session persistence system can write according to network area priority, prioritizing the cache nodes in the user's currently accessed area, and then synchronizing to other area nodes through a consistency protocol, marking the node's area identifier during writing. For example, the session persistence system can retrieve messages from the message queue through any cache node, synchronize data to multiple cache nodes associated with that cache node based on the consistency protocol, and the receiving cache node continues to propagate to other cache nodes until all cache nodes have completed writing the data.

[0081] Optionally, the session persistence system can also allocate session information to corresponding cache nodes based on the hash value of the session information identifier. At least one master node and slave nodes are deployed in each network region, and data synchronization within the shard is completed based on a consistency protocol. For example, the session persistence system can retrieve and parse messages from a message queue through the master node and initiate data write requests to all slave nodes. By encapsulating the session information into a message and sending it to the message queue, and then simultaneously writing the message from the message queue to multiple cache nodes based on a consistency protocol, the system's disaster recovery capability can be improved, thereby enhancing system stability.

[0082] By encapsulating the session information into a message and sending it to a message queue, the foundation for subsequent writing to the distributed caching system is laid. Based on the consumer process in this message queue, the message is asynchronously written to the distributed caching system, thus decoupling business requests from cache synchronization and reducing the risk of system blocking.

[0083] S103, based on the received request, determine whether the local storage unit stores the session information.

[0084] For example, a request can be instruction data for obtaining or manipulating session information. For instance, a request may include, for example, a request type, a timestamp, and a session identifier.

[0085] Optionally, the session persistence system can perform a hash calculation on the session identifier using a preset hash algorithm to obtain a fixed-length hash value, and store the session information in a local storage unit according to the hash value and session information format. Based on the received request, the session identifier is extracted, and the storage address of the session information in the local storage unit is located using the calculated hash value. If data exists at that storage address, it is determined that the local storage unit stores the session information; otherwise, it is determined that the local storage unit does not store the session information.

[0086] Optionally, the session persistence system can also use a preset session information index table, which contains the session identifier of the session information and the corresponding data storage offset. Upon receiving a request, the session persistence system extracts the session identifier and uses a binary search algorithm to retrieve the session identifier from the session information index table. If a matching index entry is found, the session persistence system locates the session information based on the data storage offset and determines whether the session information exists in the local storage unit; if no matching entry is found in the session information index table, it determines that the session information is not stored in the local storage unit.

[0087] S104, if the session information does not exist in the local storage unit but exists in the distributed caching system, the local session is reconstructed based on the session information obtained through the distributed caching system. If the session information does not exist in both the local storage unit and the distributed caching system, the local session is reconstructed based on the login server identifier obtained through the persistent storage unit.

[0088] Optionally, upon receiving a user request, the session persistence system can query the session information in the local storage unit via the local cache read interface. If a null value or invalid identifier is returned, it is determined that the session information does not exist in that local storage unit. Based on the session identifier carried in the user request, the corresponding session information is retrieved from the distributed cache system by calling the query interface of the cache cluster.

[0089] Optionally, the session persistence system can use a serialization tool to generate a local session object from the complete session information obtained from the distributed cache, store it in a designated cache area of ​​the local storage unit, and reconstruct the local session. The session persistence system can also synchronize core session fields and lazy-load non-core fields as needed to reconstruct the local session. For example, core fields could be user ID, permission level, and validity period, while non-core fields could be historical operation records.

[0090] Optionally, upon receiving a user request, the session persistence system can query the session information in the local storage unit through the local cache read interface. If a null value or invalid identifier is returned, it is determined that the session information does not exist in the local storage unit. Based on the session identifier carried in the user request, the system can call the query interface of the cache cluster to query the distributed cache system. If the query interface returns a null value or invalid identifier, it is determined that the session information does not exist in the distributed cache system.

[0091] Optionally, the session persistence system can obtain the login server identifier corresponding to the user by calling a query statement in a relational database based on the user's representation. Then, based on the login server identifier, it can call the session data interface of the login server to obtain the user's session information, construct a new local session object, and store it in the local storage unit.

[0092] In this embodiment, session information is generated in response to user login, and this session information, along with the user's login server identifier, is stored in a local storage unit, providing data for subsequent cross-campus session persistence. Synchronizing this session information to a distributed caching system improves system availability and prevents session loss due to single points of failure. Based on the received request, it is determined whether the local storage unit stores the session information. If the session information is not present in the local storage unit but exists in the distributed caching system, the local session is reconstructed based on the session information obtained from the distributed caching system, improving the system's dynamic scalability. If the session information is not present in both the local storage unit and the distributed caching system, the local session is reconstructed based on the login server identifier obtained from the persistent storage unit, improving the reliability and flexibility of session management, thereby enhancing system stability.

[0093] The following section provides a detailed explanation of how the session persistence system synchronizes the session information to the distributed caching system.

[0094] In some embodiments, the session persistence system can predict the target network area that a user may visit based on the user's historical behavior data. Then, the session information is preloaded into the cache node corresponding to the target network area in the distributed caching system.

[0095] For example, user historical behavior data can be a collection of data that records a user's past login times, network switching patterns, and other behavioral characteristics.

[0096] For example, preloading can be done by writing data to the target storage location in advance before the user actually accesses the site. For instance, if it is predicted that a user will switch to Campus A, their session information can be written to the cache node of Campus A in advance.

[0097] Optionally, the session persistence system can acquire users' historical behavior data through a data acquisition interface, clean this historical behavior data, and standardize the time and network address formats to obtain standardized historical behavior data. The session persistence system can also collect users' historical behavior data through application log tracking.

[0098] Optionally, the session persistence system can construct prompt words based on the aforementioned historical behavior data, and input these prompt words into a prediction model to output a prediction of the target network regions the user might visit. The prompt words indicate the target network regions the user might visit based on the historical behavior data. For example, the prediction model can be any pre-trained deep learning model or machine learning model with prediction capabilities.

[0099] Optionally, the session persistence system can locate the cache node for the target network area based on a consistent hashing algorithm, serialize the session information using commands and write it to the node, and set a preload validity period. Alternatively, the session persistence system can first load the session information into the primary cache node of the target network area, and then have the primary node asynchronously synchronize it to the secondary nodes of the target network area.

[0100] By employing the above method, based on the user's historical behavior data, the target network area the user may visit can be predicted, reducing session information acquisition time and operation latency. Preloading this session information into the cache node corresponding to the target network area in the distributed caching system enhances system scalability and improves system stability.

[0101] As one possible implementation, the session persistence system can identify high-frequency users based on their activity levels. Then, based on a strategy of prioritizing preloading for these high-frequency users, the session information is preloaded into the corresponding cache node in the distributed caching system for the target network region. This user activity level serves as a metric for measuring user request frequency and session access patterns.

[0102] For example, a high-frequency user can be a user with a high request frequency and a stable session access pattern.

[0103] Optionally, the session persistence system can assign users to groups based on their request frequency and session access patterns, and calculate a comprehensive score using a weighted algorithm. If the comprehensive score is higher than a preset high-frequency threshold, the user is considered a high-frequency user. For example, the session persistence system could assign a weight of 0.6 to user request frequency and a weight of 0.4 to session access stability, defining users with a comprehensive score greater than 85 as high-frequency users. The session persistence system can also calculate session access stability based on the fluctuation range of access over a continuous 7-day period.

[0104] Optionally, the session persistence system can set up a high-frequency preloading queue for the aforementioned high-frequency users. This high-frequency preloading queue has a higher priority than the regular user queue, meaning that tasks in this high-frequency preloading queue are processed first. Furthermore, a certain proportion of cache node bandwidth can be reserved for high-frequency users, allowing them to preload session information using this cache node bandwidth.

[0105] Optionally, the session persistence system can preload the session information of the high-frequency user in blocks. By prioritizing the loading of core fields and asynchronously completing non-core fields, the session information can be preloaded into the cache node corresponding to the target network area in the distributed caching system.

[0106] By using the above method, high-frequency users are identified based on user activity. Based on the strategy of prioritizing preloading for these high-frequency users, the session information is preloaded into the cache node corresponding to the target network area in the distributed caching system, thereby improving the user's interactive experience and thus improving the system's operating efficiency.

[0107] As another possible implementation, the session persistence system can also acquire load data for the target network area. Then, it dynamically allocates preloaded resources based on this load data. Finally, based on these preloaded resources, it preloads the session information into the cache node corresponding to the target network area in the distributed caching system.

[0108] For example, load data can be a set of quantified data on the running status of cache nodes corresponding to the target network area. For instance, load data may include microcontroller utilization, memory usage, network bandwidth usage, number of concurrent requests, and session storage.

[0109] For example, the preloaded resources may be system resources used to support operations that preload session information.

[0110] Optionally, the session persistence system can call the status query interface of the cache node to obtain the load data of the target network area via the HTTP protocol.

[0111] Optionally, the session persistence system can preset load tier threshold ranges based on the aforementioned load data, and allocate different preloaded resources based on different threshold ranges. For example, when the load data is less than or equal to 50%, 80% of the preloaded resources are allocated; when the load data is greater than 50% but less than 80%, 50% of the preloaded resources are allocated; when the load data is greater than or equal to 80%, unnecessary preloading is paused, and only core session preloading is retained. The session persistence system can also adjust the preloaded resource quota in real time based on the load data using an elastic resource scheduling algorithm. For example, when the node load suddenly increases, some preloaded tasks are automatically migrated to low-load standby nodes in the same region.

[0112] Optionally, the session persistence system can preload all session information to the cache nodes when resources are sufficient, and preload only the key index information of the session information when resources are scarce, and lazily load the complete data of the session information as needed. The session persistence system can also adjust the preloading timing based on load data, performing batch preloading of the session information during low-load periods and performing real-time preloading of necessary session information during high-load periods.

[0113] The above method obtains the load data of the target network area, laying the foundation for subsequent allocation of preloaded resources. Based on this load data, preloaded resources are dynamically allocated. Using these preloaded resources, the session information is preloaded into the corresponding cache node of the target network area in the distributed caching system, avoiding resource idleness and improving system stability and fault tolerance.

[0114] As another possible implementation, the session persistence system can also identify high-frequency users based on user activity and obtain load data for the target network area. Then, based on the load data, preloaded resources are dynamically allocated, and based on a strategy that prioritizes preloading for high-frequency users, the session information is preloaded into the cache node corresponding to the target network area in the distributed caching system.

[0115] Optionally, the session persistence system can pre-establish a user priority-load threshold mapping table. Based on the load data of the target network area, it can determine the preloaded resources corresponding to high-frequency users by querying this mapping table. For example, if the user is a high-frequency user and the load of the target network area is high, 10% of the basic preloaded resources are reserved for the high-frequency user; if the user is a high-frequency user and the load of the target network area is low, 50% of the basic preloaded resources are reserved for the high-frequency user. The session persistence system can also use a load prediction algorithm, combined with historical load data, to predict the load change trend of the target area in the next hour and reserve preloaded resources for high-frequency users.

[0116] Optionally, the session persistence system can also preset a node load threshold. When the load data is lower than the preset node load threshold, the system prioritizes the full preloading of sessions for all high-frequency users before processing the preloading for ordinary users. When the load data is higher than the preset node load threshold, the system preloads core session information fields for high-frequency users and suspends the preloading of session information for ordinary users.

[0117] Using the methods described above, high-frequency users can be identified based on user activity levels, and load data for the target network area can be obtained, providing a data basis for subsequent preloading of session information. Based on this load data, preloading resources can be dynamically allocated, and a strategy prioritizing preloading for high-frequency users can be implemented. This allows the session information to be preloaded into the corresponding cache node in the distributed caching system for the target network area, avoiding resource waste and improving user experience and system stability.

[0118] In some embodiments, after synchronizing the session information to the distributed caching system, the session persistence system can store the session information of users with high activity levels in a memory-based cache node. Then, it stores the session information of users with low activity levels in a disk-based cache node. Here, a memory-based cache node refers to a cache node in the distributed caching system that uses memory as its storage medium, and a disk-based cache node refers to a cache node in the distributed caching system that uses disk as its storage medium.

[0119] For example, the storage medium could be the physical storage medium in a cache node used to carry session information.

[0120] Optionally, the session persistence system can extract feature information of the user session based on a preset time window. For example, this feature information may include access frequency, cumulative duration, and read / write request volume. It should be understood that this application does not limit the duration of the preset time window, nor its start and end times. For example, the end time of the preset time window can be the current time, and the start time can be any time before the current time. Alternatively, both the start and end times of the preset time window can be any time before the current time.

[0121] Optionally, the session persistence system can assign weights to different features based on the aforementioned feature information, and, based on a weighted scoring algorithm and a preset activity threshold, divide the session information into two levels: high activity and low activity. The weights assigned to different features in this feature information can, for example, be pre-stored in the session persistence system. It should be understood that this application does not limit the relative magnitudes of the weights corresponding to different features in this feature information.

[0122] For example, the session persistence system can assign weights to different features in the feature information, such as access frequency weighting 0.4, online duration weighting 0.3, and read / write request volume weighting 0.3, calculate the total activity score of the session information, and set the session information with the total activity score greater than 80 as high activity, and the session information with the total activity score less than or equal to 80 as low activity.

[0123] Optionally, the session persistence system can also preset thresholds for different features in the feature information. When any feature in the feature information exceeds the corresponding preset threshold, the session information corresponding to that feature information is determined to be a high-activity session. For example, the preset threshold for access frequency within 1 hour is 50 times, and the preset session online duration is 30 minutes. When the access frequency within 1 hour in the feature information of the session information is greater than 50 times, the session information is determined to be a high-activity session. When the session online duration within 1 hour in the feature information of the session information is less than 30 minutes, the session information is determined to be a low-activity session.

[0124] Optionally, the session persistence system can store high-activity session information in memory-based cache nodes based on instruction information, or it can use a distributed file system to build disk-based cache nodes to store low-activity session information.

[0125] By using the above method, after synchronizing the session information to the distributed caching system, session information for users with high activity levels is stored in memory-based cache nodes, while session information for users with low activity levels is stored in disk-based cache nodes. This improves the utilization of cache resources and reduces storage costs. Specifically, a memory-based cache node refers to a cache node in the distributed caching system that uses memory as its storage medium, and a disk-based cache node refers to a cache node in the distributed caching system that uses disk as its storage medium.

[0126] Figure 2 This is a flowchart illustrating a cross-campus session persistence method based on distributed caching provided in this application. Figure 2 As shown, the method includes:

[0127] (1) When a customer successfully logs into the application, the system creates a session and registers it in the login log table, recording the login server IP and port.

[0128] (2) The system will synchronize and maintain the session information in the distributed cache.

[0129] (3) When a client makes a subsequent request to the server, a session check is performed first. If the session information does not exist locally, the distributed cache is accessed. If the session information exists in the distributed cache, the session is retrieved locally and the session information is reconstructed.

[0130] (4) If the distributed cache does not have session information, access the database login log table to obtain the Internet Protocol address (IP) and port of the login server, then send a request to the login server to obtain session information to rebuild the session locally and synchronize it to the distributed cache.

[0131] (5) After processing, synchronize the local session information to the distributed cache for updating.

[0132] Optionally, the session persistence system may include campus A, campus B, a distributed caching system for campus A, a database, and a distributed caching system for campus B.

[0133] Optionally, within Campus A, a customer login operation is performed. After login, a session is created. This operation synchronizes session data to Campus A's distributed caching system, and the login log table in the database records relevant information. Subsequently, an execution request operation is performed, and after the request is processed, the session is updated.

[0134] Optionally, if a customer subsequently requests to access Campus B from another campus, the system receiving the request will first perform a session retrieval operation from the distributed cache (retrieving session data from the distributed cache system in Campus A). If retrieval fails, the system will then retrieve the session from the login server. After successful session retrieval, the session will be rebuilt. Simultaneously, the distributed cache system in Campus B will store the corresponding session data.

[0135] The above are the method embodiments provided in this application. The apparatus provided in this application will be described below.

[0136] Figure 3 A schematic diagram of a cross-campus session holding device provided in this application is shown below. Figure 3 As shown, the cross-campus session persistence device 300 provided in this embodiment includes: a storage module 301, a synchronization module 302, a judgment module 303, and a reconstruction module 304. Among them,

[0137] Storage module 301 is used to generate session information in response to user login, and store the session information and the user's login server identifier in a local storage unit; the session information includes at least the user's identity and dialogue context; the local storage unit is deployed on the temporary storage medium of the request processing node, and the local storage unit contains a persistent storage unit; the persistent storage unit is a storage system shared across nodes, used to store the login server identifier for a long time.

[0138] Synchronization module 302 is used to synchronize the session information to a distributed caching system; the distributed caching system contains multiple cache nodes, which support data access across network regions.

[0139] The judgment module 303 is used to determine whether the local storage unit stores the session information based on the received request:

[0140] The reconstruction module 304 is used to reconstruct the local session based on the session information obtained through the distributed caching system when the session information does not exist in the local storage unit but exists in the distributed caching system; and to reconstruct the local session based on the login server identifier obtained through the persistent storage unit when the session information does not exist in the local storage unit and the distributed caching system.

[0141] Optionally, the synchronization module 302 is also used to encapsulate the session information into a message and send it to a message queue; the message queue is used as middleware for asynchronously transmitting data in a distributed system.

[0142] Based on the consumer process in the message queue, the message is asynchronously written to the distributed caching system; the asynchronous writing means that after the producer process sends the message, it does not immediately wait for the consumer process to process the result, and the consumer process processes the message asynchronously when resources are available.

[0143] Optionally, the synchronization module 302 is also used to encapsulate the session information into a message and send it to the message queue, and then, based on a consistency protocol, simultaneously write the message in the message queue to the multiple cache nodes, which are deployed in different network areas. The consistency protocol refers to the algorithm or mechanism for data consistency in the distributed cache system.

[0144] Optionally, the synchronization module 302 is also used to predict the target network area that the user may visit based on the user's historical behavior data;

[0145] The session information is preloaded into the cache node corresponding to the target network region in the distributed caching system.

[0146] Optionally, the synchronization module 302 is also used to determine high-frequency users based on user activity; the user activity is used as an indicator to measure the frequency of user requests and session access patterns; based on the strategy of prioritizing preloading for the high-frequency user, the session information is preloaded into the cache node corresponding to the target network area in the distributed cache system;

[0147] And / or, obtain the load data of the target network area; dynamically allocate preloaded resources based on the load data; and preload the session information into the cache node corresponding to the target network area in the distributed caching system based on the preloaded resources.

[0148] Optionally, the synchronization module 302 is further configured to, after synchronizing the session information to the distributed caching system, store the session information of the user with high activity in a memory-type cache node; the memory-type cache node refers to the cache node in the distributed caching system that uses memory as the storage medium;

[0149] The session information of the user with low activity is stored in a disk-based cache node, which indicates the cache node in the distributed caching system that uses a disk as the storage medium.

[0150] This embodiment provides a cross-campus session retention device that can execute the methods provided in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0151] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 4As shown, the electronic device 400 provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the device 400 further includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0152] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.

[0153] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0154] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0155] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0156] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0157] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0158] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0159] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of 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. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0160] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0161] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0162] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or in the form of software program modules.

[0163] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0164] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0165] 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. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0166] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0167] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for maintaining sessions across campuses, characterized in that, include: In response to the generation of session information after a user logs in, the session information and the user's login server identifier are stored in the local storage unit; The session information includes at least the user identity and the dialogue context; the local storage unit is deployed on the temporary storage medium of the request processing node, and the local storage unit contains a persistent storage unit; the persistent storage unit is a storage system shared across nodes and is used to store the login server identifier for a long time. The session information is synchronized to a distributed caching system; the distributed caching system contains multiple cache nodes, and the cache nodes support data access across network regions. Based on the received request, determine whether the local storage unit stores the session information; If the session information is not present in the local storage unit but exists in the distributed caching system, the local session is reconstructed based on the session information obtained through the distributed caching system. If the session information is not present in the local storage unit and the distributed caching system, the local session is reconstructed based on the login server identifier obtained through the persistent storage unit.

2. The method according to claim 1, characterized in that, The step of synchronizing the session information to the distributed caching system includes: The session information is encapsulated into a message and sent to a message queue; the message queue is used as middleware for asynchronous data transmission in a distributed system. Based on the consumer process in the message queue, the message is asynchronously written to the distributed cache system; the asynchronous writing means that after the producer process sends the message, it does not immediately wait for the consumer process to process the result, and the consumer process processes the message asynchronously when resources are available.

3. The method according to claim 2, characterized in that, The step of encapsulating the session information into a message and sending it to the message queue includes: Based on a consistency protocol, the messages in the message queue are simultaneously written to the multiple cache nodes, which are deployed in different network regions. The consistency protocol refers to the algorithm or mechanism for data consistency in the distributed caching system.

4. The method according to claim 1, characterized in that, The step of synchronizing the session information to the distributed caching system includes: Based on the user's historical behavior data, predict the target network areas that the user may visit; The session information is preloaded into the cache node corresponding to the target network region in the distributed cache system.

5. The method according to claim 4, characterized in that, The step of preloading the session information into the cache node corresponding to the predicted target network region in the distributed caching system includes: High-frequency users are identified based on user activity levels; these user activity levels are metrics used to measure user request frequency and session access patterns. Based on the strategy of prioritizing preloading for high-frequency users, the session information is preloaded into the cache node corresponding to the target network area in the distributed caching system; And / or, Obtain the load data of the target network area; Dynamically allocate preloaded resources based on the load data; Based on the preloaded resources, the session information is preloaded into the cache node corresponding to the target network region in the distributed caching system.

6. The method according to any one of claims 1-5, characterized in that, After synchronizing the session information to the distributed caching system, the process further includes: The session information of users with high activity levels is stored in a memory-based cache node; the memory-based cache node refers to the cache node in the distributed caching system that uses memory as the storage medium; The session information of users with low activity is stored in a disk-based cache node, which indicates a cache node in the distributed caching system that uses a disk as the storage medium.

7. A cross-campus session holding device, characterized in that, include: The storage module is used to store the session information and the user's login server identifier in a local storage unit in response to the generation of session information after the user logs in; The session information includes at least the user identity and the dialogue context; the local storage unit is deployed on the temporary storage medium of the request processing node, and the local storage unit contains a persistent storage unit; the persistent storage unit is a storage system shared across nodes and is used to store the login server identifier for a long time. A synchronization module is used to synchronize the session information to a distributed caching system; the distributed caching system contains multiple cache nodes, and the cache nodes support data access across network regions; The judgment module is used to determine whether the local storage unit stores the session information based on the received request; The reconstruction module is configured to, when the session information is not present in the local storage unit but exists in the distributed caching system, reconstruct the local session based on the session information obtained through the distributed caching system; and to, when the session information is not present in the local storage unit and does not exist in the distributed caching system, reconstruct the local session based on the login server identifier obtained through the persistent storage unit.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

Images