Collaborative session management method and system, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a collaborative session management method and system, electronic equipment and a storage medium. According to the technical scheme provided by the embodiment of the invention, the collaborative operation request of the target collaborative object is received, and the collaborative operation request comprises the session information of the target collaborative session to which the target collaborative object belongs; determining a kernel process cluster bound with the target collaborative session based on the session information, wherein the kernel process cluster comprises at least one kernel writing process and / or at least one kernel reading process; and determining a target kernel process from the kernel process cluster, and sending the collaborative operation request to the target kernel process for processing. By adopting the technical means, the read-write operation for the same collaborative object can be distributed to different kernel processes for parallel processing, so that process-level read-write separation and load balancing are realized, and the support capability and resource utilization efficiency of the system to a high-concurrency read-write scene are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a collaborative session management method, system, electronic device, and storage medium. Background Technology

[0002] Currently, in system architectures for multi-user collaborative sessions (such as online multi-user collaboration around a specific collaborative object), a common approach is to create an independent kernel process for each collaborative object (digital object, such as online documents, images, games, etc.) to manage collaborative sessions, achieving secure isolation and ensuring the stability of collaborative computing. Furthermore, to guarantee data consistency, this kernel process needs to handle all read and write operations simultaneously and serialize these operations. When multiple users perform read and write operations on the same collaborative object, a task queue is used, with the kernel process handling each operation sequentially.

[0003] However, the architecture of using a single-process serial processing method for collaborative session read and write operations has a significant upper limit on the performance of a single collaborative object, making it unable to support higher concurrency read and write scenarios and limiting the number of collaborative operators. Furthermore, system resources are statically allocated on a per-collaborative-object and per-process basis, with each collaborative object creating a separate kernel process, leading to uneven server resource utilization and increased operational costs. Summary of the Invention

[0004] This application provides a collaborative session management method, system, electronic device, and storage medium, which can distribute read and write operations for the same collaborative object to different kernel processes for parallel processing, realize process-level read and write separation and load balancing, and solve the technical problems of low performance limit and insufficient concurrency support capability of collaborative operations caused by single-process serial processing in the prior art.

[0005] In a first aspect, embodiments of this application provide a collaborative session management method, including: Receive a collaborative operation request from the target collaborative object. The collaborative operation request contains session information of the target collaborative session to which the target collaborative object belongs. The kernel process cluster bound to the target collaborative session is determined based on the session information. The kernel process cluster includes at least one write kernel process and / or at least one read kernel process. Identify the target kernel process from the kernel process cluster and send the cooperative operation request to the target kernel process for processing.

[0006] Furthermore, the target kernel process is identified from the kernel process cluster, including: Identify the operation type of the collaborative operation request; When the operation type is write, if a write kernel process exists in the kernel process cluster corresponding to the target collaborative session, one write kernel process is selected from at least one write kernel process in the kernel process cluster as the target kernel process; if no write kernel process exists in the kernel process cluster corresponding to the target collaborative session, a write kernel process is created in the kernel process cluster as the target kernel process; or, When the operation type is a read operation, if there is a read kernel process in the kernel process cluster that corresponds to the target collaborative session, a read kernel process is selected from at least one read kernel process in the kernel process cluster as the target kernel process. If there is no read kernel process in the kernel process cluster that corresponds to the target collaborative session, a read kernel process is created in the kernel process cluster as the target kernel process.

[0007] Furthermore, in the case where the kernel process cluster includes multiple write kernel processes, including master nodes and child nodes, the target kernel process is determined from the kernel process cluster, including: Identify the operation type of the collaborative operation request; When the operation type is write operation, the master node or child node in the kernel process cluster is selected as the target kernel process. The master node is used to synchronize the write operation data of the target collaborative session based on the synchronization information of each child node, and synchronize the synchronization information to the child nodes.

[0008] Furthermore, the target kernel process is identified from the kernel process cluster, including: Identify the operation permissions required for collaborative operation requests; If a collaborative operation request has write permissions, but the number of users handled by the write processes in the kernel process cluster has not reached the set limit, the corresponding write process is selected from the kernel process cluster as the target kernel process; or, If a collaborative operation request has write permissions, and the number of users that write processes in the kernel process cluster can handle reaches a set limit, then the corresponding read kernel process is selected from the kernel process cluster as the target kernel process; or... If the collaborative operation request has write operation permissions, the corresponding read process is determined from the kernel process cluster as the target kernel process, and in response to the received read / write state switch operation, the corresponding write process is determined from the kernel process cluster as the target kernel process.

[0009] Furthermore, in the kernel process cluster, the writing kernel process generates synchronization information for the target cooperative object, and synchronizes the synchronization information to each reading kernel process in the kernel process cluster, so that each reading kernel process can synchronize data with the writing kernel process through the synchronization information, which is a storage snapshot or a modification log.

[0010] Furthermore, the method also includes: When creating a new kernel process in a kernel process cluster, the new kernel process is created based on a storage snapshot of the remaining kernel processes in the kernel process cluster.

[0011] Furthermore, before determining the kernel process cluster to which the target collaborative session is bound based on session information, the process also includes: Obtain the load information of the target collaborative session; Based on load information, select at least one write kernel process and / or at least one read kernel process from the specified service cluster nodes; A kernel process cluster is constructed based on at least one write kernel process and / or at least one read kernel process.

[0012] Furthermore, based on load information, at least one write kernel process and / or at least one read kernel process are selected from the specified service cluster nodes, including: The number of write kernel processes and / or read kernel processes in the kernel process cluster is determined based on load information. Based on the number of write kernel processes and / or read kernel processes, select at least one specified service cluster node from the service cluster according to the load balancing principle, and select the corresponding number of write kernel processes and / or read kernel processes from the specified service cluster node.

[0013] Furthermore, after constructing the kernel process cluster based on at least one selected write kernel process and / or at least one read kernel process, the process further includes: Monitor the session status of the target collaborative session; Adjust the number of read kernel processes and write kernel processes in the kernel process cluster based on the session state.

[0014] Furthermore, after constructing the kernel process cluster based on at least one selected write kernel process and / or at least one read kernel process, the process further includes: If the target collaborative session is detected to have ended, release the kernel processes of the kernel process cluster.

[0015] Furthermore, the method also includes: Based on the log queue, the modification logs of the target collaborative session are received, and the modification logs of the same object in the log queue are identified as target logs. The target logs are then merged based on the modification time sequence.

[0016] Furthermore, after receiving the modification logs of the target collaborative session based on the log queue, it also includes: The changes in the log queue are broadcast sequentially to each kernel process in the kernel process cluster to synchronize data for the target collaborative session; or, It receives pull requests from the corresponding kernel process in the kernel process cluster, and returns the specified change logs based on the pull requests in order to perform data synchronization for the corresponding kernel process.

[0017] In a second aspect, embodiments of this application provide a collaborative session management system, including: The request receiving module is used to receive collaborative operation requests from the target collaborative object. The collaborative operation request contains session information of the target collaborative session to which the target collaborative object belongs. The cluster determination module is used to determine the kernel process cluster bound to the target collaborative session based on session information. The kernel process cluster includes at least one write kernel process and / or at least one read kernel process. The request processing module is used to determine the target kernel process from the kernel process cluster and send the cooperative operation request to the target kernel process for processing.

[0018] In a third aspect, embodiments of this application provide an electronic device, including: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the collaborative session management method as described in the first aspect.

[0019] In a fourth aspect, embodiments of this application provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the collaborative session management method as described in the first aspect.

[0020] This application embodiment receives a collaborative operation request from a target collaborative object, the request containing session information of the target collaborative session to which the target collaborative object belongs; based on the session information, it determines the kernel process cluster bound to the target collaborative session, the kernel process cluster including at least one write kernel process and / or at least one read kernel process; it then determines the target kernel process from the kernel process cluster and sends the collaborative operation request to the target kernel process for processing. By employing the above technical means, and introducing a mechanism for dynamically binding read-write separated kernel process clusters based on collaborative session information, read and write operations for the same collaborative object can be distributed to different kernel processes for parallel processing. This achieves process-level read-write separation and load balancing, avoiding the problems of low collaborative operation performance and insufficient concurrency support caused by single-process serial processing of multi-person collaborative sessions, and improving the system's support capability and resource utilization efficiency for high-concurrency read-write scenarios. Attached Figure Description

[0021] Figure 1 This is a flowchart of a collaborative session management method provided in Embodiment 1 of this application; Figure 2 This is a schematic diagram of the collaborative session management architecture in Embodiment 1 of this application; Figure 3 This is a flowchart illustrating the construction process of the kernel process cluster in Embodiment 1 of this application; Figure 4 This is a flowchart illustrating the determination of the target kernel process in Embodiment 1 of this application; Figure 5 This is a schematic diagram of kernel process binding in Embodiment 1 of this application; Figure 6 This is a schematic diagram of data synchronization of the kernel process in Embodiment 1 of this application; Figure 7 This is a flowchart illustrating the adjustment of the number of kernel processes in Embodiment 1 of this application; Figure 8 This is a schematic diagram of the structure of a collaborative conversation management system provided in Embodiment 2 of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in Embodiment 3 of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0023] The collaborative session management method provided in this application aims to achieve process-level read-write separation and load balancing by introducing a mechanism that dynamically binds read-write separation kernel process clusters based on collaborative session information. This allows read and write operations on the same collaborative object to be distributed to different kernel processes for parallel processing. A session refers to a dedicated processing unit (e.g., a process or service node) established for a collaborative object, specifically responsible for receiving, processing, and synchronizing all collaborative operations (e.g., read and write operations) of that collaborative object. It is the core "central hub" for real-time synchronization of collaborative documents and multi-person collaboration.

[0024] In system architectures for multi-user collaborative sessions (such as online multi-user collaboration centered around a specific collaborative object), a common approach is to create an independent kernel process for each collaborative object (digital object, such as online documents, images, game objects, etc.) to manage collaborative sessions, achieving secure isolation and ensuring the stability of collaborative computing. Furthermore, to guarantee data consistency, this kernel process needs to handle all read and write operations simultaneously and serialize these operations. When multiple users perform read and write operations on the same collaborative object, a task queue is used, with the kernel process processing each operation sequentially. However, this single-process, serial processing architecture for collaborative session read and write operations imposes a significant performance ceiling on individual collaborative objects, making it unsuitable for higher concurrency read and write scenarios and limiting the number of users participating in collaborative operations. Simultaneously, system resources are statically allocated on a per-collaborative-object and per-process basis, with each collaborative object creating a separate kernel process, leading to uneven server resource utilization and increased operational costs.

[0025] Based on this, a collaborative session management method according to an embodiment of this application is provided to solve the technical problems of low upper limit of collaborative operation performance and insufficient concurrency support capability caused by single-process serial processing in the prior art.

[0026] Example 1: Figure 1 A flowchart of a collaborative session management method provided in Embodiment 1 of this application is given. The collaborative session management method provided in this embodiment can be executed by a collaborative session management device, which can be implemented by software and / or hardware. The collaborative session management device can consist of two or more physical entities, or it can consist of a single physical entity. Generally, the collaborative session management device can be a computing node such as a computer or a server host.

[0027] The following description uses the collaborative session management device as an example to illustrate the collaborative session management method. (Refer to...) Figure 1 The collaborative session management method specifically includes: S110. Receive a collaborative operation request from the target collaborative object. The collaborative operation request includes session information of the target collaborative session to which the target collaborative object belongs.

[0028] The collaborative session management method of this application embodiment, when managing multi-user collaborative sessions, receives collaborative operation requests for a target collaborative object to obtain session information of the target collaborative session carried in the request. The collaborative object is the digital object (such as an online document, image, game object, etc.) operated in the multi-user collaborative session; for the current multi-user collaborative session, the collaborative object is defined as the target collaborative object. The current multi-user collaborative session is the target collaborative session, referring to a processing object involving a multi-user collaborative interaction process established around the target collaborative object. Session information is a set of metadata, including the kernel process cluster identifier processing the target collaborative session, the user identity identifier initiating the operation, and / or the unique identifier of the target collaborative object, as well as at least one of the following: the type attribute of the current operation (read operation or write operation). Furthermore, session information may also include contextual data reflecting the dynamic characteristics of the session, such as the number of active users in the current collaborative session and the persistence status of the session. By obtaining this session information, the real-time status of the session can be determined, enabling the collaborative session management device to perceive load changes and business characteristics of the multi-user collaborative session, thereby providing a data foundation for efficient and accurate operation request scheduling.

[0029] Specifically, refer to Figure 2 This application provides a schematic diagram of a collaborative session management architecture according to an embodiment of the present application. The collaborative session management architecture adopts a layered design, dynamically optimizing resource scheduling from top to bottom through a three-layer architecture consisting of a cluster control layer, an editing service layer, and a kernel computing layer, thereby supporting high-concurrency read and write operations on collaborative objects. The editing service layer corresponds to a physical service cluster, while the kernel computing layer corresponds to a logical kernel process cluster. Kernel processes on the kernel process cluster run on the cluster nodes of the service cluster.

[0030] The cluster control layer, serving as the entry point, is responsible for establishing, accessing, and managing multi-user collaborative sessions. This layer provides basic capabilities such as long and short connection service management, codec protocol conversion, message push, and security protection through the access gateway module, ensuring the standardized access of various collaborative operation requests. The user session management module is responsible for user identity verification, session state maintenance, and message push, providing unified identity authentication and session management capabilities. The session routing module intelligently routes requests to the corresponding kernel processes of the service cluster nodes for processing based on user session information and cluster status. The collaborative session management device of this application can include all modules of this cluster control layer to realize collaborative session management for multi-user collaborative sessions. Furthermore, the cluster control layer can also be configured with a cluster management decision module responsible for global load balancing and cluster lifecycle management. By collecting real-time monitoring data of each node, it dynamically allocates kernel clusters to each collaborative object and dynamically adjusts the cluster size based on session awareness, achieving intelligent resource scheduling.

[0031] The editing service layer provides collaborative editing services for collaborative objects. Within the service cluster nodes, the editing service process can simultaneously manage several kernel processes, thus enabling collaborative editing services at the editing service layer. The editing service layer abstracts the scheduling of the underlying kernel cluster into a unified RPC interface through a kernel interface unified scheduling module, simplifying the complexity of upper-layer business applications. The collaborative session and kernel binding module achieves precise mapping between sessions and kernel processes. For example, when the collaborative object is a document, the document's write and read sessions are evenly distributed across different service cluster nodes and bound to the corresponding kernel processes. The storage snapshot / modification log synchronization module employs a data synchronization scheme combining snapshots and incremental logs. Through a complementary mechanism of broadcast push and on-demand pull, along with message deduplication and compressed transmission technologies, it ensures efficient and reliable data synchronization across multiple kernels by synchronizing data between read and write kernel processes. The cluster management execution module is responsible for interacting with the upper-layer decision-making module, executing specific cluster management commands, and handling fault recovery.

[0032] The kernel computing layer, acting as the processing engine for collaborative data, employs a dynamic cluster architecture with read-write separation. This layer organizes kernel processes into clusters divided at the collaborative object granularity. Each cluster contains at least one write kernel process and at least one read kernel process. These processes are dynamically created based on cluster management decisions and are bound one-to-one with the collaborative object's session. The kernel process module includes key functional modules such as collaborative object editing computation, collaborative log generation, change log generation and replay, and snapshot generation and loading, collectively ensuring the consistency and reliability of collaborative data. Furthermore, each kernel process, as a computing resource, can simultaneously serve multiple different collaborative objects; that is, the kernel process cluster is a dynamic logical cluster relative to each collaborative object, rather than a physically fixed cluster. The kernel process cluster can flexibly adjust the number and allocation of kernel processes based on the actual load of the collaborative session, thereby achieving efficient resource utilization and load balancing.

[0033] It should be noted that the aforementioned service cluster refers to a collection of hardware resources consisting of multiple physical or virtual server nodes, used to provide high availability and load balancing infrastructure, with relatively static resource allocation. The kernel process cluster, on the other hand, is a collection of logical computing units formed by further abstracting and encapsulating specific collaborative objects (such as documents) on top of the physical server cluster. The kernel process cluster is not a fixed physical deployment, but rather a lightweight cluster with a read-write separation structure that is temporarily constructed based on the needs of the collaborative session, dynamically scheduling and combining available kernel processes from the underlying physical cluster to serve a single collaborative object. That is, the lifecycle of the kernel process cluster is bound to the collaborative session, and any kernel process in the physical cluster can be reused on demand by different collaborative objects, thereby achieving decoupling of physical resources and collaborative computing capabilities, as well as fine-grained management and efficient reuse of computing resources.

[0034] Through a refined three-layer collaborative design and kernel-level read-write separation, the performance bottleneck caused by single-process serial processing is avoided. At the same time, dynamic cluster management enables elastic resource allocation, providing high-performance and highly available technical support for large-scale collaborative scenarios.

[0035] Based on the above collaborative session management architecture, referring to Figure 3 Before determining the kernel process cluster to which the target collaborative session is bound based on session information, the process also includes: S1001. Obtain the load information of the target collaborative session; S1002. Select at least one write kernel process and / or at least one read kernel process from the specified service cluster nodes based on the load information; S1003. Construct a kernel process cluster based on at least one selected write kernel process and / or at least one read kernel process.

[0036] In the collaborative session management architecture provided in this application embodiment, when a user initiates a target collaborative session, the allocation and dynamic formation of cluster resources are first executed. Taking a document as the target collaborative object as an example, specifically, by obtaining the real-time load information of the target collaborative session, this information can be a multi-dimensional set of indicators, including data that directly reflects concurrency pressure, such as the number of active users in the current collaborative session and the frequency of user operations. In addition, it can also cover the data characteristics of the target collaborative object itself, such as document size, structural complexity, and the computational intensity shown by historical operations. Based on this load information, the most suitable service node can be selected from multiple available nodes distributed in the service cluster to carry the kernel process according to the preset resource scheduling strategy and load balancing algorithm. During the selection process, according to the operation permissions provided by the document, if the document provides write operation permissions, the collaborative session management device will allocate at least one write kernel process dedicated to handling data changes for the current session. It is usually deployed on a service cluster node with relatively low load or better network latency with the log storage system to ensure the efficiency of data persistence; at the same time, if the current document requires read operation permissions, the collaborative session management device will allocate at least one read kernel process for reading data for the current session. Furthermore, based on the estimated concurrency of current read operations, the required number of read kernel processes is dynamically determined, and these read processes are distributed across multiple different service cluster nodes, thereby achieving read load distribution at the physical level. Finally, these selected write kernel processes and / or read kernel processes, which may be located on different physical nodes, are logically associated and orchestrated to construct a kernel process cluster dedicated to this target collaborative session. This fundamentally achieves on-demand, elastic, and fine-grained allocation of computing resources, effectively solving the problem of uneven utilization caused by static resource configuration, and providing underlying architectural support for subsequent high-concurrency read and write operations.

[0037] Furthermore, based on load information, at least one write kernel process and / or at least one read kernel process are selected from the specified service cluster nodes, including: The number of write kernel processes and / or read kernel processes in the kernel process cluster is determined based on load information. Based on the number of write kernel processes and / or read kernel processes, select at least one specified service cluster node from the service cluster according to the load balancing principle, and select the corresponding number of write kernel processes and / or read kernel processes from the specified service cluster node.

[0038] When selecting kernel processes from specified service cluster nodes based on load information, the acquired multi-dimensional load information is comprehensively analyzed. For example, by weighted calculation and trend prediction of multi-dimensional load information, the kernel process configuration specifications required to ensure session service quality are calculated, namely the number of write kernel processes and the number of read kernel processes. Generally, the write kernel process is usually determined to be a single process based on data consistency and transaction integrity requirements. The number of read kernel processes can be dynamically derived by establishing a functional model between the number of concurrent users, operation complexity, and single-process processing capacity, ensuring that its scale can meet the current read throughput requirements while reserving appropriate elasticity to cope with load fluctuations. Optionally, multiple write kernel processes can also be configured according to actual needs, provided that transaction granularity is ensured and data is accurately synchronized. For example, a large document can be divided into multiple logically independent and operationally non-conflicting regions (such as different chapters of a document or different layers of a design drawing), with each region handled by an independent write kernel process. Multiple write processes handle operations in different regions in parallel, and are coordinated by a unified conflict merging and log serialization module at the upper layer. This ensures that all write operations are eventually integrated into a globally ordered log sequence, thereby improving write concurrency while still guaranteeing eventual data consistency. This application does not impose a fixed limit on the specific number of kernel processes; it can be adaptively configured according to actual scheduling needs, which will not be elaborated here.

[0039] Furthermore, after specifying the number and specifications of write and read kernel processes, a load balancing algorithm can be used to select the most suitable combination of nodes from the global node pool of the editing service cluster. For example, the load balancing algorithm considers the real-time hardware resource utilization of each cluster node (such as CPU core idle rate, available memory capacity, and network I / O bandwidth) and introduces a business affinity factor, prioritizing nodes that have cached relevant data for the collaborative object, or nodes located in the same availability zone as the log persistent storage system to reduce network latency. For write kernel processes, the node with the closest network topology to the log system and the lowest overall load score can be selected to ensure low latency and high reliability of data writing. For read kernel processes, a strategy combining minimum connection count and resource saturation is adopted to distribute them evenly across nodes that meet the criteria, thereby achieving horizontal distribution and physical isolation of the read load. Finally, by issuing resource allocation instructions to these selected service cluster nodes, a specified number of write and read kernel processes are instantiated or allocated from the local resource pool of each node. This enables a precise match between the supply of computing resources and the actual needs of the sessions, while improving the overall throughput efficiency and resource utilization of the cluster.

[0040] S120. Determine the kernel process cluster bound to the target collaborative session based on session information. The kernel process cluster includes at least one write kernel process and at least one read kernel process.

[0041] Based on the pre-configured kernel process cluster described above, and by binding it to its target collaborative session, when a collaborative operation request is received from the target collaborative session, the kernel process cluster to which the target collaborative session is bound can be determined by obtaining the session information contained in the collaborative operation request. This allows for the selection of a kernel process from that cluster to handle the collaborative operation request. The kernel process cluster internally employs a read-write separation functional division, including at least one write kernel process dedicated to handling data modification operations, and at least one read kernel process for handling data query and display operations. This ensures that computing resources can be allocated on demand in a fine-grained and elastic manner, guaranteeing data isolation and computational stability for each collaborative object while avoiding the constraints of a single process's resource limits.

[0042] S130. Determine the target kernel process from the kernel process cluster and send the cooperative operation request to the target kernel process for processing.

[0043] Furthermore, after determining the kernel process cluster corresponding to the target collaborative session, a specific kernel process can be selected from the determined kernel process cluster to handle the collaborative operation request. This kernel process is defined as the target kernel process, and the collaborative operation request is sent to this process for processing.

[0044] Among them, reference Figure 4 Identify the target kernel process from the kernel process cluster, including: S1301, Identify the operation type of the collaborative operation request; S1302. When the operation type is a write operation, if there is a write kernel process in the kernel process cluster corresponding to the target cooperative session, determine a write kernel process as the target kernel process from at least one write kernel process in the kernel process cluster; if there is no write kernel process in the kernel process cluster corresponding to the target cooperative session, create a write kernel process in the kernel process cluster as the target kernel process. Alternatively, when the operation type is a read operation, if there is a read kernel process in the kernel process cluster corresponding to the target cooperative session, determine a read kernel process as the target kernel process from at least one read kernel process in the kernel process cluster; if there is no read kernel process in the kernel process cluster corresponding to the target cooperative session, create a read kernel process in the kernel process cluster as the target kernel process.

[0045] In determining the target kernel process from the kernel process cluster, the cooperative operation request is first parsed to identify its operation type (read or write). For write operations, it first checks whether a write kernel process serving the target cooperative session already exists in the current kernel process cluster; if it exists, the existing write kernel process is directly identified as the target kernel process; if it does not exist, a new write kernel process needs to be dynamically created and added to the cluster, serving as the target kernel process. Similarly, for read operations, it checks whether an available read kernel process exists; if it does, a target kernel process is selected from the existing read kernel processes according to the load balancing strategy; if it does not exist, a new read kernel process is created and identified as the target kernel process. Generally, a write process is created when the session is first opened by an editing user, and a read process is created when it is first opened by a read-only user; subsequent session requests of the same type reuse the existing process.

[0046] The target kernel process strictly adheres to the read-write separation principle. For write operation requests, they are consistently routed to a pre-defined (reused or newly created) write kernel process in the cluster. This process then processes all data modification instructions serially, ensuring strong data consistency and transactional operation. For read operation requests, if multiple read kernel processes already exist in the kernel process cluster, a load balancer can select a process with a lighter current load from among the corresponding read kernel processes in the cluster as the target, thereby distributing a large number of read requests across multiple parallel computing units. If there is only one read kernel process (reused or newly created), then that read process handles the read operation requests.

[0047] By using an operation type-based routing mechanism, the reliability of write operations and the high concurrency of read operations can be balanced, which improves the system's processing throughput and response speed in high-concurrency scenarios, while also improving the overall utilization of server resources and effectively reducing operation and maintenance costs.

[0048] Optionally, when the kernel process cluster includes multiple write kernel processes, these write kernel processes include master nodes and child nodes. Determining the target kernel process from the kernel process cluster includes: Identify the operation type of the collaborative operation request; When the operation type is write operation, the master node or child node in the kernel process cluster is selected as the target kernel process. The master node is used to synchronize the write operation data of the target collaborative session based on the synchronization information of each child node, and synchronize the synchronization information to the child nodes.

[0049] For example, a large document can be divided into multiple logically independent and operationally non-conflicting regions (such as different chapters of a document or different layers of a design drawing). Each region is handled by an independent write kernel process. Multiple write processes process operations in different regions in parallel, and are coordinated by a unified conflict merging and log serialization module at the upper layer. This ensures that all write operations are eventually integrated into a globally ordered log sequence, thereby improving write concurrency while still guaranteeing eventual data consistency.

[0050] Furthermore, when the kernel process cluster is configured to include multiple write kernel processes, these write kernel processes are configured with a master-slave coordination structure. One write kernel process is designated as the master node, and the rest are child nodes. Of course, any child node can also have subordinate child nodes, in which case that child node can act as the master node of its subordinate child node. This child node is used to receive the change logs from its subordinate child nodes, and to resolve collaborative conflicts based on these logs to obtain a consistent version. This child node also forwards the change logs received from its subordinate child nodes to other subordinate child nodes. In determining the target kernel process from the kernel process cluster, after identifying the collaborative operation request as a write operation, the target kernel process for this request is selected from the write kernel process group containing the master node and child nodes, based on a preset routing strategy or real-time load conditions. This target could be the master node or any child node. After processing its local write operation, the selected child node reports its generated synchronization information (such as incremental change logs) to its master node. The master node coordinates data synchronization across nodes. It receives and integrates synchronization information from various child nodes, executes conflict detection and merging algorithms, and generates a globally ordered and consistent synchronization message. Subsequently, the master node broadcasts this synchronization message to all child nodes and all read kernel processes in the kernel process cluster, ensuring the entire cluster maintains a synchronized data state and guaranteeing eventual data consistency and global consistency of edit operations. This multi-level node configuration allows for the satisfaction of data consistency and transaction integrity requirements even when multiple write processes are configured.

[0051] Optionally, the target kernel process is determined from the kernel process cluster, including: Identify the operation permissions required for collaborative operation requests; If a collaborative operation request has write permissions, but the number of users handled by the write processes in the kernel process cluster has not reached the set limit, the corresponding write process is selected from the kernel process cluster as the target kernel process; or, If a collaborative operation request has write permissions, and the number of users that write processes in the kernel process cluster can handle reaches a set limit, then the corresponding read kernel process is selected from the kernel process cluster as the target kernel process; or... If the collaborative operation request has write operation permissions, the corresponding read process is determined from the kernel process cluster as the target kernel process, and in response to the received read / write state switch operation, the corresponding write process is determined from the kernel process cluster as the target kernel process.

[0052] When determining the target kernel process from the kernel process cluster, this application also identifies the operation permissions of the initiating user by parsing the collaborative operation request. If the request has write operation permissions, it further checks whether the number of user sessions served by the currently running write kernel processes in the kernel process cluster has reached the preset concurrency limit. If the limit has not been reached, a write kernel process is directly selected from the cluster as the target kernel process to perform data editing operations. If the load of the write kernel process has reached its limit, for load protection and service degradation considerations, a read kernel process will be selected from the read kernel process cluster as the target kernel process for this request. In this case, the user can only perform limited preview or cache read operations and cannot perform persistent modification operations, thereby ensuring the stability of the main write service.

[0053] Furthermore, this application supports dynamic permission switching. Even if a user has write permissions, their request can be routed to a read kernel process based on a strategy (such as the initial default state or node load balancing). Subsequently, when a user actually triggers a clear read / write state switch (e.g., clicking the "Edit" button in the editing interface), the target kernel process is dynamically switched to the corresponding write kernel process in real time to begin processing the write operation. Thus, through the above mechanisms, traffic scheduling and service degradation fault tolerance are achieved in resource-constrained or service overload scenarios, effectively balancing the performance pressure of the write service and the user's operational experience.

[0054] Optionally, if the cooperative operation request is scheduled to be handled by a kernel process, the user identifier to which the cooperative operation request belongs is bound to that kernel process, so that the kernel process that handles cooperative operation requests from different users can be determined subsequently based on the binding relationship. For example, refer to Figure 5For a write operation on document A by session 1 (user ID), after the initial scheduling of session 1's collaborative operation request to the write kernel process on service cluster node 1, a binding relationship is established between document A, session 1, and the write kernel process. For a read operation on document A by session 2 (user ID), after the initial scheduling of session 2's collaborative operation request to the read kernel process 1 on service cluster node 2, a binding relationship is established between document A, session 2, and the read kernel process 1. Based on this binding relationship, the kernel process handling collaborative operation requests from different users can be accurately determined. When a kernel process already bound to this user ID is detected in the cluster, that bound kernel process is directly selected as the target kernel process. This reuse of existing connections effectively reduces request routing overhead while maintaining the contextual continuity of the user operation sequence.

[0055] Optionally, in the kernel process cluster, the writing kernel process generates synchronization information for the target cooperative object, and synchronizes the synchronization information to each reading kernel process in the kernel process cluster, so that each reading kernel process can synchronize data with the writing kernel process through the synchronization information, which is a storage snapshot or a modification log.

[0056] Reference Figure 6 During the operation of the kernel process cluster, for write operations performed by the write kernel process, synchronization information for the target collaborating object can be generated by the write kernel process and reliably synchronized to each read kernel process in the kernel process cluster, thereby ensuring eventual data consistency in the distributed architecture. During data synchronization, the storage snapshot / modification log synchronization module deployed by the write process acts as the master node, sending the synchronization information to the storage snapshot / modification log synchronization module deployed by the read process, i.e., the slave node. Synchronization information can take two data forms: storage snapshots or modification logs. A storage snapshot is a complete copy of the target collaborating object's state at a specific point in time, actively generated by the write kernel process based on a preset time period or key operation nodes (such as when a user executes a save command). Modification logs record, in a structured form, the sequence of all incremental data change operations that have occurred since the previous snapshot base point, including complete information such as operation type, scope, content differences, and metadata. At the synchronization execution level, a multi-channel collaborative data distribution mechanism can be adopted. For newly generated change logs, the write kernel process actively pushes them to all read kernel processes within the cluster, or their subordinate write kernel processes, via real-time broadcast. Simultaneously, when a read kernel process detects data lag or the need to rebuild historical versions, it can proactively initiate an on-demand fetch request to the write kernel process to obtain a specified range of change logs or the latest snapshot. This achieves real-time data synchronization with the change logs through the snapshot mechanism, significantly improving system response speed and resource utilization efficiency while ensuring data consistency.

[0057] Optionally, the method further includes: When creating a new kernel process in a kernel process cluster, the new kernel process is created based on a storage snapshot of the remaining kernel processes in the kernel process cluster.

[0058] When a new kernel process (whether read or write) needs to be dynamically created within an existing kernel process cluster, an efficient data initialization mechanism is employed for kernel process creation. Specifically, by prioritizing an existing kernel process with low load or the most up-to-date state within the cluster, a storage snapshot maintained by that process is directly obtained. This snapshot represents a complete, persistent copy of the target collaborating object's state at a recent point in time. This snapshot contains all data structures and content up to the time of its creation. Using this snapshot as a base image, a new kernel process can be quickly instantiated and initialized, providing it with a usable data base immediately upon startup. This avoids the significant time and computational resource overhead of rebuilding the state from scratch or replaying all historical change logs. After the new process is created, incremental synchronization is used to retrieve and replay the latest change logs from the log system since the snapshot's creation point, thereby quickly synchronizing the latest data state with other processes in the cluster.

[0059] Optionally, refer to Figure 7 After constructing the kernel process cluster based on at least one selected write kernel process and / or at least one read kernel process, the process further includes: S1401. Monitor the session status of the target collaborative session; S1402. Adjust the number of read kernel processes and write kernel processes in the kernel process cluster according to the session state.

[0060] For an established kernel process cluster, a continuous session state monitoring and resource scheduling process is initiated during the management of its associated multi-user collaborative sessions to continuously track the dynamic session state of the target collaborative session. Session state can include at least one of the following: the number of collaborating users in the target collaborative session, the data volume of the target collaborative object, and the read kernel process load of the kernel process cluster. The number of collaborating users in the target collaborative session is a direct parameter measuring the concurrent pressure of read and write operations; its value directly reflects the real-time load scale that the system needs to handle. Secondly, the data volume of the target collaborative object includes document size, structural complexity, and the number of historical versions; these data characteristics directly affect the memory usage and computational intensity of the kernel processes. The write and read kernel process loads of the kernel process cluster provide accurate runtime status indicators. By collecting real-time performance data such as CPU utilization, memory usage ratio, I / O wait time, and request queue depth of each process, the processing capacity and load saturation of the current cluster are comprehensively evaluated.

[0061] By collecting the aforementioned multi-dimensional session state information, analysis and judgment can be performed based on a preset elastic scaling strategy. When monitoring data indicates an increase in read load, such as the number of concurrent users exceeding a set threshold or the average CPU load of the read kernel process consistently exceeding a safety threshold, a scaling instruction will be generated, instructing designated service cluster nodes to dynamically create and add new read kernel processes to the existing cluster to share the read pressure. Conversely, when read load is consistently low, such as a significant decrease in concurrent users and resource utilization consistently below the idle threshold, a scaling instruction will be generated to conserve system resources, instructing designated service cluster nodes to release some read kernel processes. Similarly, for write kernel processes, the scaling operation is performed in the same manner as for read kernel processes. This ensures a smooth user experience under high concurrency scenarios while automatically releasing redundant resources during low-load periods, achieving a balance between service performance and resource costs.

[0062] Optionally, after constructing the kernel process cluster based on at least one selected write kernel process and / or at least one read kernel process, the method further includes: If the target collaborative session is detected to have ended, release the kernel processes of the kernel process cluster.

[0063] Releasing the kernel process refers to unbinding the target collaborative session from the kernel process. The released kernel process can then be used to handle other collaborative sessions, or it can be shut down directly.

[0064] For established kernel process clusters, during the management of their respective multi-user collaborative sessions, the activity status of the target collaborative session is continuously monitored to ensure timely resource reclamation at the end of the session's lifecycle. For example, this involves verifying whether all user connections have been disconnected, whether the session persistence timer has expired, or whether an explicit session termination command has been received. Once the target collaborative session is confirmed to have completely ended, the cluster disbanding process is initiated. This is achieved by sending termination signals to all kernel processes serving the session, including the sole write kernel process and all read kernel processes. These kernel processes exit in an orderly manner after completing any unfinished data persistence operations, and their occupied computing resources (such as memory and CPU time slices), disk resources (such as modification logs and snapshots), and network resources are immediately released and re-integrated into the global resource pool of the edit service cluster nodes, becoming available resources for other new collaborative sessions. Simultaneously, the cluster status information is updated, logically and completely disbanding the kernel process cluster.

[0065] Optionally, the collaborative session management method of this application further includes: Based on the log queue, the modification logs of the target collaborative session are received, and the modification logs of the same object in the log queue are identified as target logs. The target logs are then merged based on the modification time sequence.

[0066] In the collaborative session management method provided in this application embodiment, the log queue acts as a buffer for receiving and temporarily storing changes made by different users to the target collaborative object. The collaborative session management device continuously monitors this queue and analyzes the incoming change logs. When multiple change logs are identified as acting on the same logical object in the collaborative object (e.g., the same paragraph in a document, the same cell in a table), these related logs are defined as target logs that need to be merged.

[0067] Subsequently, the collaborative session management device merges the target logs based on the modification sequence (such as globally incrementing operation sequence numbers or timestamps) carried by these target logs and in conjunction with specific business rules (such as the character position range of text operations). The merging process generates a new, compact integrated log while preserving the final operation intent, effectively replacing the continuous operation effect of the original multiple logs. This optimization process effectively eliminates redundant intermediate operation records, thereby significantly reducing the amount of log data requiring persistent storage and network synchronization. This reduces the I / O overhead and network bandwidth usage of the collaborative session, while ensuring the integrity of the operation history and the consistency of the final data state.

[0068] Furthermore, after receiving the modification logs of the target collaborative session based on the log queue, it also includes: The changes in the log queue are broadcast sequentially to each kernel process in the kernel process cluster to synchronize data for the target collaborative session; or, It receives pull requests from the corresponding kernel process in the kernel process cluster, and returns the specified change logs based on the pull requests in order to perform data synchronization for the corresponding kernel process.

[0069] After receiving change logs from the log queue, eventual consistency of data within the kernel process cluster is ensured through either log broadcasting or on-demand retrieval. For log broadcasting, each change log entry in the log queue is proactively and sequentially pushed to all kernel processes within the cluster in real time, strictly adhering to the global operation sequence, thus achieving real-time data synchronization. For on-demand retrieval, when any kernel process in the cluster detects that its data version is lagging, it can proactively initiate a retrieval request to the log management service of the collaborative session management device, specifying the starting sequence number or time range of the required logs. The collaborative session management device then accurately returns the specified historical change logs for incremental replay by the requester. Thus, by using log broadcasting and on-demand retrieval, the reliability of collaborative session data synchronization is improved.

[0070] As described above, by receiving a collaborative operation request from a target collaborative object, which includes session information of the target collaborative session to which the target collaborative object belongs; determining the kernel process cluster bound to the target collaborative session based on the session information, the kernel process cluster includes at least one write kernel process and / or at least one read kernel process; identifying the target kernel process from the kernel process cluster, and sending the collaborative operation request to the target kernel process for processing. By employing the above technical means and introducing a mechanism for dynamically binding read-write separation kernel process clusters based on collaborative session information, read and write operations for the same collaborative object can be distributed to different kernel processes for parallel processing. This achieves process-level read-write separation and load balancing, avoiding the problems of low collaborative operation performance and insufficient concurrency support caused by single-process serial processing of multi-person collaborative sessions, and improving the system's support capability and resource utilization efficiency for high-concurrency read-write scenarios.

[0071] Example 2: Based on the above embodiments, Figure 8 This is a schematic diagram of a collaborative session management system provided in Embodiment 2 of this application. (Reference) Figure 8 The collaborative session management system provided in this embodiment specifically includes: The request receiving module 21 is used to receive the collaborative operation request of the target collaborative object. The collaborative operation request includes the session information of the target collaborative session to which the target collaborative object belongs. Cluster determination module 22 is used to determine the kernel process cluster bound to the target collaborative session based on session information. The kernel process cluster includes at least one write kernel process and / or at least one read kernel process. The request processing module 23 is used to determine the target kernel process from the kernel process cluster and send the cooperative operation request to the target kernel process for processing.

[0072] Specifically, the target kernel process is identified from the kernel process cluster, including: Identify the operation type of the collaborative operation request; When the operation type is write, if a write kernel process exists in the kernel process cluster corresponding to the target collaborative session, one write kernel process is selected from at least one write kernel process in the kernel process cluster as the target kernel process; if no write kernel process exists in the kernel process cluster corresponding to the target collaborative session, a write kernel process is created in the kernel process cluster as the target kernel process; or, When the operation type is a read operation, if there is a read kernel process in the kernel process cluster that corresponds to the target collaborative session, a read kernel process is selected from at least one read kernel process in the kernel process cluster as the target kernel process. If there is no read kernel process in the kernel process cluster that corresponds to the target collaborative session, a read kernel process is created in the kernel process cluster as the target kernel process.

[0073] Specifically, in a kernel process cluster comprising multiple write kernel processes, including master nodes and child nodes, the target kernel process is determined from the kernel process cluster, including: Identify the operation type of the collaborative operation request; When the operation type is write operation, the master node or child node in the kernel process cluster is selected as the target kernel process. The master node is used to synchronize the write operation data of the target collaborative session based on the synchronization information of each child node, and synchronize the synchronization information to the child nodes.

[0074] Specifically, the target kernel process is identified from the kernel process cluster, including: Identify the operation permissions required for collaborative operation requests; If a collaborative operation request has write permissions, but the number of users handled by the write processes in the kernel process cluster has not reached the set limit, the corresponding write process is selected from the kernel process cluster as the target kernel process; or, If a collaborative operation request has write permissions, and the number of users that write processes in the kernel process cluster can handle reaches a set limit, then the corresponding read kernel process is selected from the kernel process cluster as the target kernel process; or... If the collaborative operation request has write operation permissions, the corresponding read process is determined from the kernel process cluster as the target kernel process, and in response to the received read / write state switch operation, the corresponding write process is determined from the kernel process cluster as the target kernel process.

[0075] Specifically, in the kernel process cluster, the writing kernel process generates synchronization information for the target cooperative object, and synchronizes the synchronization information to each reading kernel process in the kernel process cluster, so that each reading kernel process can synchronize data with the writing kernel process through the synchronization information, which is a storage snapshot or a change log.

[0076] Specifically, the system also includes: When creating a new kernel process in a kernel process cluster, the new kernel process is created based on a storage snapshot of the remaining kernel processes in the kernel process cluster.

[0077] Specifically, before determining the kernel process cluster to which the target collaborative session is bound based on session information, the process also includes: Obtain the load information of the target collaborative session; Based on load information, select at least one write kernel process and / or at least one read kernel process from the specified service cluster nodes; A kernel process cluster is constructed based on at least one write kernel process and / or at least one read kernel process.

[0078] Specifically, based on load information, at least one write kernel process and / or at least one read kernel process are selected from the specified service cluster nodes, including: The number of write kernel processes and / or read kernel processes in the kernel process cluster is determined based on load information. Based on the number of write kernel processes and / or read kernel processes, select at least one specified service cluster node from the service cluster according to the load balancing principle, and select the corresponding number of write kernel processes and / or read kernel processes from the specified service cluster node.

[0079] Specifically, after constructing the kernel process cluster based on at least one selected write kernel process and / or at least one read kernel process, the process further includes: Monitor the session status of the target collaborative session; Adjust the number of read kernel processes and write kernel processes in the kernel process cluster based on the session state.

[0080] Specifically, after constructing the kernel process cluster based on at least one selected write kernel process and / or at least one read kernel process, the process further includes: If the target collaborative session is detected to have ended, release the kernel processes of the kernel process cluster.

[0081] Specifically, the system also includes: Based on the log queue, the modification logs of the target collaborative session are received, and the modification logs of the same object in the log queue are identified as target logs. The target logs are then merged based on the modification time sequence.

[0082] Specifically, after receiving the modification logs of the target collaborative session based on the log queue, the process also includes: The changes in the log queue are broadcast sequentially to each kernel process in the kernel process cluster to synchronize data for the target collaborative session; or, It receives pull requests from the corresponding kernel process in the kernel process cluster, and returns the specified change logs based on the pull requests in order to perform data synchronization for the corresponding kernel process.

[0083] As described above, by receiving a collaborative operation request from a target collaborative object, which includes session information of the target collaborative session to which the target collaborative object belongs; determining the kernel process cluster bound to the target collaborative session based on the session information, the kernel process cluster includes at least one write kernel process and / or at least one read kernel process; identifying the target kernel process from the kernel process cluster, and sending the collaborative operation request to the target kernel process for processing. By employing the above technical means and introducing a mechanism for dynamically binding read-write separation kernel process clusters based on collaborative session information, read and write operations for the same collaborative object can be distributed to different kernel processes for parallel processing. This achieves process-level read-write separation and load balancing, avoiding the problems of low collaborative operation performance and insufficient concurrency support caused by single-process serial processing of multi-person collaborative sessions, and improving the system's support capability and resource utilization efficiency for high-concurrency read-write scenarios.

[0084] The collaborative session management system provided in Embodiment 2 of this application can be used to execute the collaborative session management method provided in Embodiment 1 above, and has corresponding functions and beneficial effects.

[0085] Example 3: This application provides an electronic device in embodiment three, referring to... Figure 9 The electronic device includes a processor 31, a memory 32, a communication module 33, an input device 34, and an output device 35. The electronic device may have one or more processors and one or more memories. The processor, memory, communication module, input device, and output device of the electronic device can be connected via a bus or other means.

[0086] Memory, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the collaborative session management method described in any embodiment of this application (e.g., the request receiving module, cluster determination module, and request processing module in the collaborative session management system). Memory may primarily include a program storage area and a data storage area, wherein the program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on device usage, etc. Furthermore, memory may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0087] The communication module is used for data transmission.

[0088] The processor executes various functional applications and data processing of the device by running software programs, instructions, and modules stored in memory, thereby realizing the aforementioned collaborative session management method.

[0089] Input devices can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the device. Output devices may include display devices such as displays.

[0090] The electronic device provided above can be used to execute the collaborative session management method provided in Embodiment 1 above, and has corresponding functions and beneficial effects.

[0091] Example 4: This application also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a collaborative session management method. The collaborative session management method includes: receiving a collaborative operation request from a target collaborative object, the collaborative operation request containing session information of a target collaborative session to which the target collaborative object belongs; determining, based on the session information, a kernel process cluster bound to the target collaborative session, the kernel process cluster including at least one write kernel process and / or at least one read kernel process; selecting a target kernel process from the kernel process cluster; and sending the collaborative operation request to the target kernel process for processing.

[0092] Storage medium – any type of memory device or storage device. The term “storage medium” is intended to include: mounting media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements, etc. Storage medium may also include other types of memory or combinations thereof. Furthermore, storage medium may reside in a first computer system in which the program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term “storage medium” can include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0093] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the collaborative session management method described above, but can also execute related operations in the collaborative session management method provided in any embodiment of this application.

[0094] The collaborative session management system, storage medium, and electronic device provided in the above embodiments can execute the collaborative session management method provided in any embodiment of this application. For technical details not described in detail in the above embodiments, please refer to the collaborative session management method provided in any embodiment of this application.

[0095] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A collaborative session management method, characterized in that, include: Receive a collaborative operation request from a target collaborative object, wherein the collaborative operation request contains session information of the target collaborative session to which the target collaborative object belongs; Based on the session information, the kernel process cluster bound to the target collaborative session is determined, and the kernel process cluster includes at least one write kernel process and / or at least one read kernel process; The target kernel process is determined from the kernel process cluster, and the cooperative operation request is sent to the target kernel process for processing.

2. The collaborative session management method according to claim 1, characterized in that, The step of determining the target kernel process from the kernel process cluster includes: Identify the operation type of the collaborative operation request; When the operation type is a write operation, if the kernel process cluster has a write kernel process corresponding to the target collaborative session, a write kernel process is determined from at least one write kernel process in the kernel process cluster as the target kernel process; if the kernel process cluster does not have a write kernel process corresponding to the target collaborative session, a write kernel process is created in the kernel process cluster as the target kernel process; or... When the operation type is a read operation, if the kernel process cluster has a read kernel process corresponding to the target collaborative session, a read kernel process is determined from at least one read kernel process in the kernel process cluster as the target kernel process; if the kernel process cluster does not have a read kernel process corresponding to the target collaborative session, a read kernel process is created in the kernel process cluster as the target kernel process.

3. The collaborative session management method according to claim 1, characterized in that, In the case where the kernel process cluster includes multiple write kernel processes, the multiple write kernel processes include a master node and child nodes, the step of determining the target kernel process from the kernel process cluster includes: Identify the operation type of the collaborative operation request; When the operation type is a write operation, the master node or the child node in the kernel process cluster is selected as the target kernel process. The master node is used to synchronize the write operation data of the target collaborative session based on the synchronization information of each child node, and synchronize the synchronization information to the child nodes.

4. The collaborative session management method according to claim 1, characterized in that, The step of determining the target kernel process from the kernel process cluster includes: Identify the operation permissions of the collaborative operation request; If the collaborative operation request has write operation permissions, and the number of users handled by the write processes in the kernel process cluster has not reached the set limit, then the corresponding write process is determined from the kernel process cluster as the target kernel process; or... If the collaborative operation request has write operation permissions, and the number of users handled by the write processes in the kernel process cluster reaches a set limit, then the corresponding read kernel process is determined from the kernel process cluster as the target kernel process; or... If the collaborative operation request has write operation permissions, the corresponding read process is determined from the kernel process cluster as the target kernel process, and in response to the received read / write state switching operation, the corresponding write process is determined from the kernel process cluster as the target kernel process.

5. The collaborative session management method according to claim 1, characterized in that, In the kernel process cluster, the write kernel process generates synchronization information for the target cooperative object, and synchronizes the synchronization information to each read kernel process in the kernel process cluster, so that each read kernel process can synchronize data with the write kernel process through the synchronization information. The synchronization information is a storage snapshot or a modification log.

6. The collaborative session management method according to claim 5, characterized in that, The method further includes: When a new kernel process is created in the kernel process cluster, the new kernel process is created based on a storage snapshot of the remaining kernel processes in the kernel process cluster.

7. The collaborative session management method according to claim 1, characterized in that, Before determining the kernel process cluster to which the target collaborative session is bound based on the session information, the method further includes: Obtain the load information of the target collaborative session; Based on the load information, at least one write kernel process and / or at least one read kernel process are selected from the specified service cluster nodes; The kernel process cluster is constructed based on at least one write kernel process and / or at least one read kernel process selected.

8. The collaborative session management method according to claim 7, characterized in that, The step of selecting at least one write kernel process and / or at least one read kernel process from the specified service cluster node based on the load information includes: The number of write kernel processes and / or read kernel processes in the kernel process cluster are determined based on the load information. Based on the number of write kernel processes and / or the number of read kernel processes, at least one specified service cluster node is selected from the service cluster according to the load balancing principle, and a corresponding number of write kernel processes and / or read kernel processes are selected from the specified service cluster node.

9. The collaborative session management method according to claim 7, characterized in that, After constructing the kernel process cluster based on at least one selected write kernel process and / or at least one read kernel process, the process further includes: Monitor the session status of the target collaborative session; Adjust the number of read kernel processes and write kernel processes in the kernel process cluster according to the session state.

10. The collaborative session management method according to claim 7, characterized in that, After constructing the kernel process cluster based on at least one selected write kernel process and / or at least one read kernel process, the process further includes: If the target collaborative session is detected to have ended, the kernel processes of the kernel process cluster are released.

11. The collaborative session management method according to claim 1, characterized in that, The method further includes: Based on the log queue, the modification logs of the target collaborative session are received, and the modification logs of the same object in the log queue are identified as target logs. The target logs are then merged based on the modification time sequence.

12. The collaborative session management method according to claim 11, characterized in that, After receiving the modification logs of the target collaborative session based on the log queue, the method further includes: The change logs in the log queue are broadcast sequentially to each kernel process in the kernel process cluster to perform data synchronization for the target collaborative session; or, Receive a pull request from the corresponding kernel process in the kernel process cluster, and return the specified change log based on the pull request to perform data synchronization for the corresponding kernel process.

13. A collaborative session management system, characterized in that, include: The request receiving module is used to receive a collaborative operation request from a target collaborative object, wherein the collaborative operation request includes session information of the target collaborative session to which the target collaborative object belongs; The cluster determination module is used to determine the kernel process cluster bound to the target collaborative session based on the session information, wherein the kernel process cluster includes at least one write kernel process and / or at least one read kernel process. The request processing module is used to determine the target kernel process from the kernel process cluster and send the cooperative operation request to the target kernel process for processing.

14. An electronic device, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the collaborative session management method as described in any one of claims 1-12.

15. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the collaborative session management method as described in any one of claims 1-12.

Images